3. 控制面蓝图架构：控制面组件与 Cluster API 的交互关系
Kubernetes 控制面由 etcd、kube-apiserver、kube-controller-manager 和 kube-scheduler 四个核心组件构成。在 Cluster API 的蓝图下，这些组件不仅管理集群内的工作负载，还通过声明式 API 驱动集群自身的生命周期。理解它们之间的交互关系，是优化查询性能与设计样本留存策略的前提。
3.1 控制面组件核心职责
下表总结了每个组件在标准 Kubernetes 控制面中的角色，以及它们在 Cluster API 场景下的扩展职责：
| 组件 | 标准职责 | Cluster API 扩展职责 |
|---|---|---|
| etcd | 集群状态持久化存储，键值数据库 | 存储 Cluster、Machine、MachineSet 等 CRD 对象；承载集群拓扑快照 |
| kube-apiserver | REST API 入口，认证/授权/准入控制 | 暴露 Cluster API CRD 端点；处理集群创建/更新/删除请求；聚合指标端点 |
| kube-controller-manager | 运行内置控制器（Deployment、Node 等） | 运行 Cluster API 控制器（ClusterController、MachineController、MachineSetController） |
| kube-scheduler | 将 Pod 调度到合适的 Node | 不直接参与集群生命周期管理；但影响工作负载集群内 Pod 的分布 |
3.2 交互关系总览
下图展示了控制面组件与 Cluster API 之间的核心交互流程。箭头方向代表数据流或控制流的方向：
3.3 核心交互流程详解
3.3.1 kube-apiserver 与 etcd：查询路径的起点与终点
所有 Cluster API 对象的读写请求都经过 kube-apiserver，它负责将数据持久化到 etcd。在查询优化场景中，以下环节直接影响延迟：
- API 聚合层：Cluster API 的 CRD 通过 API 聚合注册到 apiserver，请求路由到扩展 API Server 或直接由 apiserver 处理。
- Watch 机制：控制器通过 apiserver 的 Watch 接口监听资源变化，减少对 etcd 的轮询压力。
- 缓存与索引：apiserver 内置的缓存（etcd 索引 + 内存缓存）决定了 List 操作的响应速度。
优化要点：在管理大规模集群（>1000 个 Machine 对象）时，apiserver 的 --max-requests-inflight 和 --max-mutating-requests-inflight 参数需要根据 Cluster API 的并发请求量进行调整。etcd 的 --quota-backend-bytes 应设置为足够容纳所有集群对象的快照数据。
3.3.2 kube-controller-manager 与 Cluster API 控制器：声明式循环
Cluster API 的核心逻辑运行在 kube-controller-manager 进程中，通过以下步骤实现集群生命周期管理：
- Informer 监听：Cluster API 控制器通过 apiserver 的 Watch 接口监听 Cluster、Machine、MachineSet 等 CRD 对象的变化。
- Reconcile 循环：当检测到对象变化（创建/更新/删除），控制器将对象放入工作队列，触发 reconcile 逻辑。
- 状态回写：控制器将操作结果（如 Machine 的 Phase、ProviderID）通过 apiserver 写回 etcd。
- 基础设施调用：控制器调用基础设施 Provider（如 AWS EC2 API）创建或删除虚拟机，并将结果同步到 CRD 状态字段。
样本留存关联：在 reconcile 过程中，控制器会频繁读取和写入 CRD 对象的状态字段。如果样本留存策略不合理（例如保留所有历史状态），会导致 etcd 存储膨胀，进而拖慢 List 和 Watch 操作的性能。
3.3.3 kube-scheduler 的间接影响
kube-scheduler 不直接参与 Cluster API 的集群管理，但它影响工作负载集群内的 Pod 调度。在控制面蓝图设计中，需要注意：
- 当 Cluster API 创建的工作负载集群运行大量 Pod 时，scheduler 的调度决策会影响集群资源的利用率。
- 如果控制面集群本身运行在受限资源环境中，scheduler 的调度延迟可能间接影响 Cluster API 控制器的响应速度（例如控制器 Pod 被调度到负载过高的节点）。
3.4 交互关系中的性能瓶颈矩阵
下表列出了各组件交互中常见的性能瓶颈及其对 Cluster API 查询优化的影响：
| 交互路径 | 瓶颈类型 | 对查询优化的影响 | 推荐优化策略 |
|---|---|---|---|
| apiserver → etcd | I/O 延迟 | List 操作响应时间增加 | 启用 etcd 压缩、调整 --auto-compaction-retention |
| 控制器 → apiserver | API 限流 | Reconcile 循环阻塞 | 调整 --kube-api-qps 和 --kube-api-burst |
| 控制器 → Provider | 网络延迟 | 集群创建/删除时间延长 | 使用异步 reconcile + 状态缓存 |
| etcd 存储 | 空间膨胀 | Watch 事件积压、查询超时 | 实施样本留存策略、定期清理历史状态 |
3.5 交互关系中的样本留存切入点
基于上述交互关系，样本留存策略应聚焦以下三个关键点：
- etcd 层面的快照管理：定期对 etcd 进行快照，并设置合理的保留窗口（例如保留最近 7 天的快照），用于集群恢复和审计。
- CRD 状态字段的裁剪：在 Cluster API 控制器中，避免在 CRD 状态字段中存储冗余的历史信息。例如，Machine 对象的
status.conditions只保留最近 N 条记录。 - Watch 事件的样本采集：在 apiserver 层面，通过审计日志或事件记录器采集关键操作样本（如 Cluster 创建、Machine 删除），用于后续的查询性能分析和故障排查。
注意：不要在控制面组件中直接修改 etcd 数据来实施样本留存。所有数据操作都应通过 apiserver 的 API 进行，以保持一致性并避免触发控制器的不期望 reconcile。