别再死记硬背了！一条主线彻底搞懂 Kubernetes 全景视图架构

很多人学 K8s 的路子是这样的：背 API Server、背 etcd、背 Scheduler……背完了还是不知道它们怎么配合工作。本文换一条路——从系统自动运转的视角，把所有组件串成一条流水线，理解了这条线，K8s 就真的懂了。

先把答案亮出来

Kubernetes 的核心目标只有一句话：

让集群的「现实状态」不断逼近你定义的「期望状态」。

这不是废话，这是 K8s 整个设计哲学的根基。

它不是一个"你说什么它做什么"的命令执行系统，而是一个会自己对账、自己修复偏差的自动控制系统。你只需要告诉它"我要什么"，它会一直努力把现实调整到和你的要求一致——哪怕中途有节点挂掉、有容器崩溃。

带着这个认知，再来看各个组件，就不再是孤立的名词了。

组件速览：流水线上的各司其职

K8s 的组件分两大阵营：Master 控制平面和Node 工作节点。

控制平面（Master）

工作节点（Node）

附加核心组件

一条命令，串联所有组件

光知道组件还不够。我们来追踪一次kubectl apply -f nginx.yaml的完整旅程，看看这条流水线是怎么转起来的。

第一步：提交期望

kubectl apply -f nginx.yaml

你执行这条命令，kubectl 把 YAML 里描述的"我要 3 个 nginx Pod"打包成一个 HTTP 请求，发给API Server。

第二步：验证 + 落账

API Server 收到请求后做两件事：

1. 认证鉴权：你有没有权限做这件事？
2. 写入 etcd：验证通过，把"期望状态（3 个 nginx）"写进账本。

注意：此时 Pod 并没有被创建。API Server 只是记录了你的"意图"，什么都还没发生。

第三步：发现差异

Controller Manager在后台一直跑着一个死循环（控制循环），不断问自己：

"etcd 里说要 3 个 nginx Pod，现在实际有几个？"

刚才的状态是 0 个，期望是 3 个——差异出现了！Controller Manager 立刻动手：创建 3 个 Pod 对象，写回 etcd（此时 Pod 处于Pending状态，还没有被分配节点）。

第四步：调度决策

Scheduler也盯着 etcd，发现有 3 个没有nodeName的 Pod，它的任务来了：

对所有可用 Node 依次做过滤（这台机器资源够不够？有没有污点？）和打分（哪台机器最合适？），最终为每个 Pod 选出一个最优节点，更新 etcd。

Scheduler 只做决策，不动手执行，这是关键。

第五步：执行 + 闭环

Node 上的kubelet定时轮询 API Server（或通过 Watch 机制）：

"有没有分配给我的新任务？"

发现有新 Pod 了！kubelet 调用Container Runtime（如 containerd）拉取镜像、创建容器。容器起来后，kubelet 把"3 个 Pod 已运行"的状态上报给 API Server，更新 etcd。

至此，期望状态 == 现实状态，控制循环安静下来——直到下次出现偏差。

第六步：网络访问

如果你创建了一个 Service，kube-proxy会在每台 Node 上同步 iptables/IPVS 规则。

访问 Service 的固定 ClusterIP → 规则命中 → 流量被负载均衡到后端动态变化的 Pod IP。

就算某个 Pod 挂掉、被替换，Service IP 不变，外部访问无感知。

整条流水线，一图看懂

kubectl apply │ ▼ API Server ─── 认证/鉴权 ──▶ etcd（写入期望状态） │ ┌───────────┤ │ │ Controller Manager │ 发现差距 → 创建 Pod 对象 │ │ Scheduler ──────────┘ 绑定 Node │ kubelet（Node） │ Container Runtime │ 容器运行 → 状态上报 → etcd（期望 == 现实）

三条设计哲学

理解了流水线，再提炼三条 K8s 的设计哲学，会有更深的共鸣：

1. 声明式（Declarative）

你只声明"我要什么"，不说"怎么做"。replicas: 3就是声明，K8s 自己想办法实现。对比命令式（docker run），声明式天然支持幂等和自愈。

2. 控制循环（Control Loop）

Controller Manager 的工作本质是一个死循环：

while true: 现实 = 读取当前状态() 期望 = 读取期望状态() if 现实 != 期望: 执行修正动作() sleep(一小会儿)

这个循环是 K8s 自愈能力的底层机制。

3. 最终一致性（Eventual Consistency）

K8s 不保证"马上成功"，但保证"最终收敛"。节点重启、网络抖动、镜像拉取慢……这些都是暂时的偏差，系统会持续尝试，直到状态对齐。

总结

学 K8s，不需要把每个组件的参数背得滚瓜烂熟。先建立系统视角，再深入细节——那时候你会发现，很多设计都顺理成章，不需要死记。