3. 控制平面组件概览：API Server、etcd、Controller Manager、Scheduler

在 Kubernetes 集群中，控制平面（Control Plane）是集群的大脑，负责全局决策和状态管理。对于 Secrets 轮换准入策略自动化而言，理解控制平面各组件的职责与交互是设计可靠、安全架构的前提。本章将逐一剖析四个核心组件：API Server、etcd、Controller Manager 和 Scheduler，并重点说明它们与 Secrets 生命周期管理的关联。

3.1 组件全景与交互关系

控制平面组件以松耦合方式协作，共同维护集群的期望状态。下图展示了核心组件之间的通信路径与数据流向，其中 API Server 作为统一入口，所有组件均通过它进行状态读写。

3.2 API Server：集群的网关与准入关口

API Server（kube-apiserver）是控制平面的前端，所有对集群状态的查询和变更操作都必须经过它。对于 Secrets 轮换准入策略，API Server 是策略执行的第一个检查点。

3.2.1 核心职责

• RESTful API 提供：暴露 Kubernetes API，支持 CRUD 操作。
• 认证与授权：验证请求者身份（Authentication），检查操作权限（Authorization）。
• 准入控制：在请求持久化之前，通过 Admission Webhook 链执行校验和变更逻辑。
• 请求验证与转换：确保资源对象的合法性，处理 API 版本转换。

3.2.2 与 Secrets 轮换的关联

Webhook 类型	作用时机	在 Secrets 轮换中的用途
MutatingAdmissionWebhook	对象持久化之前，可修改请求	自动注入轮换注解、修改 Secret 元数据
ValidatingAdmissionWebhook	对象持久化之前，只读校验	验证轮换策略合规性（如禁止明文密码）

3.3 etcd：集群状态的持久化基石

etcd 是一个分布式、强一致性的键值存储，Kubernetes 将所有集群状态（包括 Secrets）存储在 etcd 中。Secrets 的加密存储和轮换直接依赖 etcd 的可靠性与安全性。

3.3.1 数据模型与存储结构

• 键前缀：所有 Kubernetes 资源以 /registry/<resource>/<namespace>/<name> 格式存储。
• Secrets 存储路径：/registry/secrets/<namespace>/<secret-name>。
• 版本控制：每个键关联一个 revision，用于 Watch 机制和乐观锁。

3.3.2 加密与安全考量

加密提供者	密钥管理方式	轮换影响
aescbc	本地静态密钥文件	密钥轮换需重启 API Server 并重写所有 Secrets
kms	外部密钥管理服务（如 AWS KMS、Vault）	支持在线密钥轮换，无需重启 API Server
secretbox	基于 XSalsa20-Poly1305	性能较好，但密钥管理仍需谨慎

3.4 Controller Manager：状态调节与自动化循环

Controller Manager（kube-controller-manager）运行多个控制器进程，每个控制器负责将当前状态调节至期望状态。在 Secrets 轮换场景中，控制器是自动化轮换逻辑的执行者。

3.4.1 核心控制器与 Secrets 相关

• Namespace Controller：删除 Namespace 时清理其中的 Secrets。
• GC Controller：清理孤儿对象，确保 Secrets 的 OwnerReference 正确。
• Controller：管理 ServiceAccount 的 Secrets 令牌。
• 自定义控制器：用户可开发控制器监听 Secret 变更，触发轮换流程。

3.4.2 控制器工作模式

// 控制器核心循环伪代码
for {
    // 1. 通过 Informer 监听 Secret 资源
    // 2. 将对象加入工作队列
    // 3. 从队列取出对象，执行调和逻辑
    // 4. 更新状态或触发外部操作（如调用 Vault API）
}

3.5 Scheduler：Pod 调度与 Secrets 依赖

Scheduler（kube-scheduler）负责将新创建的 Pod 分配到合适的节点。虽然 Scheduler 不直接管理 Secrets，但 Pod 对 Secrets 的引用会影响调度决策。

3.5.1 调度与 Secrets 的间接关系

• Volume 调度：如果 Pod 通过 Volume 挂载 Secret，调度器需确保节点可访问该 Volume（如 CSI 驱动）。
• 节点选择约束：Pod 的 nodeSelector 或 affinity 可能影响 Secret 的可用性。
• 调度失败场景：Secret 引用的 ServiceAccount 不存在时，Pod 可能无法通过准入检查，调度器不会收到 Pod。

3.5.2 调度器扩展点与 Secrets 策略

调度扩展点	Secrets 相关影响	轮换策略建议
PreFilter	检查 Pod 引用的 Secret 是否存在	确保轮换期间新旧 Secret 同时存在
Filter	节点过滤（如 Volume 可用性）	避免调度到无法访问 Secret 的节点
Score	节点打分（如资源均衡）	无直接关联，但需考虑轮换导致的 Pod 重建

3.6 组件协作：Secrets 轮换请求的完整路径

当触发 Secrets 轮换时，请求在控制平面中的流转路径如下：

1. 用户/控制器 向 API Server 发送 PATCH 或 PUT 请求更新 Secret。
2. API Server 执行认证、授权，然后调用 Admission Webhook 进行策略校验。
3. 通过准入检查后，API Server 将新 Secret 数据写入 etcd。
4. Controller Manager 中的 Informer 监听到 Secret 变更，触发控制器调和逻辑（如更新依赖的 Deployment）。
5. Scheduler 在后续 Pod 调度时，使用最新的 Secret 引用。

3.7 组件高可用与 Secrets 轮换的可靠性

控制平面组件的高可用配置直接影响 Secrets 轮换的可靠性。下表总结了各组件的 HA 部署要点：

组件	HA 部署方式	Secrets 轮换影响
API Server	多实例 + 负载均衡（如 HAProxy）	任一实例均可处理 Webhook 请求，需确保 Webhook 配置同步
etcd	3 或 5 节点集群（Raft 共识）	写入需多数节点确认，轮换延迟可能增加
Controller Manager	Leader Election（--leader-elect=true）	仅 Leader 执行调和，轮换逻辑不会重复执行
Scheduler	Leader Election（--leader-elect=true）	仅 Leader 调度 Pod，不影响 Secrets 数据面