1. Kubernetes 控制面蓝图概述：控制面核心组件与协同关系
Kubernetes 控制面（Control Plane）是整个集群的“大脑”，负责全局决策、状态管理、调度编排与故障响应。理解控制面核心组件的功能及其协同机制，是掌握 Kubernetes 架构设计的起点。本章从组件职责、数据流向、协同时序三个维度，构建控制面蓝图的第一块基石。
1.1 控制面核心组件一览
控制面由四个常驻组件构成，它们各自独立又紧密协作，共同维护集群的期望状态（Desired State）。
| 组件 | 核心职责 | 关键特征 |
|---|---|---|
| API Server | 集群统一入口，RESTful API 网关，认证/授权/准入控制 | 无状态水平扩展，etcd 的唯一读写代理 |
| etcd | 分布式键值存储，保存集群全部资源对象与状态 | 基于 Raft 共识，强一致性，数据持久化 |
| Scheduler | 为新创建的 Pod 选择最优工作节点 | 可插拔调度策略，支持亲和性/污点/拓扑约束 |
| Controller Manager | 运行各类控制器，持续调谐实际状态至期望状态 | 控制器模式（Reconciler Loop），多控制器并行 |
架构要点：API Server 是控制面的“门面”，所有组件（包括 kubectl、kubelet、Scheduler、Controller Manager）都通过 API Server 与集群交互，绝不直接访问 etcd。这种设计保证了安全边界与扩展性。
1.2 组件协同关系与数据流
四个组件并非孤立运行，而是通过 API Server 形成闭环协同。下图展示了控制面内部的核心数据流向与组件间的依赖关系。
1.3 核心组件功能详解
1.3.1 API Server — 集群网关与状态代理
- 统一入口：所有对集群的操作（kubectl、kubelet、内部组件）均通过 API Server 的 RESTful API 进行。
- 安全防线：执行认证（Authentication）、授权（Authorization）、准入控制（Admission Control）三层校验。
- etcd 代理：API Server 是唯一与 etcd 交互的组件，其他组件通过 API Server 读写集群状态。
- Watch 机制：支持客户端长轮询监听资源变化，实现事件驱动架构。
1.3.2 etcd — 集群状态存储
- 强一致性：基于 Raft 共识算法，保证所有节点数据一致。
- 数据模型：以键值对形式存储所有 Kubernetes 资源对象（Pod、Service、ConfigMap 等）。
- 高可用部署：通常以 3 或 5 节点集群运行，容忍少数节点故障。
- 性能关注：磁盘 I/O 和网络延迟直接影响控制面响应速度，建议使用 SSD 和低延迟网络。
1.3.3 Scheduler — 智能调度决策
- 调度流程：监听 API Server 中未调度的 Pod（
spec.nodeName为空），经过过滤（Predicates）和打分（Priorities）两阶段选出最优节点。 - 可扩展性：支持自定义调度器、调度框架（Scheduling Framework）和扩展点（Extender）。
- 约束支持：节点亲和性、Pod 亲和性/反亲和性、污点与容忍、拓扑分布约束。
1.3.4 Controller Manager — 状态调谐引擎
- 控制器模式：每个控制器独立运行调谐循环（Reconciler Loop），对比“期望状态”与“实际状态”并执行修正。
- 内置控制器：Node Controller、Replication Controller、Deployment Controller、Service Controller 等数十个。
- 幂等性：控制器设计为幂等，即使重复执行也不会产生副作用。
关键理解：Controller Manager 中的每个控制器只关注自己负责的资源类型。例如，Deployment Controller 只管理 Deployment 和 ReplicaSet，不直接操作 Pod。这种单一职责原则使控制面逻辑清晰且易于扩展。
1.4 组件协同时序：Pod 创建全流程
以创建一个 Nginx Deployment 为例，展示控制面组件如何协同工作：
- 用户提交请求：通过
kubectl apply -f nginx-deployment.yaml向 API Server 发送 POST 请求。 - API Server 校验与存储：认证、授权、准入控制通过后，将 Deployment 资源对象写入 etcd。
- Controller Manager 响应：Deployment Controller 监听到新 Deployment，创建对应的 ReplicaSet 资源。
- ReplicaSet 控制器工作：ReplicaSet Controller 发现 Pod 副本数不足，创建 Pod 对象（此时
spec.nodeName为空）。 - Scheduler 介入：Scheduler 监听到未调度的 Pod，执行过滤与打分，将 Pod 绑定到最优节点（更新
spec.nodeName）。 - kubelet 执行：目标节点的 kubelet 监听到 Pod 绑定信息，调用容器运行时（如 containerd）启动容器。
- 状态回写：kubelet 持续上报 Pod 状态至 API Server，最终写入 etcd。
1.5 控制面设计原则与最佳实践
| 原则 | 说明 | 实践建议 |
|---|---|---|
| 无状态设计 | API Server、Scheduler、Controller Manager 不持久化本地状态 | 水平扩展 API Server 至 2+ 实例，前端配置负载均衡 |
| etcd 隔离 | etcd 是唯一有状态组件，需独立部署与运维 | 使用专用 SSD 磁盘，开启 TLS 加密，定期备份快照 |
| 最小权限 | 控制面组件使用独立的 ServiceAccount 和 RBAC 权限 | 避免使用 cluster-admin，按需授予最小权限 |
| 监控与告警 | 控制面组件性能直接影响集群稳定性 | 监控 API Server 延迟、etcd 磁盘 I/O、Scheduler 队列深度 |
常见陷阱：etcd 性能瓶颈是控制面故障的首要原因。避免在 etcd 上执行大量 List 操作（如
kubectl get pods --all-namespaces 频繁执行），建议使用 Watch 机制替代轮询。同时，etcd 集群应部署在独立节点上，避免与工作负载争抢资源。
1.6 本章小结
- 控制面四大组件各司其职：API Server 是网关，etcd 是存储，Scheduler 负责调度，Controller Manager 负责调谐。
- 所有组件通过 API Server 间接通信，形成“中心辐射”架构，保障安全与可扩展性。
- Pod 创建流程是理解组件协同的最佳案例，涉及 API Server → etcd → Controller Manager → Scheduler → kubelet 的完整链路。
- 生产环境中应遵循无状态设计、etcd 隔离、最小权限和全面监控四大原则。