从“大脑”到“肌肉”：一张图搞懂K8s集群组件架构
从“大脑”到“肌肉”：一张图搞懂K8s集群组件架构
本文专为初学者设计，用最通俗的语言拆解Kubernetes集群的各个组件，让你一次性搞懂它们各自是干什么的。
一、先记住一个比喻
如果把一个K8s集群比作一家大型物流公司：
控制平面（Control Plane）就是公司的总部——负责接单、调度、监控全局；
工作节点（Worker Node）就是各地的仓库和配送站——负责实际存放货物（运行容器）。
K8s集群由控制平面和工作节点两大部分组成。控制平面管理集群的整体状态，工作节点则承载实际运行的容器化应用。
下面我们逐一拆解每个组件。
二、控制平面（Control Plane）——“总部”的四大核心部门
控制平面负责做出集群的全局决策（比如把Pod调度到哪个节点），以及检测和响应集群事件（比如某个Pod挂了需要重新拉起）。它由四个核心组件组成：
🚪 1. API Server——唯一的前台接待
API Server是Kubernetes的核心组件，它公开了Kubernetes API，是整个控制平面的前端入口。
所有与集群的交互——无论是你用
kubectl敲的命令、其他组件的内部通信，还是外部系统的调用——都必须经过API Server。它负责认证、授权和校验每一个请求。
一句话总结：API Server是集群的“唯一大门”，所有人都得从这里进出。
💾 2. etcd——集群的“数据库”
etcd是一个一致且高可用的键值存储，用作Kubernetes所有集群数据的后台数据库。
集群的每一个状态——有哪些节点、跑了哪些Pod、配置了什么Service——全部保存在etcd里。API Server是唯一与etcd直接交互的组件。
一句话总结：etcd是集群的“记忆中心”，所有信息都记在这里。
📋 3. Scheduler——调度员
Scheduler负责监视新创建的、尚未分配节点的Pod，并为其选择一个最合适的节点来运行。
调度决策会综合考虑资源需求、硬件/软件策略约束、亲和性规范等多种因素。它不是随便乱选，而是“精打细算”地安排。
一句话总结：Scheduler是“调度员”，决定每个Pod去哪台机器上干活。
🔧 4. Controller Manager——自动化运维团队
Controller Manager运行着各种各样的控制器，负责实现Kubernetes API的各种行为。
每个控制器都是一个独立的过程，持续监控系统当前状态，一旦发现与期望状态不一致，就自动执行调整。比如：ReplicaSet控制器确保指定数量的Pod始终在运行；Deployment控制器管理滚动更新和回滚。
一句话总结：Controller Manager是“自动化运维团队”，确保集群始终按你的期望运行。
三、工作节点（Worker Node）——“一线员工”的三大标配
每个工作节点上都运行着三个核心组件，它们共同负责让容器真正跑起来。
👷 1. Kubelet——节点上的“监工”
Kubelet是运行在每个工作节点上的主要代理，它负责与API Server通信，确保节点上的容器按照PodSpec的定义正常运行。
Kubelet管理Pod的整个生命周期——创建、运行、健康检查、销毁——并定期向API Server报告节点和Pod的状态。
一句话总结：Kubelet是节点上的“监工”，负责管好本节点上的所有Pod。
🌐 2. Kube-proxy——网络规则维护员
Kube-proxy负责维护节点上的网络规则，实现Service的负载均衡和服务发现功能。
简单说，当你要访问某个Service时，kube-proxy帮你把请求正确地转发到后端的某个Pod上。
一句话总结：Kube-proxy是“网络交警”，保证流量走对路。
🐳 3. 容器运行时——真正“干活”的人
容器运行时是真正负责运行容器的软件，比如Docker、containerd或CRI-O。
Kubernetes通过容器运行时接口（CRI）与不同的容器运行时进行交互，这使得K8s可以灵活地支持多种运行时。
一句话总结：容器运行时是“一线搬运工”，真正把容器拉起来跑。
四、它们如何协同工作？（一个完整的请求流程）
假设你执行kubectl create deployment nginx --image=nginx：
kubectl将请求发给API Server；
API Server认证通过后，把这个“我要跑一个Nginx”的信息存入etcd；
Scheduler监听到有新的Pod需要调度，选一个合适的工作节点，把结果告诉API Server；
目标节点上的Kubelet收到指令，通知容器运行时拉取镜像并启动容器；
Controller Manager持续监控，确保这个Nginx Pod始终在运行（挂了就自动重建）。
💡关键点：所有组件都只与API Server通信，彼此之间不直接打交道。这种设计让各组件松耦合，便于独立升级和扩展。
五、给小白的一张速记表
| 组件 | 所属 | 一句话记忆 |
|---|---|---|
| API Server | 控制平面 | 唯一大门，所有请求都经过它 |
| etcd | 控制平面 | 集群数据库，存所有状态 |
| Scheduler | 控制平面 | 调度员，给Pod分配节点 |
| Controller Manager | 控制平面 | 自动化运维，维持期望状态 |
| Kubelet | 工作节点 | 节点监工，管理Pod生命周期 |
| Kube-proxy | 工作节点 | 网络交警，维护流量规则 |
| 容器运行时 | 工作节点 | 一线搬运工，真正跑容器 |
写在最后
K8s的组件虽多，但逻辑非常清晰：控制平面负责“想”和“管”，工作节点负责“做”。API Server是唯一入口，etcd是记忆中心，Scheduler做决策，Controller Manager保稳定，Kubelet和容器运行时负责执行。
把这几个角色搞清楚了，你就已经掌握了K8s架构的核心。剩下的，就是在实践中慢慢加深理解了。
📚延伸阅读：Kubernetes官方文档 - 组件概述（最权威的参考资料）