第19篇 Kubernetes 架构解读：控制平面与工作节点-编程实验室

IT策士 10余年一线大厂经验，专注 IT 思维、架构、职场进阶。我会在各个平台持续发布最新文章，助你少走弯路。

从这篇文章开始，我们正式进入了系列最核心的第三部分：Kubernetes 核心。在第 18 篇中，我们把 Compose 的每一个概念都映射到了 K8s 的对应对象上，你已经有了一张“概念翻译词典”。但有一个问题我们还没回答：Kubernetes 本身到底是怎么运作的？控制平面（Control Plane）是什么？工作节点（Worker Node）又是什么？当你在kubectl apply -f一个 YAML 时，集群内部到底发生了什么？

这些，就是今天要讲清楚的事情。理解了架构，后续每一篇学到的 Pod、Deployment、Service、Ingress，你都能在脑海中准确地“摆放”到对应的组件上，不再是一团模糊。

一、回顾：我们为什么需要一套新架构？

在第 18 篇中我们已经明确：Compose 只能管理单台宿主机上的容器，无法处理跨主机的自动调度、自愈、水平伸缩和滚动更新。这背后其实是一个更深层的架构问题——单机编排工具没有全局视角。Compose 只知道当前这台机器上有什么容器，如果容器挂了，它只能在本地重启；如果这台机器宕机了，它什么都做不了。

Kubernetes 解决这个问题的思路是：引入一个“大脑”（控制平面），让它掌握整个集群的全局信息，统一调度、统一监控、统一决策。

这个大脑由多个组件协作而成，下面我们来逐一拆解。

二、Kubernetes 集群全景图

一个 Kubernetes 集群由两类节点组成：控制平面节点（Control Plane Node）和工作节点（Worker Node）。

┌─────────────────────────────────────────┐ │ Control Plane │ │ │ kubectl ──────────────► ┌──────────────┐ ┌──────────────┐ │(客户端)│ API Server │ │ etcd │ │ │ └──────┬───────┘ └──────▲───────┘ │ │ │ │ │ │ ┌──────▼───────┐ ┌──────┴───────┐ │ │ │ Scheduler │ │ Controller │ │ │ │ │ │ Manager │ │ │ └──────────────┘ └──────────────┘ │ └─────────────────────────────────────────┘ │ ┌─────────────────────┼─────────────────────┐ │ │ │ ┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐ │ Worker │ │ Worker │ │ Worker │ │ Node1│ │ Node2│ │ Node3│ │ │ │ │ │ │ │ ┌────────┐ │ │ ┌────────┐ │ │ ┌────────┐ │ │ │kubelet │ │ │ │kubelet │ │ │ │kubelet │ │ │ └───┬────┘ │ │ └───┬────┘ │ │ └───┬────┘ │ │ ┌───▼────┐ │ │ ┌───▼────┐ │ │ ┌───▼────┐ │ │ │Container│ │ │ │Container│ │ │ │Container│ │ │ │Runtime │ │ │ │Runtime │ │ │ │Runtime │ │ │ └───┬────┘ │ │ └───┬────┘ │ │ └───┬────┘ │ │ ┌───▼────┐ │ │ ┌───▼────┐ │ │ ┌───▼────┐ │ │ │ Pods │ │ │ │ Pods │ │ │ │ Pods │ │ │ └────────┘ │ │ └────────┘ │ │ └────────┘ │ └────────────┘ └────────────┘ └────────────┘

控制平面（Control Plane）：集群的“大脑”，负责全局决策。它包括 API Server、etcd、Scheduler、Controller Manager 等组件。

工作节点（Worker Node）：实际运行业务负载的机器，运行着 kubelet、kube-proxy 和容器运行时，承载 Pod。

关于 Master 和 Control Plane：Kubernetes 早期将管理节点称为 Master，从 v1.20 起逐步弃用该术语，改用 Control Plane。两者指的是同一类节点。本系列后续统一使用 Control Plane 称呼。

三、控制平面组件详解

控制平面负责管理整个集群的状态，它的每一个组件都有明确的职责。

3.1 API Server（kube-apiserver）

一句话概括：集群的统一入口，所有操作都必须经过它。

API Server 是 K8s 中最核心的组件，它暴露了一组 RESTful API（通过 HTTPS），无论是你用kubectl下命令、控制器查询/更新资源，还是组件之间通信，全都通过 API Server 完成。

# kubectl 发出的每一个命令，底层都是向 API Server 发送 HTTP 请求kubectl get pods-v=6# 输出会显示完整的 HTTP 请求：# GET https://<api-server>:6443/api/v1/namespaces/default/pods

API Server 的核心职责包括：对请求进行认证（Authentication，验证你是谁）、授权（Authorization，验证你有什么权限）、准入控制（Admission Control，在写入 etcd 之前做最后的校验和修改）；将合法的资源对象写入 etcd 持久化存储；提供 Watch 机制，让其他组件可以监听资源变化（这是控制循环的关键）。

3.2 etcd

一句话概括：集群的“唯一真相来源”（Single Source of Truth），所有状态数据都存在这里。

etcd 是一个分布式键值存储系统，由 CoreOS 开发，基于 Raft 共识算法。所有 Pod 的定义、Service 的配置、节点的状态、RBAC 策略——这些数据全部持久化在 etcd 中。API Server 是无状态的，所有数据都依赖于 etcd。

etcd 的核心特性：

强一致性：基于 Raft 算法，集群中多数节点确认后才返回写入成功。
高可用：通常部署 3 个或 5 个节点（奇数个），容忍少数节点故障。
Watch 机制：客户端可以监听 key 的变化，这是 K8s 控制器模式的基础。

3.3 Scheduler（kube-scheduler）

一句话概括：决定 Pod 应该运行在哪台机器上。

当你创建一个 Pod 时，这个 Pod 只是被写入了 etcd，还没有被分配到具体的工作节点上。Scheduler 会不断监听 API Server，发现有未分配节点的 Pod，就启动调度流程。

调度过程分为两步：

过滤（Filtering）：排除不满足 Pod 需求的节点。比如 Pod 需要 2GB 内存，那内存不足的节点直接出局。
打分（Scoring）：对剩余节点按负载、亲和性、资源均衡度等策略打分，选出最优节点。

Scheduler 做出决定后，更新 Pod 对象的nodeName字段，然后该节点上的 kubelet 就会把这个 Pod“领取”过去。

3.4 Controller Manager（kube-controller-manager）

一句话概括：集群的“控制循环引擎”，持续调和实际状态与期望状态。

Controller Manager 不是一个单一的控制器，而是一堆控制器的集合。每个控制器负责一类资源的生命周期管理：Deployment Controller 管理 Deployment 和 ReplicaSet、Node Controller 监控节点健康状况、Service Controller 为 Service 创建负载均衡器、Job Controller 管理批处理任务。

控制器的工作模式是一个永不停歇的循环：从 API Server 获取期望状态 → 检查实际状态 → 采取行动让实际状态趋向期望状态。这就是 K8s 声明式管理的核心机制——你在 YAML 中声明“我要 3 个副本”，Deployment Controller 会不断检查，不够就创建，多了就删除。

3.5 Cloud Controller Manager（cloud-controller-manager）

一句话概括：让 K8s 与云平台交互的桥梁。

这个组件是可选的（自建集群通常没有），但在公有云环境中非常重要。它负责与云平台 API 交互，实现：节点管理（检测被删除的云主机并从集群移除）、路由管理（配置 VPC 路由）、负载均衡（为 LoadBalancer 类型的 Service 创建云 LB）。这样设计的好处是将 K8s 核心逻辑与云平台特定逻辑分离，不同云厂商只需实现自己的 Cloud Controller Manager。

四、工作节点组件详解

控制平面做出决策，而工作节点是真正运行业务负载的地方。

4.1 kubelet

一句话概括：每个节点上的“管家”，负责维护容器的运行状态。

kubelet 是工作节点上最核心的组件，每个节点都运行着一个 kubelet 实例。它会定期从 API Server 接收该节点应该运行的 Pod 清单，然后通过容器运行时（containerd/docker）确保这些容器正常运行。如果容器挂了，kubelet 负责重启；如果节点状态变化（如磁盘压力、内存不足），kubelet 会向控制平面报告。

# 在任意工作节点上查看 kubelet 状态sudosystemctl status kubelet

4.2 kube-proxy

一句话概括：实现 Service 的网络代理和负载均衡。

还记得第 18 篇我们说过，K8s 中的 Service 负责给一组 Pod 提供稳定的访问入口。kube-proxy 就是这个功能的实际实现者。它运行在每个节点上，通过维护 iptables 规则（或 IPVS）来确保：访问 Service 的 ClusterIP 的流量被转发到后端某一个健康的 Pod 上。

我们在第 8 篇学 Docker 网络时接触到的iptables，在 K8s 中同样承担着流量转发的重要角色。

4.3 Container Runtime（容器运行时）

一句话概括：真正运行容器的底层软件。

K8s 早期只支持 Docker，现在通过CRI（Container Runtime Interface）接口支持多种运行时：containerd（目前最主流）、CRI-O（Red Hat 主导）、Docker Engine（已弃用，需通过 cri-dockerd 适配）。我们在第 20 篇搭建 Minikube 时，默认使用的运行时就是 containerd。

五、一个 Pod 的完整旅程

理论讲完了，让我们追踪一个真实的请求，看看各个组件是如何协同工作的。

场景：你执行了kubectl create deployment nginx --image=nginx --replicas=3

kubectl → API Server：kubectl 将命令转换为 REST API 请求（POST /apis/apps/v1/namespaces/default/deployments），发送到 API Server。
API Server 认证与准入：API Server 验证你的身份（证书/Token），检查 RBAC 权限，通过准入控制器的规则校验，然后将 Deployment 对象写入 etcd。
Deployment Controller 创建 ReplicaSet：Deployment Controller 通过 Watch 机制发现新的 Deployment，读取期望副本数（3），创建一个 ReplicaSet 对象。
ReplicaSet Controller 创建 Pod：ReplicaSet Controller 发现新的 ReplicaSet，检查实际 Pod 数量（0），与期望数量（3）对比，创建 3 个 Pod 对象写入 etcd。
Scheduler 调度 Pod：Scheduler 发现 3 个未分配节点的 Pod，依次对每个 Pod 执行过滤和打分，选出最优节点，更新 Pod 的nodeName字段。
kubelet 启动容器：各节点上的 kubelet 监听到有新 Pod 分配给自己，调用容器运行时（containerd）拉取 nginx 镜像并启动容器。
kubelet 上报状态：容器启动成功后，kubelet 更新 Pod 状态为 Running，API Server 将状态写入 etcd。

这 7 步是 K8s 中几乎一切操作的标准流程。理解了这个流程，你就能在后续排查问题时快速定位故障点——是调度没找到节点？是镜像拉取失败？还是 kubelet 出了问题？

补充说明：上述流程描述的是命令式创建（kubectl create）。K8s 更推荐的日常操作是声明式应用（kubectl apply -f nginx-deployment.yaml），但提交后的组件交互流程完全一致——区别仅在于 kubectl 发送的 HTTP 方法是 PATCH（增量修改）而非 POST（创建新资源）。

六、控制器模式与控制循环：Kubernetes 的“心跳”

上面我们多次提到了“控制循环”和“控制器模式”，这是 Kubernetes 架构中最重要的设计模式。

// 控制器模式的伪代码（所有控制器都长这样）for{desiredState :=getDesiredState()// 从 etcd 读取期望状态 currentState :=getCurrentState()// 观察集群实际状态ifdesiredState!=currentState{makeChanges(currentState, desiredState)// 采取行动趋近期望状态}sleep(interval)}

所有控制器都是这个循环的变体。你在 YAML 中写replicas: 3，Deployment Controller 就不断地检查：“现在有几个 Pod 在跑？如果不够 3 个，就创建；如果超过 3 个，就删除。”正是这套控制循环，让 K8s 具备了自愈能力——节点宕机、Pod 被误删、配置被错误修改，控制器最终都会把集群扳回到你声明的期望状态。

“监听-比较-行动”这三个步骤，是 Kubernetes 声明式 API 能够工作的根基。在第 25 篇学习 Deployment 时，你会对这个模式有更切身的体会。

七、本篇总结

这一篇是 K8s 核心部分的“总纲”。在继续深入之前，确保你记住了这几个关键点：

控制平面（大脑）：API Server（统一入口）、etcd（数据存储）、Scheduler（调度 Pod）、Controller Manager（控制循环）——它们共同掌管集群的全局状态。
工作节点（手脚）：kubelet（节点管家，管理容器）、kube-proxy（网络代理，实现 Service）、Container Runtime（真正运行容器）——它们是命令的最终执行者。
Pod 创建流程：kubectl → API Server → etcd → Scheduler → kubelet → Container Runtime——这 7 步链路是 K8s 中最核心的交互流程。
控制器模式：K8s 的灵魂在于声明式——你声明期望状态，控制器持续调和。这个模式贯穿后续 30 篇的全部内容。

学架构的意义不在于记住每个组件名称，而在于后续遇到问题时，你能快速判断出“这是控制平面的问题还是工作节点的问题”、“是调度的问题还是网络代理的问题”。这也为下一篇文章——第 20 篇：搭建 Kubernetes 实验环境：Minikube 与 kubectl——打好了基础。下周，你将在自己的电脑上亲手启动一个 K8s 集群，用 kubectl 发出第一个命令，亲眼见证控制平面的组件如何协同工作。

想了解更多还可以去各个平台搜索「IT策士」，一起升级 IT 思维！