1. 为什么大家都在讲k8s技术架构却很少有人把整个体系讲透先说个大实话k8s这个词在简历上出现得越多真正把它当成一件系统活儿来理解的人反而越少。我见过太多人会敲kubectl get pods、会写几个yaml但一旦被问到“你集群里有哪些组件它们之间是怎么协作的为什么挂了某一台Master集群还能继续跑”就当场卡壳。这不怪大家因为k8s技术架构是一个非常典型的分布式系统它把很多原本藏在业务代码背后的复杂问题统一放到了平台层面去解决而要想真正理解这套体系你必须站在“设计者视角”而不是“使用视角”去审视它。k8sKubernetes说到底是一个容器编排平台它解决的是“容器多了怎么管、服务多了怎么调度、流量来了怎么分、机器挂了怎么自愈”这一系列问题。最早我们玩Docker一条docker run就能起一个容器但容器一多网络怎么互通、存储怎么挂载、负载怎么均衡、配置怎么下发全都乱了。docker本身只解决“单机怎么跑容器”k8s则把这些能力提升到“整个集群”级别把一批物理机或虚拟机变成一台逻辑上的超大计算机。这篇文章的核心目的就是从上到下、从控制面到数据面把k8s技术架构拆开讲清楚再结合我实际落地部署、维护集群的经验把你可能踩的坑提前标出来。适合正在学k8s的运维、刚接触云原生的后端开发、准备面试的技术人以及那些已经会用kubectl但想深入理解原理的工程师。网上讲k8s的文章很多但大部分要么是纯概念罗列要么是直接甩一套部署脚本。我的思路是先讲清架构为什么这么设计再带你动手搭一套可用的集群最后把生产环境里常见的故障和监控配套一起收了。这样你学完不是只会跑demo而是能真正去维护一套系统。2. k8s架构设计的底层逻辑控制面与数据面分离2.1 为什么k8s一定要把“大脑”和“手脚”分开k8s技术架构最核心的一个设计理念就是控制面Control Plane和数据面Data Plane/Worker Nodes的分离。这个思想其实一点都不新鲜通信领域的老架构早就这么干了SDN就是把控制逻辑从转发设备里抽出来集中管理。k8s把这套思路搬到了容器调度领域控制面负责做决策工作节点负责执行。你想象一个公司老板和管理层不亲自搬砖他们只负责制定计划、派发任务、检查结果真正干活的是一线员工。老板挂了公司会乱一阵子但业务不会立即全停如果一线员工全跑光那老板再牛也没用。这就是控制面和工作节点的关系。具体到组件控制面有四个核心API Server、etcd、Scheduler、Controller Manager。工作节点上有kubelet、kube-proxy、容器运行时。所有编排动作本质上是“你通过API Server提交一个期望状态控制面里的组件想办法让实际状态无限接近期望状态”。2.2 API Server整个集群的神经中枢API Server是k8s里最核心的入口所有请求、所有组件之间的通信最终都要经过它。你敲kubectl命令kubectl会把它翻译成对API Server的RESTful请求kubelet要向控制面汇报节点状态走的也是API ServerScheduler调度结果要写回集群还是通过API Server。这个组件在设计上有几个让人印象深刻的地方第一它是无状态的所有状态都丢给etcd存储。这意味着API Server可以水平扩展前面挂负载均衡多实例同时对外提供服务。这也为高可用集群提供了基础。第二它内置了一套完善的认证、授权与准入控制机制。请求进来先过认证你是谁再过授权你能干什么最后过准入控制你要干的事合不合规。这个机制非常重要因为k8s集群里所有变更操作都走API Server如果这里把关不严整个集群等于裸奔。第三它是唯一能读写etcd的组件。换句话说etcd里存的数据是“真相”API Server是“唯一合法入口”。这避免了多组件直接操作存储导致的数据不一致问题。2.3 Scheduler和Controller Manager决策者与纠偏者API Server只是接收请求和存储状态真正让集群“动起来”的是另外两个组件。Scheduler负责“把Pod放到哪个节点上”。它不真正去启动容器只是做决策。调度时会考虑资源量、节点亲和性、污点容忍、数据 locality 等因素。调度过程很简单从队列里取出待调度的Pod过滤掉不满足条件的节点然后打分选最高分的节点把结果写到API Server。从K8s 1.16开始Scheduler里已经默认启用了调度框架Scheduling Framework可以自定义扩展点这也是为什么你能在社区里看到各种自定义调度器的原因。Controller Manager则是“纠偏者”。它内部跑着很多个循环控制器比如ReplicaSet控制器、Deployment控制器、Namespace控制器等。每个控制器的逻辑都是同一个循环观察当前状态对比期望状态执行操作弥合差异。举个例子你创建一个Deployment说“我要3个副本”Controller Manager里的Deployment控制器发现当前只有0个Pod在运行它会创建3个某个Pod挂了控制器发现实际数量小于期望数量它又会补一个新的Pod。这套逻辑叫“控制循环”是k8s最基础的哲学永远朝期望状态逼近。2.4 etcd唯一的数据真相存储etcd是整个集群的“记忆体”集群的期望状态和实际状态全存在这里。它基于Raft共识算法保证多节点之间的数据一致。生产环境至少要用三节点etcd集群这台机器如果全挂了控制面就读不出状态了虽然Pod还在跑但任何变更操作都无法执行比如无法扩缩容、无法滚动更新。很多人会忽略etcd的运维工作我在这里多说一句etcd备份是你保命的底线。别嫌麻烦至少做每日快照。真正出故障的时候没有备份就相当于一切重来。2.5 工作节点实际干活的kubelet与kube-proxy工作节点上的核心是kubelet。这个组件看起来简单实际非常重要。它通过API Server监听分配给本节点的Pod任务然后调用容器运行时比如containerd去真正启动或停止容器。它还要周期性地上报节点状态、Pod运行状态、资源使用情况。kubelet有点像项目经理手下的一线班组长总部通知你来了三个新任务你负责安排手下工人干活工人干得怎么样你要定时汇报上去出了问题你要重启工人或者把情况反馈上去。kube-proxy则负责实现Service的访问规则。Service是k8s里一个逻辑抽象它为一组Pod提供一个稳定的访问入口。kube-proxy通过iptables或IPVS规则把发往Service地址的流量转发到后端的某个Pod。这里有个很重要的细节kube-proxy并不是代理进程本身它是规则管理器真正转发数据的还是内核里的iptables/IPVS。所以严格说它更像是“交通规则划线员”不是“交警”。3. 高可用集群怎么搭三台Master的坑与原理3.1 为什么需要三台Master两台行不行很多新手都会问为什么生产环境要三台Master两台行不行这个问题得从etcd的选主机制说起。etcd用Raft协议保证数据一致性Raft要求大多数节点同意才能提交数据、才能选主。大多数意味着N/2 1个节点。两台节点时大多数是2台任何一台挂了另一台就凑不齐大多数集群直接变成只读状态。而三台时允许坏一台五台时允许坏两台。所以从数据安全角度主节点数必须是奇数且至少三台。这也就解释了为什么“三台master高可用”在k8s部署里那么常见它是用最低成本换取故障容错能力的最优解。3.2 高可用的核心让API Server永远有响应k8s控制面高可用的关键是API Server。因为所有组件交互都通过API Server所以如果API Server不可用整个系统就瘫痪了。要让API Server高可用需要做两件事第一多个API Server实例同时运行共享同一个etcd集群。它们是无状态的所以可以同时对外服务。第二在前面对一个负载均衡器把请求分发到多个API Server。负载均衡器本身也要高可用可以部署KeepalivedHAProxy也可以用云平台的LB产品。注意这个LoadBalancer的IP建议是稳定的VIP因为kubelet、kube-proxy都要用这个地址访问API Server。3.3 kubeadm与KubeKey两种主流部署方式对比这里重点说一下两个工具选型的对比因为好多人在这上面卡了很久。kubeadm是官方推荐的部署工具它的优点是标准、透明、可审计。所有组件都以静态Pod形式运行在Master节点上你可以在/etc/kubernetes/manifests目录下看到各个组件的 manifest 文件。改动配置、排查问题都很方便。它适合有一定k8s基础、想深入理解组件协作关系的团队。KubeKey是KubeSphere社区出品的部署工具最大特点是全自动化和一体化一条命令能连操作系统层面的docker/containerd安装、k8s集群部署、高可用配置全部搞定。它还在持续集成里预置了很多云原生组件比如Prometheus、Grafana。但它的黑盒程度比kubeadm要高出了问题你需要去了解它生成的配置在哪里。我个人推荐学习阶段用kubeadm生产环境如果团队人力充裕也用kubeadm因为它更可控如果追求快速交付且不想折腾底层细节KubeKey是省心选择。3.4 三节点Master高可用部署实操kubeadm路径这里给出一套我可复用的部署思路假设你已有三台Linux服务器每台都装好了docker/containerd第一步给三台节点设置主机名并关闭swap。k8s要求禁用swap否则kubelet无法启动。执行swapoff -a sed -ri s/.*swap.*/#/ /etc/fstab第二步加载内核模块和参数cat /etc/modules-load.d/containerd.conf EOF overlay br_netfilter EOF modprobe overlay modprobe br_netfilter第三步所有节点安装kubeadm、kubelet、kubectl。三件套的版本必须固定建议先指定好版本号再安装避免版本漂移。第四步在第一台Master上kubeadm init --control-plane-endpoint k8s-master-vip:6443 \ --apiserver-advertise-address0.0.0.0 \ --pod-network-cidr10.244.0.0/16注意--control-plane-endpoint填的是负载均衡器的VIP地址不是第一台Master自己的IP。这是三节点高可用和单节点部署最大的区别。初始化完成后把生成的kubeadm join命令保存好这个命令里带了证书token。第五步在第一台Master上配置kubectl然后部署CNI网络插件的Pod网段。Pod网段必须与--pod-network-cidr一致否则节点网络不同。第六步在第二台、第三台Master上执行kubeadm join命令注意追加--control-plane参数表示加入控制面否则只会变成Worker节点。3.5 高可用集群验证清单部署完成后不要急着开心先做这几项验证在任意Master上执行kubectl get nodes三个节点都应显示Ready。执行kubectl get pods -n kube-system确认所有控制面组件处于Running。停掉一台Master上的kubelet再执行kubectl get nodes观察集群是否仍能正常响应。这种故障演练最好定期做否则真出故障时你会手忙脚乱。在所有Worker节点上执行kubeadm join将Worker节点加入集群数量按业务需要。我遇到过一种很典型的问题部署完三台Master发现etcd集群状态正常但Scheduler总是不工作后来排查发现是控制面端点VIP没有配置好导致Scheduler访问API Server超时。这种问题最隐蔽配置文件里看着都对但网络层面就是不通。4. 从Pod到Service再到Ingress流量路线的关键拆解4.1 Pod的IP与集群网络的基石Pod是k8s中最小调度单元每个Pod有自己的IP。Pod内的容器共享网络命名空间所以通过localhost就能互相访问。而不同的Pod之间通信则需要CNIContainer Network Interface插件来解决。常见的CNI有Calico、Flannel、Cilium。这里有个关键点CNI网络是集群内部网络Pod IP通常只在集群内可达。你从外部是无法直接访问这个IP的。所以Service才有了存在的意义。4.2 Service的三种类型到底怎么选Service是k8s里一个重要的抽象。我见过很多新手在这里绕晕其实就是流量进入集群的三种方式。ClusterIP默认类型给Pod组一个稳定的虚拟IP只能在集群内部访问。比如后端服务A调用后端服务B用ClusterIP最合适。NodePort在每一台节点上开放一个高位端口外部通过任意节点的IP这个端口访问。适合测试环境、临时联调。生产环境直接用NodePort暴露服务通常被认为是不太优雅的方案因为它直接把机器端口透出去了。LoadBalancer本质是NodePort的扩展版它会在云平台上创建一个负载均衡器把流量转发到任意节点的NodePort上。自建集群通常用MetalLB这类软件方案提供类似能力。这里也值得提一下externalIPs字段这是Service里一个比较冷门但实用的配置你可以手动指定一个集群外部可达的IPkube-proxy会把Service流量打到这个IP上。早期自建集群没有LB时很多人靠它应急但它不支持自动故障转移设置的时候要确认外部IP真的可达。4.3 kube-proxy三种模式userspace、iptables、IPVSkube-proxy在实现Service流量路径上可选的方案不同性能差异明显。早先的userspace模式已经不推荐了它把数据包送到用户态的代理进程再转出去性能和延迟都很差。iptables模式是k8s默认的模式它用iptables规则做DNAT把发往Service ClusterIP的流量改写目标地址为某个Pod IP。规则由kube-proxy动态维护。性能比userspace好但Pod数量上千后iptables规则会非常多内核遍历规则时CPU开销会变成瓶颈。IPVS模式是生产环境里更推荐的模式。它利用内核的IPVS模块做负载均衡支持更多算法rr、wrr、lc等规则复杂度远低于iptables性能在高并发下表现好得多。我的建议是如果你的业务规模起来了或者是生产集群直接启用IPVS模式。切换方法是在kube-proxy的ConfigMap里把mode改成ipvs然后滚动重启所有kube-proxy Pod。4.4 Ingress七层路由的钥匙Service是四层负载它只看IP和端口到了真正的业务场景需要根据域名、URL路径做路由这就需要Ingress。Ingress是k8s内置的一套资源对象只定义规则真正干活的Ingress Controller会监听这些规则然后配置Nginx/Envoy等代理服务。比如你要让a.example.com走服务Ab.example.com走服务B用Ingress是最标准的做法apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: a.example.com http: paths: - path: / pathType: Prefix backend: service: name: service-a port: number: 80 - host: b.example.com http: paths: - path: / pathType: Prefix backend: service: name: service-b port: number: 80这里要注意一个容易错的地方Ingress Controller和Ingress资源是两个东西。你只创建Ingress资源不部署Controller规则永远不会生效。很多新手在这个上面卡一整天。5. 控制器、Operator与GPU调度k8s的扩展能力边界5.1 控制器本质把“运维动作”变成“声明式期望”之前提过Controller Manager里内置了一系列控制器。但k8s的强大之处在于它允许你自定义CRDCustomResourceDefinition然后编写自定义控制器去响应这些新资源的变更。这就是Operator模式的底层基础。你想象一下如果Deployment控制器是“通用进程守护者”那Operator就是“领域专家”。前者只知道“保持3个副本”后者知道“这是一个数据库实例需要主从复制、需要定时备份、需要故障自动切换、版本升级要按特殊顺序”。k8s社区里有大量成熟的Operator比如Prometheus Operator、Elasticsearch Operator、RabbitMQ Operator等用它们管理有状态应用效果远好于手动维护StatefulSet。我在实践中最大的体会是Operator不是银弹但它把原先写在运维手册里的流程固化成了代码。你写Operator不是写一堆yaml而是写一套“如何运维这一种应用”的程序逻辑。理解这一点去看商店里那些开源Operator思路会清晰很多。5.2 GPU调度是怎么做出来的k8s调用GPU是一个高需求场景尤其是做大模型推理和AI训练时。k8s原生并不能直接识别GPU它靠的是Device Plugin机制。简单说Device Plugin是一个运行在节点上的插件负责向kubelet上报“这台机器上有4张GPU”并负责启动容器时把GPU设备挂载进去。部署NVIDIA GPU的Device Plugin后你就可以在Pod里声明resources: limits: nvidia.com/gpu: 1调度器看到这个请求后会优先把Pod调度到有GPU资源的节点上并在该节点上分配一个GPU。如果节点有多张GPU默认情况是随机选你可以通过环境变量NVIDIA_VISIBLE_DEVICES做更细粒度的控制。GPU调度的坑主要是驱动版本和不兼容。Device Plugin版本要和NVIDIA驱动、容器运行时版本配套否则上报设备会失败。我用过一个办法先手动在节点上跑一个简单的GPU容器验证CUDA能正常访问再去允许调度能帮你把问题限定在“节点本身”而不是“k8s调度配置”。5.3 集群资源管理的另一条线HPA与资源配额调度GPU只是资源管理的一部分。k8s里还常常用HPAHorizontalPodAutoscaler做弹性伸缩核心思路是先设置一个目标指标比如CPU使用率或自定义Prometheus指标控制器周期性地获取当前指标然后根据期望副本数公式计算应该扩到多少副本。公式长这样desiredReplicas ceil[currentReplicas * (currentMetric / targetMetric)]。比如当前副本数是2当前CPU平均使用率为80%目标值是50%那期望副本数就是ceil[2 * (80/50)] 4。HPA会让Deployment扩到4个副本等负载降下来再缩回去。生产环境里推荐用自定义指标而不是纯CPU水位因为很多服务的瓶颈在内存、QPS、队列深度等只盯CPU容易误判。如果你已经部署了Prometheus配合prometheus-adapter来做自定义指标HPA是完整路径。6. 监控体系怎么搭Prometheus、Metrics Server与告警实战6.1 先分清三种监控数据来源kluster运维第一个问题就是数据从哪里来。我建议先理解三类来源基础设施指标节点CPU、内存、磁盘、网络。这部分由node-exporter采集。k8s对象状态Pod数量、Deployment状态、节点Ready情况。这部分由kube-state-metrics从API Server读取。业务容器指标应用内部的QPS、延迟、错误率、饱和度。这部分需要业务暴露Prometheus格式的/metrics接口由Prometheus主动拉取。把这三类分开监控体系就不会糊成一团。6.2 部署Prometheus监控k8s的推荐路径直接用Helm Chart是最省事的方案。先加仓库然后自定义values.yaml重点改下面几个参数prometheusOperator: createCustomResource: true kubeStateMetrics: enabled: true nodeExporter: enabled: true grafana: enabled: true adminPassword: your-passwordHelm部署完成后Prometheus会自动创建一堆监控规则和采集目标包括apiserver、kubelet、kube-scheduler、etcd等。它会通过ServiceMonitor和PodMonitor这两种CRD来自动发现要采集的目标。这套机制的优雅之处在于以后新部署一个有监控需求的中间件你只需要给它标注上Prometheus的注解监控规则自动纳入采集范围不用手动改配置。6.3 Metrics Server与Prometheus别搞混很多新手会把Metrics Server和Prometheus混在一起。Metrics Server是k8s内置的轻量级指标采集器它只提供kubectl top命令的数据支持供HPA使用。它不长期存储历史数据功能定位非常明确只做“实时快照查询”。Prometheus则是完整的监控与告警系统有TSDB存储、有PromQL查询语言、有Alertmanager告警。两者一个轻量一个重一个服务HPA一个服务运维监控。生产环境一般是两个都装职责分离。6.4 告警规则怎么配置才有价值我第一次配告警时把阈值设置得很敏感结果半夜告警轰炸群里的同事第二天怨声载道。后来我终于总结出一套相对合理的告警策略CPU和内存使用率超过85%持续5分钟告警一次表示节点快要扛不住。Pod频繁重启超过阈值比如重启次数达到10次以上需要人工介入。持久化卷使用率超过90%这个必须告警因为存储写满往往意味着服务直接不可用。控制面组件不可用这类告警优先级最高直接P0。还要注意设置for字段比如for: 5m表示持续5分钟才触发。这个字段非常实用它可以过滤掉很多瞬时抖动。6.5 一次完整的监控事故排查记录之前我维护的集群出现过一次Kubelet“永久掉线”现象节点明明还活着但kubectl get nodes显示NotReady。排查时我先检查Kubelet服务状态看日志发现反复出现“Failed to update node lease”。这类问题的根因多半是Kubelet无法稳定上报Lease信息可能因为API Server负载过高或是Kubelet证书过期。当时处理办法是先看看API Server有没有异常日志又检查证书有效期。最后定位是证书过期导致Kubelet与API Server之间的TLS握手失败。解决办法是更新集群证书kubeadm certs renew all然后重启控制面组件。这里提醒一句自建集群最容易忽略证书过期问题。默认证书有效期是1年很容易埋雷。建议在监控里加一条证书过期时间告警规则类似kubeadm_cert_expiration_days 30。不然等到证书过期那天你会同时面对一大片故障信息。7. 常见问题排查技巧与面试高频考点7.1 镜像拉取不到先分清楚是网络问题还是配置问题自建集群最常见的问题是ImagePullBackOff也就是镜像拉取失败。排查思路是先看节点的容器运行时配置比如containerd是否配置了私有镜像仓库。确认网络能连通后再检查私有仓库的认证。除此之外国内访问Docker Hub经常不稳定解决办法是给容器运行时配置镜像加速器或把镜像同步到内网仓库。这类问题的排查路径其实是个很好的思维模型先看Pod事件再看节点日志最后查配置。不要一上来就盲目重启。7.2 Pod一直PendingScheduler不调度还是资源不足Pod卡在Pending状态最常见原因是资源不足。你可以在kubectl describe pod xxx里看到调度失败的提示比如“0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory”。这种情况要么给节点扩容要么降低Pod的资源申请量。另一种原因是节点有污点TaintPod没有对应的容忍Toleration。这种情况describe里也会有明确提示。比如Master默认有NoSchedule的污点你直接把Pod调度到Master上就永远Pending。多节点集群习惯后这些问题基本一眼就能看出来。7.3 面试高频k8s和docker到底是什么关系热搜里有一个非常典型的问题k8s和docker区别。这个问题几乎每次面试都会被问到但问法往往不同你有必要把逻辑理清楚。Docker解决的是“单机容器化”它让你能打包、发布、运行一个或多个容器。k8s解决的是“大规模容器编排”它管的是多台机器上的容器如何协同工作。你在k8s里完全可以用containerd作为容器运行时不装Docker也没关系因为k8s接口是CRIContainer Runtime Interface运行时只要实现这套接口就能接入。Docker只是runc之上加了镜像管理、CLI等功能的“全家桶”后来k8s为了让Docker作为运行时接入专门写了dockershim适配器但到k8s 1.24这个适配器就被彻底移除了。所以在面试里回答这个问题的标准姿势是两者不在同一个层次Docker是runtimek8s是orchestratork8s本来就是设计成支持多种运行时的Docker只是其中一个选择。7.4 面试高频三台Master怎么保证高可用这个问题考察的就是控制面的高可用设计。你需要围绕三件事回答API Server无状态多实例共用一个etcd集群前置负载均衡。etcd通过Raft保证一致性奇数节点能容忍少数节点故障。kubelet始终指向VIP访问控制面。如果面试官再深挖你还要能说出这种架构不依赖“active-passive”而是所有Master实例都处于活动状态Scheduler和Controller Manager通过leader选举机制选出唯一工作实例。这个机制利用了租约Lease对象续约失败时其他实例接任。7.5 常用命令的实战记忆法很多人记不住k8s常用命令我提供一个场景记忆法不要死记硬背。一个典型的操作流程是查看集群状态kubectl get nodes、kubectl get pods -A看资源详情kubectl describe pod xxxx看日志kubectl logs -f pod-name --tail200进入容器排查kubectl exec -it pod-name -- /bin/bash看资源使用kubectl top nodes临时调试端口转发kubectl port-forward pod-name 8080:80修改资源定义kubectl edit deployment xxx命令审计kubectl get events --sort-by.lastTimestamp只要你在集群里完整排查过几次问题这些命令会自然记住。真正要下功夫的是对describe输出和事件日志的解读能力。8. 最后一个实操经验我的集群维护工作流文章写到这里核心内容其实已经讲完了。最后再分享一个我长期维护这套体系时沉淀下来的工作流希望对你有参考价值。每个工作日早上到岗我先花两分钟看三样东西kubectl get nodes的输出是否全为Readykubectl get pods -A | grep -v Running是否有异常状态kubectl get events --sort-by.lastTimestamp | tail -20有没有明显异常事件。这三条命令并不复杂但它能帮你快速感知集群健康状况。每周做一次etcd快照备份把快照文件同步到专门的备份存储。从k8s 1.27开始etcdctl snapshot save命令是针对具体节点的操作时要小心指定endpoint。如果你用1.27以下版本命令会稍微不同但备份思路不变。每月做一次故障演练或者至少做一次控制面组件重启演练观察集群的容错表现。很多高可用架构“看着没问题”实际上可能因为负载均衡器、防火墙或证书到期等问题在高可用切换的关键时刻掉链子。提前演练就好比给你的架构做一次预防性体检。我这几年最大的体会是k8s技术架构真正难的不是单点组件原理而是所有组件协同工作时暴露出的“分布式系统问题”证书过期、网络偶发超时、etcd磁盘空间不足、节点时钟漂移……这些问题都不是某一个组件能单独解决的它们需要你对整个体系有全局的理解。希望这篇文章能帮你把那块拼图拼完整。