1.2 Kubernetes 架构概览：控制平面与数据平面

1. 先建立整体认知：Kubernetes 集群由谁组成？

从架构上看，一个 Kubernetes 集群由两大部分组成：控制平面（Control Plane）和承载业务的节点（Node）。官方文档将集群描述为“控制平面 + 一组运行容器化应用的工作机器”，每个集群至少需要一个工作节点来运行 Pod；控制平面负责管理节点与 Pod，而工作节点负责真正承载应用::cite[177].

如果把 Kubernetes 比作一家公司，那么控制平面更像“管理层与中枢系统”，负责下决策、存状态、发指令；数据平面更像“执行层”，负责把容器真正跑起来，并维持网络连通。理解这层分工，是后续学习所有对象行为的基础。

2. 控制平面：负责“想清楚”和“发命令”

官方文档指出，控制平面组件会对集群做全局决策，例如调度，也会检测并响应集群事件，例如当 Deployment 的副本数不满足时触发新的 Pod 创建::cite[177].

2.1 API Server：整个集群的统一入口

API Server 是 Kubernetes 控制平面的前端，它暴露 Kubernetes API，也是几乎所有组件和客户端交互的入口。你执行 kubectl apply、控制器写状态、调度器更新绑定结果，本质上都在和 API Server 通信::cite[177].

你可以把 API Server 理解成“集群大门 + 总服务台”：

接收用户或组件发来的请求；
做认证、鉴权、校验与准入处理；
把合法对象写入后端存储；
对外提供 watch 能力，让其他组件持续感知对象变化。

这也是为什么很多人会说：Kubernetes 是一个 API 驱动系统。因为整个集群的状态变化，最终都围绕 API 对象进行。

2.2 etcd：集群状态的“总账本”

etcd 是 Kubernetes 的后端一致性键值存储，可以把它理解成“集群事实的权威记录”。哪些 Pod 存在、Deployment 期望几个副本、某个节点当前是什么状态，最终都要落到这里::cite[177].

初学时你不必立刻深入 etcd 的细节，但要记住两点：

etcd 保存的是集群核心状态；
API Server 是主要入口，其他组件通常不直接绕过 API Server 去改状态。

也因此，备份 etcd、保障其可用性，是生产环境中的关键事项之一::cite[177].

2.3 Scheduler：决定 Pod 该去哪里运行

Scheduler 的职责非常直观：它持续关注“尚未分配节点的 Pod”，然后为这些 Pod 选择一个最合适的节点::cite[177].

这个“合适”并不是随机挑选，而会综合考虑很多因素，例如：

CPU / 内存等资源是否足够；
节点标签、亲和性与反亲和性；
污点与容忍度；
数据本地性；
其他调度策略约束。

所以，调度器解决的是“应该在哪跑”的问题，而不是“怎么把容器拉起来”。后者属于节点侧职责。

2.4 Controller Manager：负责持续纠偏

Controller Manager 会运行多个控制器进程。控制器的核心工作方式就是前一章提到的控制循环：看当前状态与期望状态是否一致，如果不一致，就想办法让它重新一致::cite[177].

最常见的例子包括：

Deployment 控制器：确保副本数正确；
Node 控制器：感知节点状态变化；
ReplicaSet 控制器：确保指定数量的 Pod 存在；
Job 控制器：保证任务执行直到完成或失败。

如果只记一句话，那就是：控制器负责“不断盯着结果是否对齐”。

3. 数据平面：负责“把应用真正跑起来”

工作节点承载的是实际业务负载。你可以把它理解成“应用执行现场”。Pod 会被调度到某个节点上，然后由节点中的组件接手，把容器创建出来、接入网络、上报状态::cite[177].

3.1 kubelet：节点上的代理人

kubelet 是运行在每个节点上的代理。它会持续读取分配到本节点的 Pod 规格，并确保这些 Pod 中描述的容器按预期运行。简单说，控制平面说“这里应该有一个 Pod”，kubelet 负责把这件事在本机落地::cite[177].

kubelet 典型会做这些事情：

监听发给本节点的 Pod 说明；
调用容器运行时创建容器；
执行探针与健康检查；
采集并回报 Pod 状态；
在容器异常时配合重启策略进行处理。

所以，kubelet 是连接“声明”和“执行”的关键桥梁。

3.2 容器运行时：真正运行容器的底层能力

容器运行时是节点上负责运行容器的软件，例如 containerd。Kubernetes 自己并不直接创建 Linux 进程或容器，它通过标准接口与容器运行时配合，由后者完成拉取镜像、创建容器、启动进程等工作::cite[177].

这也说明一个重要事实：Kubernetes 管理容器，但它并不是容器引擎本身。它更像是上层调度与控制系统，而真正执行容器生命周期的是运行时。

3.3 kube-proxy：让服务访问能够成立

kube-proxy 负责在节点上维护网络规则，这些规则使集群内部或外部流量能够按照 Service 抽象，被正确转发到后端 Pod::cite[177].

对于初学者来说，可以先把 kube-proxy 理解为：

Service 能“看起来像一个稳定入口”；
Pod 实例可能会变，但访问入口尽量稳定；
kube-proxy 通过节点网络规则帮助完成这种转发。

后面学到 Service、ClusterIP、NodePort 时，你会更清楚它的作用边界。

4. 控制平面与数据平面的职责边界

学习架构时，一个常见误区是把“谁决定”和“谁执行”混在一起。你可以用下面这张表来建立边界感：

维度	控制平面	数据平面
核心任务	存状态、做决策、持续纠偏	运行容器、汇报状态、维护节点网络
关注对象	集群全局	当前节点上的 Pod 与容器
典型组件	API Server、etcd、Scheduler、Controller Manager	kubelet、容器运行时、kube-proxy
回答的问题	应该运行什么？跑在哪里？目标是否达成？	容器有没有真正拉起？网络是否连通？状态是否正常？

如果再说得更直白一点：

控制平面负责“脑子”；
数据平面负责“手脚”。

很多线上问题，判断快不快，往往就取决于你能不能先定位：这是控制平面没决定好，还是数据平面没执行好？

5. 一个对象从提交到生效的完整链路

这一段非常关键，因为它把前面的组件串起来了。假设你提交一个 Pod YAML，链路通常可以这样理解：

第 1 步：用户提交对象

你执行：

kubectl apply -f pod.yaml

kubectl 会把 YAML 发送给 API Server。API Server 做认证、鉴权、校验和准入处理后，把对象写入存储体系::cite[177].

第 2 步：对象被持久化

对象进入 etcd 后，就意味着“目标状态”被正式记录下来了。此时系统已经知道：你想要一个什么样的 Pod，但它还未必已经在某个节点上真正运行::cite[177].

第 3 步：调度器发现待调度 Pod

如果该 Pod 还没有绑定节点，Scheduler 会观察到它，并为其选择一个满足资源和约束条件的节点，然后把绑定结果更新回 API Server::cite[177].

第 4 步：目标节点上的 kubelet 开始执行

被选中的节点上，kubelet 会看到“有一个 Pod 分配给我了”，于是读取 Pod 规格，调用容器运行时拉取镜像、创建并启动容器::cite[177].

第 5 步：网络规则与服务访问逐步就位

如果该 Pod 后续被 Service 选中，kube-proxy 会基于 Service 与 Endpoint 变化维护节点网络规则，使流量能够被转发到正确的后端 Pod::cite[177].

第 6 步：状态持续回报，控制器持续校正

容器运行后，kubelet 会不断把 Pod 状态回报给 API Server；若对象属于更高层控制器（例如 Deployment），控制器也会持续判断副本数、可用性等是否满足期望，不满足就继续纠偏::cite[177].

可以把它压缩成一句顺口的话：

用户声明目标 → API Server 接收 → etcd 存状态 → Scheduler 选节点 → kubelet 调运行时落地 → kube-proxy 维护访问路径 → 控制器持续纠偏。

6. 用一张“脑内图”理解整个架构

为了方便记忆，你可以把 Kubernetes 想成下面这个逻辑结构：

你 / kubectl
   ↓
API Server
   ↓
etcd（保存目标状态）
   ↓
Scheduler / Controllers（做决策、做纠偏）
   ↓
Node
 ├─ kubelet（执行）
 ├─ container runtime（运行容器）
 └─ kube-proxy（维护网络规则）

这张图虽然简化了很多细节，但非常适合入门阶段建立整体感。你后面无论学 Pod、Deployment、Service，还是排查“为什么没调度成功”“为什么镜像拉不下来”“为什么服务访问不到”，都可以回到这条链路来定位问题。

7. 本章小结

本章你需要真正掌握的，不是组件定义背诵，而是职责分层：

API Server 是统一入口；
etcd 存核心状态；
Scheduler 负责选节点；
Controller Manager 负责持续纠偏；
kubelet 在节点上执行 Pod；
容器运行时真正把容器跑起来；
kube-proxy 维护服务访问所需的网络规则。

当你把这几个角色放进“提交对象 → 存状态 → 做决策 → 执行落地 → 持续校正”的主链路里，Kubernetes 架构就不再是散乱的名词表，而是一套完整、可推演的系统模型::cite[177].

📝 版权声明：本文为原创技术博客，转载请注明出处。

如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！