控制平面组件（apiserver / scheduler / controller-manager / etcd）
本教程共 65 篇 · 第 5 篇 · 更新于 2026-08-14 · 约 13 分钟阅读
本节目标：讲清楚控制平面的四个核心组件各自负责什么，以及它们是怎么配合干活、维持集群稳定的。
上一章说控制平面是集群的大脑。这章我们把这个大脑的”几个脑区”分别拆开看。记住一句话：所有写操作都先过 apiserver，所有状态都存进 etcd。
5-1 kube-apiserver：集群的唯一大门
kube-apiserver 是控制平面的核心，也是整个集群对外的唯一入口。你用 kubectl 敲的命令、别的组件之间的通信、甚至 Dashboard 的调用，统统经过它。
它的职责很清晰：
- 提供 Kubernetes 的 HTTP API。
- 做认证（你是谁）、鉴权（你能干啥）、准入控制（请求合不合规）。
- 把数据写进 etcd，或从 etcd 读出来。
Note因为所有写请求都汇总到 apiserver，它本身要做水平扩展、做高可用就很关键。生产环境一般会在多台机器上各跑一个 apiserver 实例，前面挡个负载均衡器。
你可以把 apiserver 想成银行的”综合柜台”：所有业务都从这儿进，它再转给后台各系统。别的组件不直接互相喊话，都通过 apiserver 传话。
5-2 etcd：集群的账本
etcd 是一个分布式、高可用的键值（key-value）数据库。它存的是集群所有状态的真相来源（Source of Truth）。
比如：现在有几个节点、跑着哪些 Pod、每个 Pod 什么状态、配了哪些 Service……全在 etcd 里。apiserver 是唯一能直接读写 etcd 的组件，其他组件想改状态，都得先找 apiserver。
etcd 有两个关键词要记住：
- 一致（Consistent）：多个副本之间数据强一致，不会出现”这台说有、那台说没”。
- 高可用（Highly-available）：通常部署奇数个（3、5、7）节点，挂掉一两个还能正常工作。
Warningetcd 是集群的命根子。它一旦数据损坏又没备份，集群状态可能全乱。生产环境一定要给 etcd 做定期备份，这是运维的基本功。
5-3 kube-scheduler：决定 Pod 去哪台机器
scheduler（调度器）干的事很专一：盯着那些”还没分配到 Node 的 Pod”，给每个 Pod 挑一台最合适的机器。
它怎么挑？两步走：
- 过滤（Filter）：先排除不合适的 Node。比如机器资源不够、有污点不允许这类 Pod、节点标签不匹配，直接筛掉。
- 打分（Score）：对剩下的 Node 打分，谁更合适（资源更均衡、亲和性更匹配）给高分，选最高的。
Tip调度只看”能不能放、放哪更好”，它不负责把容器真正跑起来——那是 kubelet 的活。分工很明确。
顺带一提，k8s 的调度器是可替换的。你可以写自己的调度器，或者装第三方的，和默认调度器并存。
5-4 kube-controller-manager：让现状追上期望
controller-manager 是”一堆控制器的集合”。每个控制器盯着一类资源，负责把”实际状态”往”期望状态”上拉。
官方文档举了几个例子：
- Node 控制器：节点挂了，它负责发现并响应。
- Job 控制器：看到有 Job 任务，就创建 Pod 把它跑完。
- EndpointSlice 控制器：维护 Service 和 Pod 之间的对应关系。
- ServiceAccount 控制器：给新命名空间建默认的 ServiceAccount。
Note“控制器”这个名字听着玄，其实是”不断重试直到对为止”的循环。它每时每刻都在问：现在的状态，和我要的状态一样吗？不一样就动手改。这正是 k8s 自愈能力的来源。
5-5 cloud-controller-manager：云厂商的翻译官
最后一个组件比较特殊：cloud-controller-manager。它只在”集群跑在云上”时才需要。
它的作用是把 k8s 和云厂商的能力对接起来。比如：
- 节点控制器：去云上确认某台虚拟机是不是真没了。
- 路由控制器：在云网络里配路由。
- Service 控制器：在云上创建、更新、删除负载均衡器。
Tip如果你在自己电脑上用 minikube 或 kind 学习，集群里没有 cloud-controller-manager。别奇怪，因为本地环境不接云厂商。
5-6 它们怎么配合
把上一章那个”建 Pod”的流程用组件语言再讲一遍：
- 你提交创建请求 → apiserver 收下，写进 etcd。
- scheduler 发现新 Pod 没归属，挑好 Node，把结果写回 apiserver/etcd。
- 目标 Node 的 kubelet 被通知到位，拉起容器。
- controller-manager 持续校核：副本数对不对、节点在不在、Service 映射好不好。
一切以”循环校核、逼近期望”为准则。这套机制稳定、可预测，正是 k8s 可靠的根基。
5-8 用一个例子串起全部组件
光讲职责还是有点虚，我们拿”部署一个 nginx”走一遍组件协作，你就全通了：
- 你敲
kubectl create deployment nginx --image=nginx。 - apiserver 收到请求，校验权限后，把”要一个 nginx Deployment”写进 etcd。
- scheduler 发现有 Pod 待调度，按资源打分，选了节点 Node-A，把结果写回 etcd。
- Node-A 上的 kubelet 被通知，请容器运行时拉起 nginx 容器。
- controller-manager 里的 Deployment 控制器盯着：副本数是 1 吗？是。状态对了，不动。
- 你改
replicas为 3，controller-manager 发现差 2 个，立刻补建 2 个 Pod，重新走一遍 3–5。
你看，五个组件像一条流水线，各管一段，靠 etcd 这个账本同步信息。理解了这条线，k8s 就不再是黑盒。
Tip排错时也可以顺着这条线想：请求到 apiserver 了吗？etcd 写进去了吗？scheduler 分配了吗？kubelet 拉起了吗？逐段排查，定位会快很多。
小结
四句话再强调：apiserver 是大门、etcd 是账本、scheduler 管往哪放、controller-manager 管补到对。它们围着 apiserver 转、以 etcd 为真相来源。云上才有的 cloud-controller-manager 负责对接厂商能力。
下一章，我们把视角移到工作节点，看看 kubelet、kube-proxy 和容器运行时这三个”一线打工人”。