1. Kubernetes 控制面概述：控制面组件
Kubernetes 控制面（Control Plane）是集群的“大脑”，负责维护集群的期望状态、调度工作负载、响应故障并对外暴露 API。控制面由四个核心组件构成：API Server、etcd、Scheduler 和 Controller Manager。它们协同工作，形成一个闭环的控制系统。
1.1 核心组件功能一览
| 组件 | 核心职责 | 关键特性 |
|---|---|---|
| API Server | 所有 REST 操作的入口，认证、授权、准入控制 | 无状态、水平扩展、唯一与 etcd 通信的组件 |
| etcd | 分布式键值存储，保存集群全部状态数据 | 强一致性（Raft）、watch 机制、快照备份 |
| Scheduler | 为未调度的 Pod 选择最优节点 | 过滤 + 打分、可扩展调度框架 |
| Controller Manager | 运行控制器循环，确保实际状态趋近期望状态 | 多控制器组合、leader 选举、故障自愈 |
1.2 组件交互流程
当用户通过 kubectl apply -f deployment.yaml 创建一个 Deployment 时，控制面内部发生以下交互：
- API Server 接收请求：对用户进行认证、授权，执行准入控制（Mutating/Validating Admission Webhook），将资源对象序列化后写入 etcd。
- etcd 持久化：通过 Raft 协议将数据复制到集群中的多个 etcd 节点，确保强一致性。
- Controller Manager 检测变化：Deployment Controller 通过 watch 机制感知到新的 Deployment 对象，创建对应的 ReplicaSet，并进一步创建 Pod 对象（此时 Pod 处于 Pending 状态）。
- Scheduler 介入：Scheduler 通过 watch 发现未绑定节点的 Pod，执行过滤（如资源不足、端口冲突）和打分（如节点亲和性、资源均衡），将 Pod 绑定到最优节点。
- Kubelet 执行：节点上的 Kubelet 通过 watch 发现 Pod 被调度到本节点，调用容器运行时（如 containerd）启动容器。
关键点：所有组件之间不直接通信，而是通过 API Server 和 etcd 的 watch 机制实现事件驱动。API Server 是唯一与 etcd 交互的组件，其他组件只与 API Server 通信。
1.3 控制面交互流程示意图
1.4 组件协作的闭环控制模型
Kubernetes 控制面采用“声明式”控制模型，其核心循环可概括为：
- 观测（Observe）：Controller Manager 和 Scheduler 通过 API Server 的 watch 机制持续观测集群状态变化。
- 分析（Analyze）：控制器将当前状态与期望状态（存储在 etcd 中）进行比较，计算出差异。
- 执行（Act）：控制器通过 API Server 创建、更新或删除资源对象，驱动集群向期望状态收敛。
设计启示：理解控制面的交互流程是设计 CRD 和自定义控制器的基础。自定义控制器本质上是在复用这套“观测-分析-执行”的闭环模型，只是将控制逻辑从内置资源扩展到自定义资源。
1.5 组件部署拓扑
在生产环境中，控制面组件通常以静态 Pod 或 DaemonSet 的形式部署在控制面节点上。etcd 集群与控制面组件分离部署，以保证数据安全。API Server 通常通过负载均衡器对外暴露，实现高可用。
1.6 组件高可用配置要点
| 组件 | 高可用策略 | 推荐实例数 |
|---|---|---|
| API Server | 无状态，前端负载均衡 | 2~3 个实例 |
| etcd | Raft 集群，奇数节点 | 3 或 5 个节点 |
| Scheduler | leader 选举，同一时间只有一个活跃 | 2~3 个实例 |
| Controller Manager | leader 选举，同一时间只有一个活跃 | 2~3 个实例 |
注意：etcd 是控制面的状态存储核心，其性能直接影响整个集群的响应速度。建议为 etcd 使用独立的 SSD 磁盘，并定期执行压缩和碎片整理操作。etcd 集群的网络延迟应控制在 10ms 以内，避免 Raft 选举超时导致集群不稳定。