想要快速掌握 Kubernetes 架构，最稳妥的路径是先区分控制平面与工作节点，再逐个识别核心组件的职责，不要一开始就陷入网络插件或存储细节。
先说结论：Kubernetes 架构核心是控制平面负责决策，工作节点负责执行，理解这一分工是入门的关键。
- 适合：刚接触容器编排的开发者或运维人员，需要建立全局视角。
- 先看：控制平面组件（API Server、etcd、Scheduler、Controller）与工作节点组件（kubelet、kube-proxy）。
- 建议：结合官方文档概念图与现有集群的组件列表对照学习，避免纸上谈兵。
命令速用版
如果你手头有一个可用的集群，可以通过以下命令观察实际运行的架构组件，这比单纯看图更直观：
kubectl get pods -n kube-system查看控制平面组件状态：
kubectl get componentstatuses查看节点角色与状态：
kubectl get nodes为什么会这样
Kubernetes 采用主从分布式架构，设计思想是控制面管理、数据面执行。控制平面作为集群的「大脑」，负责全局决策、调度和状态存储，不直接运行业务容器。工作节点作为「手脚」，负责实际运行 Pod 并接收控制平面指令。这种分离确保了集群可以水平扩容，且控制平面故障不会直接影响已运行容器的存活。
所有组件通过 API Server 进行通信，状态最终持久化到 etcd 中。这种声明式 API 设计让用户只需描述「期望状态」，控制器负责自动调和至该状态。
分步处理
1. 识别控制平面组件
控制平面通常包含以下核心服务，生产环境需高可用部署：
- kube-apiserver：集群唯一入口，处理所有资源操作请求，提供认证授权。
- etcd：高可用键值存储，保存集群所有核心元数据，丢失会导致集群不可用。
- kube-scheduler：负责监视新创建的 Pod，为其选择最合适的节点。
- kube-controller-manager：运行控制器进程，维护集群状态（如副本数、节点故障）。
2. 识别工作节点组件
每个工作节点必须运行以下组件才能接纳负载：
- kubelet：节点代理，确保容器按预期运行，上报节点状态。
- kube-proxy：网络代理，维护节点网络规则，实现 Service 负载均衡。
- 容器运行时：如 containerd 或 Docker，负责镜像管理和容器执行。
3. 理解通信流程
控制平面和数据平面之间通过 kube-apiserver 通信，节点主动向 Master 上报状态，所有通信基于 HTTPS 加密。
怎么验证是否生效
学习架构是否到位，可以通过以下方式进行自我验证：
- 绘图能力：能否在白纸上画出控制平面与工作节点的连接关系，并标出各组件名称。
- 流程口述：能否清晰描述「创建一个 Pod」的过程中，kubectl、apiserver、scheduler、kubelet 各自做了什么。
- 故障预判：当 etcd 不可用时，能否判断出集群无法创建新资源但已有容器可能继续运行。
常见坑
- 忽略 etcd 备份：etcd 存储集群状态，公开资料中没有看到可靠的量化数据表明恢复难度，但共识是丢失即集群不可用，必须制定备份计划。
- 控制平面运行负载：虽然控制平面节点技术上可以运行 Pod，但通常建议排除非关键工作负载，以免资源竞争影响集群稳定性。
- 混淆网络组件：kube-proxy 负责服务代理，而 Pod 间跨节点通信通常依赖 CNI 插件（如 Flannel、Calico），两者职责不同。
- 单点故障：学习环境中常使用单节点控制平面，但生产环境控制平面通常跨多机器运行以提供容错。
参考来源
- 你的知识库 - 了解 Kubernetes 主体架构 (二十八)
- 你的知识库 - Kubernetes 架构解析
- 你的知识库 - Kubernetes 架构
- 你的知识库 - Kubernetes(K8s) 深度全解析
- 你的知识库 - 【运维干货分享】一份完整的图文手册，理解 kubetnetes 架构