理解 Kubernetes 架构的核心在于把握控制平面与工作节点的分离设计，以及声明式 API 驱动的控制器模式，这种设计适合需要高可用和弹性伸缩的容器化管理场景。
先说结论：Kubernetes 通过控制平面做全局决策，工作节点负责实际运行，两者通过声明式接口解耦。
- 适合：大规模容器编排、需要自动化运维的团队
- 先看：控制平面组件（API Server、etcd）与工作节点组件（kubelet、kube-proxy）的职责
- 建议：从声明式 API 和控制循环入手，避免陷入具体命令细节而忽略设计哲学
命令速用版
虽然架构理解偏理论，但通过以下命令可以直观查看集群组件状态：
kubectl get pods -n kube-system
kubectl get nodes -o wide
kubectl cluster-info
为什么会这样
Kubernetes 采用控制平面和数据平面分离的架构。控制平面负责全局决策，比如资源调度和响应集群事件；工作节点则运行实际的容器负载。这种分离实现了集群管理与容器运行的解耦，提供了高可用性和可扩展性。核心设计哲学是声明式 API 与控制器模式，用户定义期望状态，系统持续收敛实际状态到期望状态。
分步处理
1. 识别控制平面组件：确认 API Server 作为唯一入口，etcd 存储状态，Scheduler 负责调度，Controller Manager 负责状态协调。
2. 识别工作节点组件：确认 kubelet 与 API Server 通信，kube-proxy 处理网络代理，容器运行时负责启动容器。
3. 理解通信流程：用户提交定义 -> API Server 验证写入 -> Controller 检测变更 -> Scheduler 选择节点 -> kubelet 启动容器。
怎么验证是否生效
查看 kube-system 命名空间下的核心组件 Pod 是否运行正常，检查节点状态是否为 Ready，观察部署应用后 Pod 是否能按期望副本数启动。
常见坑
注意控制平面组件通常不建议运行用户容器以避免资源竞争；网络插件可能替代 kube-proxy 功能；单节点 etcd 存在单点故障风险，生产环境需高可用部署。
参考来源
- Kubernetes 高级技术原理与应用实践深度解析
- Kubernetes 源码解析：从架构到实现的深度探索
- Kubernetes 架构与原理笔记
- 深入浅出 Kubernetes:核心原理与集群架构解析
- Kubernetes 架构
- Kubernetes 核心原理和搭建
原文链接：https://www.zjcp.cc/ask/10417.html