k8s 整体架构总览

前面几章我们认识了 Pod、Node、Cluster。这一章把镜头拉远，看整个集群的”骨骼”长什么样。

4-1 两大平面：大脑和手脚

一个 Kubernetes 集群，从架构上只分两大部分：

• 控制平面（Control Plane）：集群的大脑，负责做决策——调度、状态管理、对外接口。
• 工作节点（Node）：真正干活的机器，负责把 Pod 跑起来。

你可以这样想：控制平面是工厂的总调度室，工作节点是一线车间。总调度室不下车间搬货，但它决定谁去哪、什么时候停、出了事怎么补。

4-2 控制平面里有什么

控制平面由几个核心组件组成，它们各管一摊：

• kube-apiserver：整个集群的唯一入口，所有操作都通过它。相当于前台兼总机。
• etcd：一个高可用的键值数据库，存着集群所有的状态。相当于集群的”账本”。
• kube-scheduler：调度器，负责把新来的 Pod 安排到合适的 Node 上。
• kube-controller-manager：一堆控制器的集合，负责让集群现状逼近期望状态。
• cloud-controller-manager：跟云厂商打交道的组件（本地学习环境没有它）。

这几个组件下一章会逐个细讲。这章你只要知道”它们都在控制平面里、各司其职”就够了。

4-3 工作节点上有什么

每个 Node 上固定跑着三样东西：

• kubelet：节点上的”驻场管家”，盯着本机的 Pod，确保它们按预期运行。
• kube-proxy：负责网络转发，让 Service 的流量能正确到达 Pod。
• 容器运行时（Container Runtime）：真正拉起容器的软件，比如 containerd、CRI-O。

4-4 一次调度，发生了什么

光列组件太干，我们用一个真实场景串一遍。你敲下命令创建一个 Pod：

1. 命令经 kubectl 发给 kube-apiserver。
2. apiserver 把”要建一个 Pod”这件事写进 etcd 账本。
3. kube-scheduler 发现有个 Pod 还没分配 Node，根据资源、亲和性等规则挑一台合适的机器。
4. 被选中的 Node 上的 kubelet 收到指令，请 容器运行时 把容器拉起来。
5. kube-controller-manager 持续盯着：Pod 真的起来了没？数量对不对？不对就纠正。
6. 用户的请求进来时，kube-proxy 负责把流量转到这个 Pod。

你看，一次简单的”建 Pod”，其实五大组件在背后接力完成。

4-5 组件怎么部署都行

官方文档特意强调：这些组件怎么摆，很灵活。

• 控制平面可以跑在普通机器上（systemd 服务）。
• 也可以以”静态 Pod”方式由 kubelet 管起来（kubeadm 就是这么干的）。
• 还可以让控制平面自己跑在集群里（自托管）。
• 云上的托管 k8s（如 GKE、EKS、ACK）则把控制平面藏起来，你只管用。

不管怎么摆，组件的职责不变。这是 k8s 架构”松耦合”的体现。

4-6 插件补足能力

光有核心组件，集群还缺一些便利功能，靠**插件（Addons）**补上。常见的有：

• DNS：集群内部的域名解析，很多功能依赖它。
• Dashboard：网页版管理界面。
• 监控与日志：收集容器指标和日志。
• 网络插件（CNI）：给 Pod 分配 IP、打通 Pod 间通信。

插件本身也是用 k8s 资源（Deployment、DaemonSet）实现的，多住在 kube-system 这个命名空间里。

4-7 这章你该记住什么

合上眼，能在脑子里画出这个结构：

            ┌──────────── 控制平面 ────────────┐
            │  apiserver  etcd  scheduler      │
            │  controller-manager (云相关另算)  │
            └──────────────────────────────────┘
                        │ 指挥
            ┌───────────┴────────────┐
         Node 1                      Node 2 ...
       [kubelet kube-proxy 运行时]  [kubelet kube-proxy 运行时]
          └─ Pod ── Container         └─ Pod ── Container

大脑管决策，手脚管执行，中间靠 apiserver 串起来。

4-8 控制平面怎么做到高可用

生产环境里，控制平面绝不能”一损俱损”。常见做法是把几个核心组件各跑多个副本：

• apiserver：无状态，可以横向扩多个，前面挡负载均衡器。
• etcd：本身就设计成奇数节点的分布式集群（3/5/7），靠投票保证一致。
• scheduler / controller-manager：同一时刻只允许一个”活跃”实例做决策，其余待命，通过选主（leader election）避免脑裂。

而工作节点通常也会多台部署。这样任意单台机器挂了，集群整体照常运转。这正体现了 k8s 架构”没有单点”的设计取向。

4-9 为什么是这种分层结构

k8s 把”决策”和”执行”彻底分开，好处很明显：

• 节点可以随便加、随便换，只要上面三件套在，就能加入集群。
• 控制平面集中管状态，节点只管干活，职责单一、好排查。
• 所有写操作都过 apiserver，审计、权限、准入都能统一卡一道。

这种”大脑—手脚”的清晰边界，是 k8s 能管成千上万台机器还不乱的根本原因。

下一章，我们把控制平面里的组件一个个拆开讲透。