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 形成闭环协同。下图展示了控制面内部的核心数据流向与组件间的依赖关系。

Kubernetes 控制面核心组件协同关系图 Kubernetes 控制面核心组件协同关系 API Server 认证 · 授权 · 准入 · 路由 etcd Raft 共识 · 强一致性存储 Scheduler 调度策略 · 节点选择 Controller Manager 调谐循环 · 状态控制器 协同要点 1. 所有组件仅与 API Server 通信，不直接访问 etcd。 2. Scheduler 通过 Watch 机制监听未调度的 Pod，绑定结果写回 API Server。 3. Controller Manager 持续调谐，确保集群状态与 etcd 中的期望状态一致。

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 为例，展示控制面组件如何协同工作：

  1. 用户提交请求：通过 kubectl apply -f nginx-deployment.yaml 向 API Server 发送 POST 请求。
  2. API Server 校验与存储：认证、授权、准入控制通过后，将 Deployment 资源对象写入 etcd。
  3. Controller Manager 响应：Deployment Controller 监听到新 Deployment，创建对应的 ReplicaSet 资源。
  4. ReplicaSet 控制器工作：ReplicaSet Controller 发现 Pod 副本数不足，创建 Pod 对象（此时 spec.nodeName 为空）。
  5. Scheduler 介入：Scheduler 监听到未调度的 Pod，执行过滤与打分，将 Pod 绑定到最优节点（更新 spec.nodeName）。
  6. kubelet 执行：目标节点的 kubelet 监听到 Pod 绑定信息，调用容器运行时（如 containerd）启动容器。
  7. 状态回写：kubelet 持续上报 Pod 状态至 API Server，最终写入 etcd。
Pod 创建全流程时序图 Pod 创建全流程：控制面组件协同时序 时间 ① 用户 → API Server：POST /apis/apps/v1/namespaces/default/deployments ② API Server → etcd：写入 Deployment 资源对象 ③ Controller Manager：Deployment Controller 创建 ReplicaSet ④ Controller Manager：ReplicaSet Controller 创建 Pod（未调度） ⑤ Scheduler：过滤 + 打分 → 绑定 Pod 到最优节点 ⑥ kubelet：拉取镜像 → 启动容器 → 上报状态至 API Server

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 隔离、最小权限和全面监控四大原则。
← 上一章 📖 返回目录 下一章 →