1. 从一个日常部署场景说起集群到底在干嘛我第一次试着在生产环境用Kubernetes下文直接叫k8s的时候脑子里只有一个模糊的印象它能把一堆服务器我管起来有问题自动重启流量大了自动扩展。但真到搭建集群、排查故障的时候发现自己连组件之间谁和谁说话、谁负责干什么都没搞清出了问题只能靠重启和百度。如果你也是准备入门k8s的开发或运维我强烈建议你先别急着写YAML也别一上来就折腾各种插件。先把集群里都有什么角色搞清楚这一篇就是干这个的。你可以把k8s理解成一个托管容器的小区物业你只告诉物业我这个房里要住3个租客容器一个负责做饭两个负责打扫后面租客怎么安排、房子怎么分配、谁生病了谁来替补都归物业管。这个物业由好几个部门组成有的坐镇物业总部控制面有的驻在每个楼层工作节点。对应到技术语言k8s是一种容器编排系统其核心目标就是让你用声明式的方式描述期望状态系统持续调和现实状态直至两者一致。这里的期望状态就是我要3个副本我要Nginx镜像1.24版之类而调和动作就是集群里各组件分工协作干出来的。整篇文章我会把组件分成两拨讲一拨是控制面成员负责做决策另一拨是工作节点成员负责干活。最后再用一条创建Pod的完整旅程把所有串起来。2. 控制面四件套谁在做决策、谁在记账、谁在安排工作控制面Control Plane是集群的大脑。它不一定只部署在一台机器上通常会有多个副本保证高可用。这里先按单机房、单主节点的场景讲逻辑清楚后再谈多副本。2.1 kube-apiserver所有请求的唯一入口集群的前台所有和集群有关的操作——不管是kubectl敲入的命令、各组件之间的通信还是外部系统通过API访问——最终都要经过kube-apiserver通常简称apiserver。它有三层职责认证、授权、准入先证明你是谁证书/token再判断你有没有权限干这事RBAC最后通过准入控制器检查比如配额够不够、这个标签是否合规。RESTful API转发把请求转换成etcd能理解的操作就像前台把客人的需求抄成工单递给档案室。无状态网关apiserver自己不存业务状态所有状态都落到etcd里这也是为什么它可以水平扩展多个实例。一个容易忽略的点apiserver是集群里唯一能和etcd直接对话的组件。换句话说任何人想改集群状态都得走apiserver这道门。这么设计的好处是权限集中、审计集中任何变更都有据可查坏处是apiserver一旦过载或挂了整个集群就聋哑了——不是业务流量断了而是所有人都无法查询和修改集群状态了。实操心得多主节点环境下给apiserver前面挂负载均衡时注意保持长连接参数比如TCP的keepalive时间、超时时间不要沿用普通的Web负载均衡配置。我见过太多因为负载均衡空闲超时设得太短导致apiserver连接频繁断开、kubectl频繁卡顿的情况。2.2 etcd群集状态的档案室所有真相都在这里etcd是一个分布式的键值存储集群里所有对象——节点信息、Pod定义、配置、Secret、Deployment状态——都以键值形式存在这里。它最大的特点是强一致性也就是说无论集群里有多少个etcd节点大家读到的最新值都是一样的。为什么可能需要等一会才能看到实时状态因为k8s集群本身就是一个基于期望状态不断调和的系统各组件通过apiserver往etcd里写变化又通过监听机制感知变化。etcd保证的是一旦写入成功所有人都能读到这个最终值但落到各组件自己的内存视图可能稍有延迟这是最终一致的体现不是bug。useful类比etcd像物业的房屋档案册它不负责规划、不负责执行只负责把所有事实准确记下来。如果档案册丢了物业就失去了一切记忆所以它需要备份而且备份要放在独立环境不能和集群同生共死。生产环境etcd建议单独部署至少3节点磁盘尽量用SSD不要和业务容器混跑。定期做快照。这条我劝你自己动手写个cron任务别指望云厂商的自动备份一定符合你的RPO要求。删除操作要小心etcd里的数据被覆盖后很难找回这和MySQL里误删还能靠binlog恢复不太一样。2.3 kube-controller-manager只盯着现状改没改到位的调和器controller-manager名义上是一个组件里面其实跑着几十种不同的小控制器controller。它们各有分工节点控制器检查节点健康发现节点失联就标记NotReady等一段时间没恢复就执行Pod驱逐。副本控制器盯住ReplicaSet发现副本数少于期望值就补充。部署控制器盯住Deployment负责滚动更新的节奏控制、新旧版本Pod的切换。端点控制器维护Service对应的Pod列表谁添加、谁删除都会反映到Endpoints对象里。这些小控制器的工作模式高度统一叫Reconcile循环调和循环从etcd / 缓存读取当前状态和期望状态对比有差异就执行动作比如创建Pod、删除Pod、更新状态然后进入下一轮循环。整个k8s的自动恢复能力就是靠这一群永远在对比、永远在纠偏的小循环撑起来的。有一个非常关键但容易被忽略的事实controller-manager本身不直接创建容器它只是调用apiserver的接口去修改集群对象。最终创建容器的动作要等后续章节的工作节点组件接手。理解这一点你以后排查为什么Pod没有按预期创建时思路就能顺着这条链路一层层往下找。2.4 kube-scheduler决定新Pod放哪台机器的分配师调度器scheduler负责给还没有分配节点的Pod找到合适的家。它从apiserver拿到待调度Pod的队列然后做两件事过滤预测排除掉不满足条件的节点。比如Pod要求4核节点只有2核或者Pod声明要落在有特殊标签的节点上其他节点直接出局。打分优选在合格节点里按资源余量、亲和性、污点容忍等规则打分选最优者。选完后scheduler并不过去物理机上推一把而是把结果写成一个对象绑定Binding通过apiserver更新到etcd里。后续真正在节点上拉起容器的是节点上的kubelet看到这个绑定后自己动手的。调度策略默认是资源足够就安排但生产环境常常需要加自定义规则比如节点亲和性把数据库Pod固定到有大磁盘的节点组。污点与容忍给某些节点打上这里只为特定业务服务的污点其他Pod默认进不来。拓扑分布约束把副本分散到不同可用区避免一个机房故障全挂。注意scheduler看重的是调度时刻的资源情况但调度完到Pod真正启动还有时间窗口高并发创建Pod时可能出现腹泻式调度后节点负载不均。这是scheduler设计上的固有延迟高级用法可以用调度插件和Pods Topology Spread来缓解入门阶段了解即可。3. 工作节点三件套真正在机器上干活的组件控制面做再多的决策终究要落到具体的服务器上跑容器。每一台工作节点上都有三个常驻组件它们才是一线员工。3.1 kubelet节点上的全权代表负责容器生老病死kubelet是每台节点上唯一的官方管理员它以Agent形式运行持续通过apiserver监听Watch分配给本节点的Pod需求。一旦发现有新的Pod对象绑到自己身上kubelet就会接手后续一系列操作拉起容器调用容器运行时比如containerd挂载存储卷协调CNI插件给Pod配置网络定期执行存活探针Liveness Probe和就绪探针Readiness Probe向apiserver上报节点状态、Pod状态、资源使用情况它和控制面的通信方向需要注意kubelet是主动向apiserver发起连接的不是apiserver反向连它。所以kubelet所在节点的网络只要能做到出去就行反过来如果你的防火墙规则要求apiserver主动找到kubelet那方向就搞反了集群一定起不来。一个常见的坑kubelet默认每10秒上报一次状态节点失联后控制器并不能立刻判定节点宕机而是要等节点失联宽限期node-monitor-grace-period默认40秒过去再配合一次Pod驱逐宽限期才算确认节点没了。所以生产上看到节点宕机但Pod没有马上迁移是正常现象不要急着怀疑系统坏了。3.2 kube-proxy让Service像一台虚机的连通工具每个节点上还有一个叫kube-proxy的进程。它解决的核心问题是一群Pod的IP会随时变化你怎么用一个固定的前端地址稳定地访问它们答案就是Service对象。而Service只是存在etcd里的一个逻辑定义真正让流量按照Service规则转发到具体Pod的是每台节点上的kube-proxy。它会把Service和后端Pod的关系转换成节点上的网络规则常见的模式有iptables模式成熟稳定但规则多了之后性能一般。ipvs模式性能更好支持更多调度算法也是目前主流推荐模式。需要理解的是kube-proxy只负责做规则真正走流量时数据包的转发是靠Linux内核的netfilter完成的并不经过kube-proxy进程本身。所以kube-proxy的CPU占用通常不高但如果节点上Service数量上千、规则极其复杂iptables模式的效率会明显下滑切换ipvs模式会有可感知的提升。3.3 容器运行时真正生出容器的底层引擎在k8s里kubelet并不直接调用docker命令而是通过CRIContainer Runtime Interface和容器运行时对话。当前事实标准是containerd早期k8s还内置支持docker后来通过CRI插件过度如今docker直接作为k8s运行时已经很少见了。还有一个概念值得了解pause容器也叫基础设施容器。每个Pod在真正启动业务容器之前kubelet会先创建一个全新的pause容器它的唯一作用是占住这个Pod的网络命名空间和Linux命名空间后续所有业务容器都共享这个命名空间。换句话说Pod里多个容器可以通过localhost互相访问原因就在pause容器身上。如果不太理解pause容器你只需要记住一句话每个Pod都有一个隐形大哥它先占着网络业务容器才进来一起住。这个设计让Pod成为k8s里最小的调度和资源共享单位而不是单个容器。3.4 节点上的常驻服务不只是三个组件除了上面三件套节点上还少不了一些日常插件CoreDNS集群内部域名解析默认Service名称和命名空间会自动注册成域名Pod之间通过域名访问依赖它的解析。CNI网络插件为每个Pod分配IP、打通跨节点网络常见有Calico、Cilium、Flannel。Metrics Server提供资源指标数据是kubectl top node这类命令的数据来源没有它HPA水平自动扩缩容也无法工作。4. 一条请求从进入到落地的完整旅程把组件串起来看单独记每个组件的职责容易忘我们来追踪一条真实请求把前面所有内容串成一个完整故事。假设你执行一条命令kubectl create deployment nginx-demo --imagenginx:1.24完整链路如下第1站kubectl → apiserverkubectl先把这条命令转成JSON格式的请求发给apiserver。apiserver先做身份认证验证你的kubeconfig里的证书再做授权检查确认你有权限在default命名空间创建Deployment最后通过准入控制器校验合法性。没问题它就把用户想创建一个名为nginx-demo的Deployment这个对象持久化写入etcd。第2站deployment controller → replicasetdeployment控制器一直监听etcd里的Deployment对象。它看到一个新的Deployment出现期望副本数是1默认于是它去创建对应的ReplicaSet对象。ReplicaSet控制器又发现这个Set目前没有Pod于是开始创建Pod对象。第3站scheduler介入这个Pod对象创建出来后它的节点字段是空的。scheduler一直监视这类待调度Pod它开始过滤和打分。假设当前集群里node-01资源充足于是它把这个Pod绑定到node-01并回写状态到etcd。第4站kubelet接手node-01上的kubelet通过watch感知到有个新Pod被分配给自己于是按Pod定义开始干活先创建pause容器铺好网络命名空间再从镜像仓库拉取nginx镜像启动真正的nginx容器把port、env、volume逐一配置好。Container运行时通过CRI接口执行这些动作同时把容器的运行状态回传给kubelet。第5站网络与服务别名容器起来了CNI插件给它分配一个集群内部IP。此时如果你之前已经定义了一个Service指向这个Deploymentkube-proxy会自动把Service的转发规则更新为流量可以送到这个新Pod的IP并且当Pod被删除时这条规则也会被清理相关Pod从Endpoints中摘除。整个链路你会发现apiserver像一条主干道几乎每个环节都要经过它etcd像记忆库所有状态都从这里读、写controller-manager像监工不断检查各个环节有没有偏离scheduler像分配员只管决定去哪kubelet像一线工人具体把活干完kube-proxy和CNI插件则负责把抽象的网络变成能用的现实。我再补一个真实排查经验有一次新加的节点始终没有调度上去任何Pod查看日志发现scheduler一直在报node is not ready。当时我第一反应是看kubelet是否正常运行确实运行正常后来才定位到是时间同步问题——节点时钟和主节点差异超过1分钟kubelet上报状态时被apiserver的正常心跳检查逻辑拦了下来。装好NTP服务、校准时钟后一切恢复正常。这件事给我的教训是排查集群问题的时候从组件之间只要有一个没对齐整条链路就堵的角度出发往往比盯着单个组件的日志更高效。5. 集群组件部署形态与容量规划的一些参考知道了每个组件的职责接下来就是它们应该怎么部署、各给多少资源。这里给出的是中小集群的常见参考不是绝对标准。5.1 单机学习 vs 高可用生产形态控制面部署工作节点适用场景单节点/开发控制面和工作节点在同一台机器1台即可学习、联调、Demo小型集群控制面单独1~3台2~5台中小规模业务生产高可用控制面独立部署3台apiserver/etcd等全部多副本按需扩容线上业务建议至少3个控制面节点加3个etcd节点控制面节点不建议和工作节点混跑尤其不要让etcd和业务容器共享磁盘IO否则一个业务高峰期就能把性能拖垮。5.2 资源配比的经验值最小单机学习环境2核4G内存跑一个控制面加一个工作节点日常玩转基本够用。小规模生产主节点建议4核8G起步apiserver和etcd共享这台机器时内存最好不低于8G。工作节点看业务容量一般4核8G起步再做垂直扩容。有一个要反复强调的事etcd对磁盘延迟极其敏感如果使用机械硬盘或NoSQL类网络的存储etcd的性能会直接拖累整个集群的控制面响应表现为kubectl查询极慢、调度延迟高但节点上的容器可能还跑得好好的。这种业务没事、命令卡死的体验往往就是etcd在门口堵车。5.3 常见误区认为apiserver只是个代理它要处理认证、准入、序列化、缓存、限流负载并不低。主节点上apiserver进程CPU飙升时需要检查是不是有太多的list-watch请求。以为controller-manager挂了只是控制慢它挂了之后虽然Pod本身还能跑但Deployment的滚动更新、故障副本补充、节点失联后的驱逐都会停摆等于集群的自愈能力失效了。把kube-proxy不当回事在旧版本k8s里kube-proxy的iptables规则和Service更新有时会让部分节点上的连接短暂中断。升级到ipvs模式并配合conntrack参数调优后这类问题会缓解很多。6. 入门阶段最容易踩到的坑以及如何避免这部分是我自己带团队过程中最常被问到的问题我把它整理成排查清单初学阶段照着排查能少走很多弯路。6.1 组件日志要看哪个进程控制面组件要么是systemd服务比如kubelet、kube-proxy要么是容器化Pod比如apiserver等。排查时优先看kubelet日志因为绝大多数下层问题都会传导到它这里。查看Pod起不来的原因第一优先看kubectl describe pod它会把事件历史列出来比如镜像拉取失败、端口冲突、探针失败。比看容器日志更高效。6.2 证书和Token是隐性雷区集群内部的证书有有效期apiserver的证书过期后kubelet、kubectl、各个控制器之间都会报certificate has expired or is not yet valid。生产环境建议提前配置自动续期并监控证书到期时间。我踩过一个具体案例某内部集群某天突然大量报x509: certificate has expired但kubectl访问还是正常的后来发现是服务账户Token里内置的旧证书过期Pod访问API时用到旧签发证书就会报错。这类问题只看Pod日志很容易误判成网络问题实际上换一个重新签发的Token就能解决。6.3 Node失联后的Eviction时间线节点宕机Pod不会瞬间被重新调度。整体时间线大概是kubelet心跳超时默认40秒→ 节点控制器标记NotReady → 再过一段时间由pod-eviction-timeout决定默认5分钟→ 才开始驱逐该节点上的Pod。也就是说就算你的节点真的挂了理想情况下也要5分多钟才迁移业务关键业务必须提前设计多副本和优雅终止不能指望快速迁移兜底。6.4 不要忽略网络插件版本和内核参数的匹配Calico或Cilium这类CNI插件对Linux内核模块和iptables/netfilter版本有要求。升级内核或切换网络插件大版本时最好先在一个节点上验证否则可能出现某些节点上Pod间通信异常但容器本身跑得好好的诡异问题。这类问题的排查思路一般是先看节点上ip a里Pod网卡是否存在再看CNI插件的日志最后查内核模块是否加载。7. 控制面扩容和升级时的三件事如果你已经能在测试环境里正常创建Pod下一步基本就是考虑生产化此时有三件事必须提前规划。第一etcd备份是性命攸关的。建议维护一个独立的备份任务把etcd快照存到对象存储或异地机器。恢复流程也建议在测试环境演练一遍不要等真正出事了才去翻文档。第二版本升级遵循先控制面、后节点的顺序。控制面内部依次升级etcd、apiserver、controller-manager、scheduler然后处理节点的kubelet和kube-proxy。跨小版本升级没问题但跨大版本比如从1.24升到1.28建议逐版本或查阅官方支持链路不要跳。第三组件之间的兼容性要看官方矩阵。kubelet最好和apiserver保持同版本或小版本差不要差太多。很多人图省事手动装一个最新版kubelet配一个稍老版本apiserver结果证书、API字段兼容性上问题一堆。8. 最后再分享一个小技巧用角色卡的方式记忆组件入门阶段我不建议靠死记硬背每个组件的标志和端口。我自己的办法是先建立谁做决策、谁干活、谁管账的角色框架再遇到具体问题的时候追问这一步是哪个角色在负责。比如看到Pod一直Pending就问是scheduler没选好节点还是节点资源不足这两者的排查路径完全不同前者看scheduler日志和事件后者看节点资源和污点。再比如看到Deployment一直没有新的Pod生成就问deployment controller有没有创建ReplicaSetReplicaSet有没有创建Pod还是controller-manager压根没启动顺着这个思路排查的速度会比直接乱翻日志快得多。k8s的组件体系看起来很多但核心逻辑其实就一条一个集中式控制面加一群分布式执行者用声明式期望状态驱动整个系统不断靠拢。把这条主线揪住后面无论学习Service、Ingress、Helm还是Operator理解起来都会顺畅很多。