引言：分布式系统的“操作系统”
Kubernetes 并非简单的容器管理工具，而是一个可移植、可扩展的开源平台，用于管理容器化工作负载与服务。其设计目标让部署、伸缩、运维自动化变得简单可靠。理解 K8s 架构是掌握其强大能力的起点。
本文将系统剖析 Kubernetes 的控制平面（Control Plane）与工作节点（Worker Node）组件，揭示组件间的协作机制，并给出完整的架构图。
一、K8s 整体架构概览
Kubernetes 采用主从（Master-Worker）架构，集群由一组控制平面节点（通常 3 或 5 个高可用副本）和若干工作节点组成。
二、控制平面（Control Plane）组件
控制平面负责全局决策（如调度）、检测并响应集群事件（如启动新 Pod）。
2.1 API Server（核心网关）
唯一入口：所有组件（包括
kubectl、控制器、kubelet）都通过 API Server 进行通信，内部 RESTful API。认证授权：集成 RBAC、ABAC、Webhook 等机制。
数据校验与转换：接收的 YAML/JSON 对象会经过准入控制（Admission Control）、默认值填充、校验后存入 etcd。
聚合层：支持扩展 API（如 metrics.k8s.io）。
高可用部署：多个 API Server 实例 + 负载均衡，通过 etcd 集群保证状态一致性。
2.2 etcd（集群数据库）
分布式键值存储：保存所有集群数据（Pod、Service、ConfigMap、Secret 等）。
一致性保证：使用 Raft 算法，推荐 3、5、7 节点部署。
性能调优：默认存储 8GB 快照大小，定期压缩历史版本（
etcdctl compact）。安全：启用 TLS 加密通信，防止窃听。
关键点：只有 API Server 能直接访问 etcd，其他组件通过 API Server 间接读写，保证安全与审计。
2.3 Controller Manager（控制器大脑）
运行一系列控制器，每个控制器是一个控制循环，将实际状态调谐至期望状态。
主要控制器包括：
Node Controller：监控节点健康，驱逐故障节点上的 Pod。
Deployment Controller：管理 ReplicaSet 与滚动更新。
Service Controller：为 LoadBalancer 类型的 Service 调配合云 LB。
EndpointSlice Controller：维护 Service 与 Pod 的映射。
Namespace Controller：当 Namespace 被删除时，清理其下所有资源。
工作原理：控制器通过 API Server 的Watch 机制（长连接 + 资源版本号）监听资源变化，触发调谐逻辑。
2.4 Scheduler（调度决策者）
负责将未调度的 Pod绑定到合适的工作节点。决策分为两步：
过滤阶段（Predicates）：筛选满足 Pod 资源请求、节点亲和性、污点容忍等条件的节点。
打分阶段（Priorities）：对剩余节点按优先级排序（如 LeastRequestedPriority、BalancedResourceAllocation），选最高分节点。
可扩展插件：用户可实现自定义调度器（如考虑 GPU 拓扑、网络延迟）。
三、工作节点（Worker Node）组件
3.1 kubelet（节点代理人）
运行在每个节点上，负责：
Pod 生命周期管理：根据 API Server 分配的 Pod 清单，调用容器运行时创建/停止容器。
健康探针执行：定期执行 livenessProbe、readinessProbe、startupProbe。
上报节点状态：向 API Server 发送 NodeStatus（资源容量、文件系统可用等）。
静态 Pod：可指定本地目录中的 Pod 定义（常用于启动控制平面组件的自托管集群）。
工作原理：kubelet 监听 API Server 上分配给该节点的 Pod 变化，同步到本地容器运行时。
3.2 kube-proxy（网络代理）
实现Service 抽象，保证 Pod 可访问稳定的 ClusterIP 和负载均衡。常用模式：
iptables：默认模式，使用 NAT 规则转发，性能较好但规则更新 O(n) 耗时。
IPVS：基于 Linux 内核 LVS，支持更多负载均衡算法（rr、lc、sh 等），适合大规模集群。
userspace（已弃用）：性能差，仅用于旧版本。
工作流程：kube-proxy 监听 Service 和 EndpointSlice 资源，将规则写入本机 iptables/IPVS，实现流量转发。
3.3 容器运行时（Container Runtime）
负责拉取镜像、启动容器。K8s 通过CRI（Container Runtime Interface）对接不同运行时：
containerd：最常用，CNCF 毕业项目，效率高且稳定。
CRI-O：专为 K8s 设计的轻量运行时。
Docker Engine：通过 cri-dockerd 适配器（K8s v1.24+ 已移除原生 Docker 支持）。
四、关键附加组件（Add-ons）
| 组件 | 功能 |
|---|---|
| CoreDNS | 集群 DNS 服务，为 Service 提供my-svc.my-ns.svc.cluster.local域名解析。 |
| Ingress Controller | 实现 Ingress 七层路由，常见实现：Nginx、Traefik、Envoy。 |
| Dashboard | Web UI，可视化管理集群。 |
| Metrics Server | 采集容器资源使用（CPU、内存），支持 HPA（水平自动伸缩）。 |
| Network Plugin | 实现容器网络接口（CNI），如 Calico、Flannel、Cilium。 |
五、组件协作流程：以创建 Deployment 为例
下图展示用户提交 Deployment YAML 后各组件如何协同工作：
关键观察：
所有组件都只与 API Server 通信，形成松散耦合。
Watch 机制实现事件驱动，避免轮询开销。
API Server 作为状态的中转站和并发控制中心。
六、高可用架构最佳实践
| 组件 | 高可用方式 |
|---|---|
| etcd | 3 或 5 节点集群，分开部署（与控制平面物理隔离更佳）。 |
| API Server | 多实例 + 外部负载均衡器（如 HAProxy、Nginx）或云 LB。 |
| Controller Manager & Scheduler | 使用--leader-elect=true，多实例通过选举产生唯一 Leader。 |
| 工作节点 | 跨可用区部署，配合 PodDisruptionBudget 和反亲和性。 |
七、架构设计哲学总结
声明式优于命令式：用户描述期望状态，控制器负责调谐。
控制平面集中、数据平面分散：API Server 是总线，节点自主工作。
可扩展性：CRI、CNI、CSI（容器存储接口）、CRD（自定义资源）等扩展点丰富。
自愈能力：控制器循环持续修复偏离期望的状态（节点故障、Pod 崩溃）。
结语
Kubernetes 架构的精髓在于分层解耦与标准化接口。控制平面组件各司其职，工作节点则执行具体容器任务。掌握这些组件的交互逻辑，不仅能帮助我们高效运维集群，更能为故障排查、性能优化提供坚实基础。
在实际生产环境中，还可以引入Service Mesh（如 Istio）、GitOps 工具（如 ArgoCD）等进一步增强架构。希望本文提供的架构图与深度解析能成为你理解 K8s 的良好起点。
