2. Kubernetes 控制面架构：核心组件职责与监控要点
Kubernetes 控制面（Control Plane）是集群的“大脑”，负责全局决策、状态协调与调度编排。在 Prometheus 策略命中率与误报复核场景中，控制面各组件的健康状态与性能指标直接决定了告警规则的可靠性与响应时效。本节深入剖析四大核心组件——API Server、Controller Manager、Scheduler、etcd——的职责边界与关键监控指标。
监控前置原则： 控制面组件的 Prometheus 指标暴露端口与路径应纳入 ServiceMonitor 或 PodMonitor 的自动发现范围，避免手工配置遗漏导致指标采集盲区。
2.1 API Server：集群的网关与状态中枢
API Server（kube-apiserver）是 Kubernetes 控制面的前端，所有组件与 kubectl 均通过它进行资源操作。它负责认证、授权、准入控制、请求限流以及将资源状态持久化到 etcd。
核心职责
- RESTful API 网关： 提供 CRUD 接口，处理所有资源对象的增删改查。
- 认证与授权： 集成 TLS 证书、Bearer 、Webhook 等多种认证方式，并通过 RBAC/ABAC 进行授权校验。
- 准入控制： 执行 MutatingAdmissionWebhook 与 ValidatingAdmissionWebhook，在持久化前修改或验证资源。
- 请求限流与优先级： 基于 APF（API Priority and Fairness）对请求分级限流，防止异常流量打垮控制面。
- Watch 机制： 维护长连接，向 Controller Manager、Scheduler 等组件推送资源变更事件。
监控要点
| 指标类别 | 关键指标示例 | 监控意义 |
|---|---|---|
| 请求延迟 | apiserver_request_duration_seconds |
按 verb、resource、scope 分位延迟，超过 1s 需关注 |
| 请求速率与错误 | apiserver_request_total / apiserver_request_errors_total |
错误率突增可能预示认证失败或准入 Webhook 异常 |
| Watch 连接数 | apiserver_watch_connections |
连接数过高可能导致 API Server 内存膨胀 |
| APF 拒绝数 | apiserver_flowcontrol_rejected_requests_total |
拒绝请求突增说明控制面过载，需扩容或优化请求模式 |
| etcd 交互延迟 | etcd_request_duration_seconds（通过 API Server 代理） |
反映 etcd 响应速度，间接影响 API Server 延迟 |
Prometheus 策略关联： 若 API Server 请求延迟 P99 持续超过 2s，基于 API Server 延迟的告警规则可能频繁误报。建议在告警规则中引入
apiserver_request_duration_seconds 的基线动态阈值，避免静态阈值在集群扩缩容时产生误报。
2.2 Controller Manager：集群状态的自愈引擎
Controller Manager（kube-controller-manager）运行着数十个控制器，负责将集群实际状态向期望状态收敛。常见的控制器包括 Node Controller、Deployment Controller、ReplicaSet Controller、EndpointSlice Controller 等。
核心职责
- 节点管理： 监控节点心跳，标记 NotReady 节点并驱逐 Pod。
- 工作负载协调： 确保 Deployment、StatefulSet、DaemonSet 的副本数符合预期。
- 服务与端点管理： 维护 Service 与 EndpointSlice 的映射关系。
- 与 Secret 管理： 自动创建 ServiceAccount 对应的 Secret 并挂载。
监控要点
| 指标类别 | 关键指标示例 | 监控意义 |
|---|---|---|
| 工作队列深度 | workqueue_depth |
队列堆积表明控制器处理能力不足或 API Server 响应慢 |
| 工作队列延迟 | workqueue_queue_duration_seconds |
任务在队列中等待时间过长，影响自愈速度 |
| 控制器同步延迟 | controller_runtime_reconcile_time_seconds |
Reconcile 循环耗时超过 10s 需排查 |
| Leader 选举状态 | leader_election_master_status |
确保只有一个 Controller Manager 实例处于活跃状态 |
| 节点状态变更 | node_collector_unhealthy_nodes |
异常节点数突增可能引发大规模 Pod 驱逐 |
误报复核场景： 当 Controller Manager 的工作队列深度持续超过 100 且同步延迟 > 30s 时，基于“Pod 重启次数”或“节点状态”的告警规则可能因控制器处理滞后而产生误报。建议在告警规则中增加
workqueue_depth 的上下文标签，辅助区分真实故障与控制器积压。
2.3 Scheduler：Pod 与节点的最优匹配器
Scheduler（kube-scheduler）负责为新创建的 Pod 选择最合适的节点。它通过过滤（Predicates）与打分（Priorities）两阶段算法，结合调度策略与资源可用性做出决策。
核心职责
- Pod 调度： 监听未调度的 Pod，为其分配节点。
- 资源感知： 基于节点 CPU、内存、GPU 等资源余量进行过滤。
- 亲和性与反亲和性： 支持节点亲和、Pod 亲和/反亲和、Taint/Toleration 等高级调度策略。
- 调度队列管理： 维护待调度 Pod 的优先级队列，支持抢占式调度。
监控要点
| 指标类别 | 关键指标示例 | 监控意义 |
|---|---|---|
| 调度延迟 | scheduler_e2e_scheduling_duration_seconds |
端到端调度延迟，超过 5s 需关注 |
| 调度队列深度 | scheduler_pending_pods |
待调度 Pod 数量持续增长说明调度瓶颈 |
| 调度失败次数 | scheduler_pod_scheduling_failures_total |
失败原因分布（资源不足、端口冲突、亲和性不满足等） |
| 抢占次数 | scheduler_preemption_attempts_total |
频繁抢占表明集群资源紧张 |
| 打分算法耗时 | scheduler_score_extension_point_duration_seconds |
自定义打分插件性能瓶颈定位 |
Prometheus 策略优化： 若 Scheduler 的
scheduler_pending_pods 持续大于 50，且 scheduler_e2e_scheduling_duration_seconds P99 超过 10s，则基于“Pod 启动延迟”的告警规则应设置较长的评估周期（如 5m），避免因调度瞬时抖动触发误报。
2.4 etcd：集群状态的持久化基石
etcd 是一个分布式键值存储，Kubernetes 将所有资源对象的状态持久化在 etcd 中。它是控制面的“单点真理源”，其性能直接影响整个集群的响应速度。
核心职责
- 数据持久化： 存储所有资源对象的当前状态与历史版本。
- Watch 机制： 支持 API Server 通过 Watch 监听资源变更。
- 分布式一致性： 基于 Raft 协议保证多副本数据强一致。
- 租约管理： 支持 Leader 选举与分布式锁。
监控要点
| 指标类别 | 关键指标示例 | 监控意义 |
|---|---|---|
| 请求延迟 | etcd_request_duration_seconds |
读写延迟 P99 超过 100ms 需排查 |
| DB 大小 | etcd_mvcc_db_total_size_in_bytes |
超过 2GB 需启用压缩或清理历史版本 |
| Leader 变更次数 | etcd_server_leader_changes_seen_total |
频繁 Leader 切换表明网络或磁盘 I/O 异常 |
| 磁盘 fsync 延迟 | etcd_disk_wal_fsync_duration_seconds |
WAL 写入延迟超过 500ms 可能导致集群不稳定 |
| gRPC 请求速率 | etcd_grpc_requests_total |
请求量突增可能预示 API Server 异常重试 |
误报复核场景： etcd 的
etcd_request_duration_seconds 在磁盘 I/O 压力下可能短暂飙升到 1s 以上，此时基于 API Server 延迟的告警规则可能被触发。建议在告警规则中引入 etcd 延迟的滑动窗口均值（如 5m 平均），避免单点毛刺导致误报。
2.5 控制面组件监控总览
下表汇总了四大组件的核心监控维度与 Prometheus 指标前缀，便于快速建立监控面板与告警规则。
| 组件 | 指标前缀 | 核心监控维度 | 默认端口 |
|---|---|---|---|
| API Server | apiserver_* |
请求延迟、错误率、Watch 连接、APF 拒绝 | 6443 (HTTPS) / 8080 (HTTP) |
| Controller Manager | workqueue_*, controller_runtime_* |
队列深度、同步延迟、Leader 选举 | 10257 (HTTPS) |
| Scheduler | scheduler_* |
调度延迟、待调度 Pod、失败原因 | 10259 (HTTPS) |
| etcd | etcd_* |
请求延迟、DB 大小、Leader 变更、磁盘 fsync | 2379 (gRPC) / 2380 (peer) |
最佳实践： 在 Prometheus 中为每个控制面组件创建独立的 Recording Rule，将高频查询的指标（如
apiserver_request_duration_seconds 的分位值）预聚合为 :apiserver_request_duration_seconds:p99，减少查询时的计算开销，提升告警规则的响应速度。