2. 控制平面架构：定义、组件与数据平面分离
在 Kubernetes 与 GitOps 的融合体系中，控制平面（Control Plane） 是集群的“大脑”，负责全局决策、状态协调与资源调度。理解控制平面的定义、核心组件及其与数据平面的分离原则，是掌握 GitOps 资源模型优化与数据传输路径的基础。
2.1 控制平面的定义与职责
控制平面是一组运行在集群主节点上的分布式进程集合，它不直接运行用户业务容器，而是通过 API 与声明式状态管理来驱动整个集群达到期望状态。其核心职责包括：
- 状态存储与一致性：通过 etcd 持久化所有集群资源对象，确保强一致性。
- API 网关与认证授权：作为所有管理操作的唯一入口，执行身份验证、授权与准入控制。
- 控制器循环：持续对比“期望状态”（Spec）与“实际状态”（Status），执行调和逻辑。
- 资源调度：将 Pod 等工作负载绑定到最合适的节点。
GitOps 视角： 控制平面是 GitOps 代理（如 Argo CD、Flux）的“下游执行者”。GitOps 工具将 Git 仓库中的期望状态推送到控制平面的 API Server，由控制平面负责后续的分布式协调与收敛。
2.2 核心组件详解
控制平面由三个核心组件与一个可选组件构成，它们各司其职，共同维护集群的生命周期。
| 组件 | 功能定位 | 关键行为 | 与 GitOps 的交互点 |
|---|---|---|---|
| API Server (kube-apiserver) | 控制平面的前端与唯一入口 | RESTful API 提供、认证授权、请求验证、etcd 读写 | GitOps 工具直接调用其 API 创建/更新资源 |
| Controller Manager (kube-controller-manager) | 内置控制器的集合 | 运行 Deployment、ReplicaSet、Node 等控制器，执行调和循环 | 确保 GitOps 提交的资源被正确实例化与维护 |
| Scheduler (kube-scheduler) | Pod 的调度决策者 | 基于资源需求、亲和性、污点等策略选择最优节点 | 间接影响 GitOps 部署的 Pod 分布与数据传输路径 |
| etcd | 分布式键值存储（可选但必须） | 存储所有集群状态，支持 Watch 机制 | GitOps 资源模型的最终一致性来源 |
2.3 控制平面与数据平面的分离
Kubernetes 架构的核心设计原则之一是控制平面与数据平面严格分离。这种分离不仅保障了安全性，也为 GitOps 的资源模型优化提供了架构基础。
- 控制平面：运行在专用主节点上，处理 API 请求、调度与协调。它不承载用户业务流量，只传输控制指令与状态数据。
- 数据平面：由所有工作节点（Worker Nodes）组成，运行用户业务容器（Pod），处理实际的网络数据包、存储 I/O 与计算任务。
关键约束： 控制平面组件不应直接参与业务数据的传输或处理。任何绕过 API Server 直接操作 etcd 或工作节点 kubelet 的行为，都会破坏架构的声明式一致性，并导致 GitOps 状态追踪失效。
以下 SVG 图展示了控制平面与数据平面的逻辑分离架构，以及 GitOps 工具如何通过 API Server 与集群交互：
2.4 分离原则对 GitOps 资源模型的影响
控制平面与数据平面的分离，直接决定了 GitOps 资源模型的设计边界与数据传输优化方向：
- 资源模型只存在于控制平面：所有 GitOps 定义的资源（Deployment、Service、ConfigMap 等）都通过 API Server 写入 etcd，数据平面只负责执行。
- 数据传输路径优化：GitOps 工具应尽量减少对数据平面的直接查询，优先通过 API Server 的 Watch 机制获取状态变更，避免频繁轮询工作节点。
- 安全边界：控制平面组件不应暴露到数据平面网络，GitOps 工具的 Webhook 与 API 调用必须严格限制在控制平面网络域内。
实践建议： 在 GitOps 流水线中，将 Argo CD 或 Flux 部署在独立的控制平面命名空间（如
gitops-system），并配置 NetworkPolicy 仅允许其访问 API Server 的 6443 端口，禁止直接访问工作节点 kubelet 端口（10250）。
以下 SVG 图进一步细化 GitOps 工具如何通过控制平面组件实现资源模型的声明式管理：
2.5 本章小结
控制平面是 Kubernetes 集群的决策中枢，其 API Server、Controller Manager、Scheduler 与 etcd 的协作机制，为 GitOps 提供了声明式资源管理的执行基础。控制平面与数据平面的严格分离，不仅保障了集群的安全性与稳定性，也定义了 GitOps 资源模型的数据传输边界——所有期望状态必须通过 API Server 注入，所有状态反馈必须通过 API Server 的 Watch 机制获取。理解这一架构，是后续优化 GitOps 资源模型与数据传输路径的前提。