2. Kubernetes 控制面组件概述：API Server、Controller Manager、Scheduler、etcd 的核心职责与资源特征
Kubernetes 控制面是集群的“大脑”，负责全局决策与状态管理。在讨论 Prometheus 告警规则如何适配控制面弹性伸缩之前，必须深入理解每个组件的职责边界与资源消耗模式。控制面由四个核心组件构成：API Server、Controller Manager、Scheduler 和 etcd。它们各自承担不同的工作负载，对 CPU、内存、网络和磁盘 I/O 的需求差异显著。
2.1 组件职责与交互关系
下图展示了控制面组件之间的核心数据流与依赖关系。API Server 作为统一入口，所有组件通过它进行状态读写；etcd 提供强一致性的后端存储；Controller Manager 和 Scheduler 则作为控制器循环运行，持续调谐集群状态。
2.2 各组件核心职责与资源特征
每个组件在控制面中扮演不同角色，其资源消耗模式与 Prometheus 告警规则设计密切相关。下表从职责、资源瓶颈、关键指标三个维度进行对比。
| 组件 | 核心职责 | 主要资源瓶颈 | 关键 Prometheus 指标 |
|---|---|---|---|
| API Server | RESTful API 统一入口；认证、授权、准入控制；请求验证与状态持久化 | CPU（请求处理）、内存（缓存对象）、网络（并发连接） | apiserver_request_totalapiserver_request_duration_secondsapiserver_current_inflight_requests |
| Controller Manager | 运行多种控制器循环（Node、ReplicaSet、Endpoint、ServiceAccount 等）；调谐期望状态 | 内存（对象缓存）、CPU（调谐循环频率） | workqueue_depthworkqueue_adds_totalcontroller_runtime_reconcile_total |
| Scheduler | 为未调度的 Pod 选择合适节点；执行预选、优选、绑定三个阶段 | CPU（调度算法计算）、内存（节点缓存） | scheduler_pod_scheduling_attemptsscheduler_e2e_scheduling_duration_secondsscheduler_queue_incoming_pods_total |
| etcd | 强一致性键值存储；保存所有集群状态；支持 Watch 机制 | 磁盘 I/O（WAL 写入）、内存（缓存）、网络（Raft 共识） | etcd_server_leader_changes_seen_totaletcd_disk_wal_fsync_duration_secondsetcd_mvcc_db_total_size_in_bytes |
2.3 组件资源特征深度分析
2.3.1 API Server：控制面的流量中枢
API Server 是所有请求的入口，其资源消耗与集群规模、请求速率、对象数量直接相关。核心特征包括：
- CPU 敏感型：每个请求都需要经过认证、授权、准入控制、序列化/反序列化等步骤，CPU 是首要瓶颈。
- 内存缓存：维护大量对象的缓存（如 Pod、Service、Endpoint），内存占用随集群规模线性增长。
- 并发连接数：
--max-requests-inflight和--max-mutating-requests-inflight控制并发上限，超出后请求被限流。
告警关注点： 当 apiserver_current_inflight_requests 持续接近配置上限时，表明 API Server 面临过载风险，应考虑水平扩展或增加资源配额。
2.3.2 Controller Manager：控制循环的集合体
Controller Manager 内部运行数十个独立的控制器循环，每个循环通过 Informer 机制监听资源变化并执行调谐。资源特征如下：
- 内存密集型：每个控制器维护自己的对象缓存（Store），大量控制器同时运行时内存消耗显著。
- 工作队列深度：每个控制器使用独立的工作队列，队列深度反映积压的待处理任务。
- 调谐频率：默认调谐周期（如 5 分钟）与事件触发调谐并存，频繁的调谐会增加 CPU 开销。
最佳实践： 监控 workqueue_depth 指标，当某个控制器的队列深度持续增长时，表明该控制器处理能力不足，可能需要拆分或优化。
2.3.3 Scheduler：调度决策的 CPU 消耗者
Scheduler 负责为每个待调度 Pod 执行预选（Predicates）和优选（Priorities）算法。其资源特征高度依赖集群节点数量和调度策略复杂度：
- CPU 密集型：调度算法需要遍历所有节点进行过滤和打分，节点数越多，CPU 消耗越大。
- 调度队列：维护多个优先级队列（PriorityQueue），Pod 入队和出队操作频繁。
- 缓存依赖：缓存节点信息和已调度 Pod 信息，缓存失效会导致重新计算。
2.3.4 etcd：状态存储的基石
etcd 是控制面的“数据库”，所有集群状态最终存储于此。其资源特征与其他组件截然不同：
- 磁盘 I/O 敏感：WAL（Write-Ahead Log）写入是 etcd 性能的关键路径，磁盘延迟直接影响写入延迟。
- 内存缓存：整个数据库的 MVCC 版本数据缓存在内存中，内存大小与数据量和历史版本数相关。
- Raft 共识：Leader 选举和日志复制需要网络通信，网络延迟和丢包会影响集群稳定性。
重要提示： etcd 的 etcd_disk_wal_fsync_duration_seconds 指标超过 100ms 时，通常表明磁盘性能不足，可能导致 Leader 选举或写入超时。这是控制面弹性伸缩中必须优先关注的告警信号。
2.4 组件资源特征对比总结
下表从弹性伸缩的角度，对比四个组件在资源扩展时的行为差异：
| 组件 | 水平扩展能力 | 垂直扩展效果 | 典型瓶颈 | 弹性伸缩策略 |
|---|---|---|---|---|
| API Server | 强（无状态，可多副本） | 中等（增加 CPU/内存） | CPU、并发连接 | HPA 基于 CPU/内存/请求速率 |
| Controller Manager | 弱（Leader 选举，单副本活跃） | 强（增加内存） | 内存、工作队列深度 | 垂直扩展为主，水平扩展需拆分控制器 |
| Scheduler | 中等（可多副本，需配置 leader-elect） | 强（增加 CPU） | CPU、调度队列 | HPA 基于 CPU/调度延迟 |
| etcd | 有限（Raft 集群，3/5/7 节点） | 中等（增加磁盘 IOPS/内存） | 磁盘 I/O、网络延迟 | 垂直扩展磁盘性能，水平扩展增加节点 |