2. 控制平面架构：控制平面定义、组件划分、API Server、控制器、存储后端

控制平面是 Kubernetes 集群的“大脑”，也是 GitOps 检测体系与资源模型设计的核心执行层。在云原生架构中，控制平面负责维护集群的期望状态（Desired State），并通过一系列协调循环（Reconciliation Loop）驱动实际状态向期望状态收敛。理解控制平面的组件划分与协作机制，是构建可靠 GitOps 检测系统的前提。

2.1 控制平面定义与核心职责

控制平面（Control Plane）是一组运行在集群主节点上的分布式组件集合，其核心职责包括：

• 状态管理：维护集群中所有资源对象的期望状态（存储在 etcd 中）。
• 决策与调度：根据资源声明做出调度、扩缩容、滚动更新等决策。
• 协调循环：持续对比实际状态与期望状态，执行差异修复。
• 认证与授权：提供 API 访问的认证、授权与准入控制。
• 事件与审计：记录资源变更事件，支持审计与可观测性。

2.2 组件划分与职责矩阵

控制平面由以下核心组件构成，每个组件承担独立的职责，并通过 API Server 进行通信：

2.3 API Server：控制平面的统一入口

API Server（kube-apiserver）是控制平面的前端，所有组件和用户都通过它进行交互。其核心工作流程包括：

1. 认证（Authentication）：验证请求者身份（证书、、OIDC 等）。
2. 授权（Authorization）：检查请求者是否有权限执行操作（RBAC、ABAC）。
3. 准入控制（Admission Control）：在持久化前执行 Mutating 和 Validating 准入插件。
4. 验证与持久化：校验资源定义，序列化后写入 etcd。
5. 响应与通知：返回结果，并触发事件通知给监听者（Watch）。

2.4 控制器：状态协调的执行者

控制器（Controller）是控制平面中实现“期望状态驱动”的核心组件。每个控制器负责管理特定类型的资源，其工作模式遵循统一的协调循环：

• Informers：通过 API Server 的 Watch 机制监听资源变化，维护本地缓存。
• Work Queue：将变化事件入队，支持去重与重试。
• Reconciler：从队列中取出事件，对比实际状态与期望状态，执行差异修复。
• Status Update：将协调结果写回 API Server，更新资源状态字段。

// 控制器协调循环伪代码
for {
    event := workQueue.Get()          // 从队列获取事件
    actualState := getActualState()   // 获取实际状态
    desiredState := getDesiredState() // 从 etcd 获取期望状态
    if diff := compare(actualState, desiredState); diff != nil {
        applyDiff(diff)               // 执行差异修复
    }
    updateStatus()                    // 更新资源状态
    workQueue.Done(event)
}

2.5 存储后端：etcd 的状态持久化

etcd 是控制平面的存储后端，采用 Raft 共识算法保证强一致性。在 GitOps 检测体系中，etcd 扮演以下关键角色：

2.6 控制平面架构总览

下图展示了控制平面各组件的协作关系，以及 GitOps 检测系统在其中的位置：

2.7 控制平面高可用设计要点

在生产环境中，控制平面必须支持高可用部署，以确保 GitOps 检测系统的持续运行：

• API Server 多副本：至少 2 个实例，前端通过负载均衡器分发请求。
• etcd 集群：奇数节点（3/5/7），Raft 共识保证数据一致性。
• Controller Manager 选主：通过 Leader Election 机制确保同一时刻只有一个活跃控制器。
• Scheduler 选主：与 Controller Manager 类似，避免重复调度。
• Watch 连接优化：GitOps 检测系统应复用 Watch 连接，避免为每个检测任务创建独立连接。