集群架构：控制平面与工作节点

集群不是一台机器#

上一章我们说，Kubernetes 的职责是「让现实不断向期望靠拢」。真正干这件事的不是一个程序，而是一组组件，分布在两类机器上：控制平面（control plane）负责做决定，工作节点（worker node）负责干活。

你敲的 kubectl 命令既不直接操作容器，也不直接跟节点说话，它只是把 YAML 交给集群的入口，剩下的由内部组件接力完成。

理解这套分工很实用：以后遇到节点 NotReady、Pod 卡在 Pending、Service 访问不通，你能立刻判断该去看哪一层，而不是盲目重启所有东西。

kubectl / CI / 其他客户端
        │ HTTPS
        ▼
  kube-apiserver ──────────► etcd（唯一持久化存储）
        ▲
        │ watch / 读写
        ├── kube-scheduler
        ├── kube-controller-manager
        └── cloud-controller-manager（可选，本地集群没有）
        │
        │ 节点上的 kubelet 通过 apiserver 领任务
        ▼
   kubelet ──► containerd ──► 容器
   kube-proxy ──► Service 的转发规则

注意这张图里所有箭头都指向 apiserver：没有组件会绕过它直接改 etcd。

控制平面：做决定的那一层#

kube-apiserver 是所有客户端唯一的对话对象。它本身几乎不保存状态，只做三件事：认证（你是谁）、鉴权（你能不能做）、准入控制（这个对象合不合法），然后把对象写进 etcd。正因为它无状态，生产环境可以同时跑多个实例，前面挂一个负载均衡。

etcd 是集群的「唯一真相来源」。你创建的每一个对象——Pod、Service、ConfigMap——最终都序列化存在这里；apiserver 通过 watch 机制把变化推送给其他组件。etcd 一旦不可用，集群就失去了记忆：已经在跑的容器还在跑，但任何查询、调度和变更都会失败。生产上 etcd 通常单独部署在低延迟 SSD 上，并盯住磁盘 fsync 延迟，因为所有写请求都要落盘才返回。

kube-scheduler 只干一件事：给 spec.nodeName 为空的 Pod 选一个节点。它先过滤掉资源不足、污点不匹配、亲和性不符的节点，再给剩下的节点打分，最后把绑定结果写回 apiserver。它不负责启动容器，只是写下「这个 Pod 应该去哪个节点」。

kube-controller-manager 把一批控制器打包在一个进程里运行：Deployment 控制器保证副本数、ReplicaSet 控制器创建 Pod、Node 控制器处理节点失联、EndpointSlice 控制器维护 Service 的后端列表。上一章提到的「控制器」，绝大多数跑在这个进程里。每个控制器都是同一个套路：watch 一类对象，比较期望与实际，然后采取动作。

cloud-controller-manager 是可选的，把与云厂商耦合的逻辑拆出去，比如创建云负载均衡、给节点打标签、管理云上路由。本地 kind / minikube 集群没有这个组件。

哪个组件挂了会怎样#

这个表格能帮你在出问题时快速缩小范围。学习环境里不用背，但排错时非常省时间：

注意最后两行：节点和 DNS 属于「Pod 已经跑起来之后」才暴露的问题，很容易被误判成应用故障。判断时先看 kubectl get nodes，再看 kubectl get pods -A，顺序不要颠倒。

单节点与高可用控制面#

学习用的 kind、minikube 默认是单节点集群：一个节点同时承担控制平面和工作节点的角色。它足够学完本课程，但控制平面一挂，整个集群就无法调度和变更了。

生产集群的做法不同：控制平面至少 3 个节点，etcd 用 3 或 5 个成员（奇数是为了在出现网络分区时还能选出多数派），多个 apiserver 实例前面挂一个负载均衡 VIP，kubelet 和 kubectl 都连这个 VIP。工作节点可以随时增删，控制平面则要谨慎维护。

一句话总结：控制平面里只有 etcd 是有状态的，apiserver、scheduler、controller-manager 都可以多副本；所以要小心对待的是 etcd，而不是 apiserver。

工作节点：真正跑容器的那一层#

节点上只有三个常驻角色，但它们是容器真正跑起来的地方。

kubelet 是节点上的工头。它通过 apiserver 领到自己节点上「应该跑哪些 Pod」，调用容器运行时把容器拉起来，按 livenessProbe / readinessProbe 执行健康检查，并持续上报节点与 Pod 状态。kubelet 不参与调度决策，它只执行「分配给我」的结果。

容器运行时 负责拉镜像、创建容器、管理命名空间和 cgroups。现在主流是 containerd，kubelet 通过 CRI（Container Runtime Interface）跟它说话。Docker 本身不再直接参与，它只是能构建出符合 OCI 标准的镜像。

kube-proxy 把 Service 的虚拟 IP 翻译成节点上的转发规则（iptables 或 IPVS 模式），让访问 Service 的流量能落到某个 Pod 上。它只做转发，不做负载均衡决策之外的复杂逻辑。现在很多集群用 Cilium 这类基于 eBPF 的方案直接替代它，把 Service 转发和网络策略一起接管。

kubelet 还会定期向 apiserver 上报节点心跳。默认情况下，超过约 40 秒没有心跳，Node 控制器就把节点标记为 NotReady；再持续一段时间（默认约 5 分钟），就会开始驱逐上面的 Pod，把它们重新调度到健康节点上。你不需要手动搬运 Pod，这套机制是自动的。

集群附加组件#

控制平面和节点组件只保证「Pod 能跑起来」，要让应用好用，还需要几个附加组件。它们通常装在 kube-system 命名空间，或者由你自己部署到别的命名空间。

CoreDNS 是必装项：没有它，Pod 之间只能靠 IP 互相访问。CNI 也是必装项：没有它，Pod 连 IP 都拿不到，会一直卡在 ContainerCreating。

动手：看清你的集群里跑着什么#

kubectl get nodes
kubectl get nodes -o wide
kubectl get pods -n kube-system -o wide

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl get daemonsets -n kube-system

一条 kubectl apply 之后发生了什么#

这是本章最值得记住的链路。假设你提交了一个 Pod 清单：

1. kubectl 把 YAML 转成 JSON，向 kube-apiserver 发起 HTTPS 请求，例如 POST /api/v1/namespaces/demo/pods。
2. apiserver 完成认证、鉴权、准入校验，补全默认值（比如 restartPolicy: Always），把对象写入 etcd。
3. etcd 持久化成功并返回，apiserver 告诉 kubectl「创建成功」。此刻容器还没有开始跑。
4. 控制器（如果你提交的是 Deployment，就是 Deployment 控制器）通过 watch 感知到新对象，发现期望副本数与实际不一致，创建 ReplicaSet，再由 ReplicaSet 控制器创建 Pod 对象。
5. kube-scheduler 看到这个 Pod 的 spec.nodeName 是空的，经过过滤和打分选出节点，把绑定结果写回 apiserver。
6. 该节点上的 kubelet watch 到「有一个 Pod 分配给我」，调用容器运行时（containerd）拉镜像、创建并启动容器。
7. kubelet 把 Pod 状态（Running、Pod IP、就绪情况）上报给 apiserver 并写入 etcd，你才能从 kubectl get pods 里看到 Running。

如果链路在第 6 步断掉，通常是镜像拉不下来，Pod 会停在 ImagePullBackOff；如果第 4、5 步出问题，Pod 会长时间停在 Pending。后面几章的排错，基本都在定位这条链路的哪一段卡住了。

把这条链路画成时序图，看的是「谁在什么时候动」：

kubectl apply -f pod.yaml
   │ ① HTTPS 请求
   ▼
kube-apiserver ──② 写入──► etcd
   │ ③ etcd 写入成功，apiserver 返回 created（此刻容器还没跑）
   │
   │ ④ watch 事件推送给控制器
   ▼
控制器（Deployment → ReplicaSet → Pod）
   │
   ▼
kube-scheduler ⑤ 过滤 + 打分，写回 spec.nodeName
   │
   ▼
kubelet ⑥ 调 containerd 拉镜像、创建并启动容器
   │
   ▼
kubelet ⑦ 上报 Pod 状态 ──► apiserver ──► etcd
   │
   ▼
kubectl get pods 里终于看到 Running

注意 ③ 和 ⑦ 之间的时间差：`kubectl apply` 返回 `created` 只代表对象进了 etcd，不代表容器已经在跑。想观察这段过程，用 kubectl get pods -w 盯着状态变化。

常见坑#

自测题#

小结#

• 控制平面做决定：apiserver 是唯一入口，etcd 存全部状态，scheduler 挑节点，controller-manager 负责把现实拉回期望。
• 工作节点干活：kubelet 领任务并上报状态，containerd 真正起容器，kube-proxy 维护 Service 的转发规则。
• 附加组件补齐能力：CoreDNS 做服务发现，CNI 打通网络，metrics-server 提供指标，Ingress Controller 接入外部流量。
• 一条 kubectl apply 的链路是：apiserver → etcd → 控制器 → 调度器 → kubelet → 容器运行时。
• 单节点适合学习，生产要 3 个以上控制平面节点，并把 etcd 的磁盘性能当成第一优先级。

相关章节：动手把集群装起来看 第 3 章 kind 与 kubectl 上手；真机上排障的分层判断见 第 15 章 排障手册。

练习#

1. 在你的集群上跑 kubectl get pods -n kube-system -o wide，把每个 Pod 归到「控制平面组件」「节点组件」「附加组件」三类里。
2. 用 kubectl describe node <你的节点名> 找到 Conditions 一节，查清 Ready、MemoryPressure、DiskPressure 分别代表什么。
3. 想一下：如果 etcd 的数据盘写满了，集群会先表现出什么症状？是「能查到对象」还是「写不进去」？

下一章我们把这样一个集群装到自己电脑上，从零开始，直到 kubectl get nodes 返回 Ready。