Kubernetes 架构概览：别把控制面当魔法

初学 Kubernetes 时，很多人会被眼花缭乱的架构图和一堆 kube-* 进程吓退。其实不管这套系统有多么庞大，它的架构本质上只分为两层：做决策的控制平面（Control Plane），以及干脏活的节点（Node）。

如果你在线上排查过“明明改了 YAML，但 Pod 怎么就是不更新”这种灵异事件，你就必须在大脑里建立起这两层的清晰边界。

控制平面的核心模块（决策层）

控制平面的组件全都是无状态或者极简状态的守护进程（除了 etcd）。如果你的集群“大脑”出问题了，往往发生在这里。

• API Server（全场枢纽）：整个集群里唯一允许直接读写 etcd 的组件，其他所有组件的通信、鉴权、数据请求都要强制走它。如果你执行 kubectl 指令一直超时，不用怀疑，多半是 API Server 负载太高或者挂了。
• etcd（持久化大脑）：存储集群唯一的真实状态。一旦等它出了问题（比如网络分区、磁盘 I/O 阻塞导致心跳超时），整个集群的读写都会进入脑裂或阻塞状态。
• Scheduler（干算力的调度员）：只干一件事——发现有没有绑定节点的 Pod（通常是 Pending 状态），然后通过亲和性、资源 requests 等一系列公式算出一个最合适的节点，通过 API Server 把它“画”在 etcd 里。
• Controller Manager（不知疲倦的包工头）：它是整个声明式系统的核心引擎。实际上它内部包含了各种小控制器（Node Controller, ReplicaSet Controller）。它永不停歇地对比“你期望的状态”和“现在实际的状态”，只要不一致，它就发号施令去推平差异。

节点层面的干活主力（执行层）

每个跑业务的 Worker 节点上，都有这三个劳模在默默兜底。如果你排障时发现只有一台节点上的应用全军覆没，那多半是它们罢工了。

• kubelet（节点大管家）：也是最重要的组件，它向控制面汇报节点健康度，并负责跟底层容器运行时（Containerd/CRI-O）对接，硬生生把容器拉起来。如果是 OOMKilled 或者镜像拉不下来，去查这台机器上 kubelet 的日志准没错。
• kube-proxy（流量路由小队长）：它不真的转发流量（除非跑在耗费性能的 user-space 模式），它的正经工作是监听 API Server 的 Service 和 Endpoints 变化，然后偷偷去改机器上的 iptables 或 IPVS 规则。如果你发现 Pod 活着但 Service 连不上，去查网络侧的 kube-proxy 拓扑。
• CNI / CSI（挂载网线与磁盘的泥瓦匠）：Kubernetes 极其聪明地把网络栈（比如 Calico/Flannel）和存储接口解耦了出来，交给了这些标准插件去接管。

建立排障心智模型：控制回路（Control Loop）

Kubernetes 与过去那套服务器运维（Ansible 写死一台台机器去跑脚本）最根本的区别，在于声明式设计与控制回路。

当你执行了一个 kubectl apply -f deployment.yaml，千万不要以为系统当场就帮你把进程启好了，它的真实微观流转是：

1. kubectl -> API Server：请求写入 etcd 成功，告诉你 Created。
2. Controller Manager 监听到了新的 Deployment，一看发现没建 ReplicaSet，于是创建一个 3 副本的 ReplicaSet。
3. ReplicaSet Controller 发现有 3 个期望副本，但现在是 0 个，于是向 API Server 注册 3 个闲置的 Pod。
4. Scheduler 发现这 3 个 Pod 没有绑定节点属性（nodeName 为空），噼里啪啦算完分之后，把节点名字填进了它们的 Spec 里。
5. 这个名字对应的那台服务器上的 kubelet 一直在轮询自己节点需要负责的 Pod 列表。它猛然发现多了几个属于自己的任务，于是立刻呼叫底层的 Containerd 开始拉镜像、接网线、跑探针，最后变为 Running 状态。

结语：为什么这套模型能赢？

理解这条漫长并且极其分布式的事件流，这不仅是理解架构，更是日常排障的“破案地图”。

当部署卡住了，顺着上面的流转想一想：

• 如果状态一直卡在 Pending？说明前面都成了，但在第 4 步卡住了，去 kubectl describe pod 看看 Scheduler 抱怨什么（多半是资源不足、亲和性互斥）。
• 如果状态是 ContainerCreating？说明前 4 步都过了，目前卡在第 5 步 kubelet 身上。你得去看节点层网络或者是否有拉镜像的权限问题。

永远把对象状态当做你与集群交互的唯一桥梁。 把“找问题出在哪里”变成“判断断链发生在哪个组件的循环里”，这就是进阶工程师和初级使用者的本质分水岭。