2. Kubernetes控制面组件全景：API Server、etcd、Scheduler、Controller Manager、CoreDNS的职责与关键指标
Kubernetes控制面是整个集群的“大脑”，负责全局决策、状态存储与调度编排。理解每个组件的职责及其可观测性指标，是构建控制面监控体系的基础。本章逐一剖析五大核心组件，并给出每个组件必须关注的黄金指标。
2.1 组件架构总览
控制面组件通常运行在Master节点上（或作为静态Pod），它们通过API Server进行松耦合通信。下图展示了组件间的核心交互关系：
2.2 API Server — 控制面总线
kube-apiserver 是所有组件和客户端交互的唯一入口，提供RESTful API、认证授权、准入控制、请求聚合等功能。它是控制面中负载最重、最需要监控的组件。
核心职责
- API 注册与路由：管理所有Kubernetes资源（Pod、Service、Deployment等）的API版本与路由。
- 认证与授权：支持TLS证书、Bearer 、Webhook等多种认证方式，结合RBAC/ABAC进行授权。
- 准入控制：通过MutatingAdmissionWebhook和ValidatingAdmissionWebhook对请求进行修改和校验。
- 请求聚合：将kubelet、metrics-server等扩展API的请求代理到对应后端。
- Watch机制：维护长连接，向客户端推送资源变更事件。
关键可观测性指标
| 指标类别 | 指标名称（Prometheus） | 说明 | 告警阈值参考 |
|---|---|---|---|
| 请求速率 | apiserver_request_total |
按verb、resource、code分桶的请求总数 | 突增 > 3σ 或 5xx 占比 > 1% |
| 请求延迟 | apiserver_request_duration_seconds |
请求处理耗时（P99/P95/P50） | P99 > 5s（写）/ > 1s（读） |
| Watch延迟 | apiserver_watch_events_sizes |
Watch事件大小与延迟 | 事件积压 > 1000 |
| 准入控制 | apiserver_admission_webhook_request_total |
Webhook调用次数与失败率 | 失败率 > 5% |
| etcd交互 | etcd_request_duration_seconds |
API Server到etcd的请求延迟 | P99 > 500ms |
监控要点：API Server的请求延迟和错误率是控制面健康的“晴雨表”。优先关注
apiserver_request_duration_seconds{verb="WATCH"}，因为Watch连接过多或etcd响应慢会导致级联故障。
2.3 etcd — 集群状态存储
etcd 是一个强一致性的分布式键值存储，Kubernetes将所有集群状态（Pod、ConfigMap、Secret等）持久化在etcd中。etcd的性能直接决定控制面的响应速度。
核心职责
- 数据持久化：存储所有Kubernetes资源对象的完整状态。
- 分布式共识：使用Raft协议保证多副本之间的数据一致性。
- Watch机制：支持客户端（主要是API Server）监听键值变化。
- 事务与租约：提供原子性事务操作和租约（Lease）机制。
关键可观测性指标
| 指标类别 | 指标名称（Prometheus） | 说明 | 告警阈值参考 |
|---|---|---|---|
| Leader状态 | etcd_server_is_leader |
当前节点是否为Leader（1/0） | 无Leader > 10s |
| 磁盘IO | etcd_disk_wal_fsync_duration_seconds |
WAL日志fsync耗时 | P99 > 100ms |
| DB大小 | etcd_mvcc_db_total_size_in_bytes |
etcd数据库文件大小 | 超过配额（默认2GB）的80% |
| Raft提案 | etcd_server_proposals_failed_total |
Raft提案失败总数 | 任何失败 > 0 |
| 网络延迟 | etcd_network_peer_round_trip_time_seconds |
节点间RTT | P99 > 200ms |
重要：etcd的磁盘性能至关重要。务必使用SSD，并监控
etcd_disk_backend_commit_duration_seconds 和 etcd_disk_wal_fsync_duration_seconds。如果P99超过100ms，集群可能出现间歇性不可用。
2.4 Scheduler — 调度决策引擎
kube-scheduler 负责将未调度的Pod绑定到合适的Node上。它通过一系列过滤（Predicates）和打分（Priorities）算法，为每个Pod选择最优节点。
核心职责
- Pod监听：通过Watch机制获取未调度的Pod（
spec.nodeName为空）。 - 节点过滤：排除不满足Pod资源请求、端口冲突、污点容忍等条件的节点。
- 节点打分：对剩余节点进行优先级排序（如资源利用率、亲和性规则）。
- 绑定：将Pod与选定节点绑定，更新API Server中的Pod对象。
关键可观测性指标
| 指标类别 | 指标名称（Prometheus） | 说明 | 告警阈值参考 |
|---|---|---|---|
| 调度延迟 | scheduler_scheduling_duration_seconds |
Pod从创建到被调度的总耗时 | P99 > 10s |
| 调度队列 | scheduler_queue_incoming_pods_total |
进入调度队列的Pod数量 | 队列深度持续 > 100 |
| 调度失败 | scheduler_pod_scheduling_attempts |
Pod调度尝试次数（失败会重试） | 重试次数 > 3 的Pod比例 > 5% |
| 预选/优选 | scheduler_e2e_scheduling_duration_seconds |
过滤+打分阶段耗时 | P99 > 5s |
常见问题：调度延迟飙升通常由以下原因引起：① 集群资源不足导致所有节点被过滤；② 自定义调度器扩展（Extender）响应慢；③ 节点标签或污点频繁变更导致调度队列重排。
2.5 Controller Manager — 状态调节器
kube-controller-manager 是一个包含多个控制器的进程集合，每个控制器负责将实际状态调节至期望状态。常见的控制器包括：Deployment Controller、ReplicaSet Controller、Node Controller、Service Controller等。
核心职责
- 状态循环：每个控制器通过Watch监听资源变化，并通过调谐循环（Reconcile Loop）执行操作。
- 副本管理：确保Pod副本数与期望值一致（ReplicaSet/Deployment）。
- 节点健康：监控节点心跳，标记NotReady节点并驱逐Pod。
- 服务与端点：维护Service与EndpointSlice的映射关系。
关键可观测性指标
| 指标类别 | 指标名称（Prometheus） | 说明 | 告警阈值参考 |
|---|---|---|---|
| 调谐延迟 | workqueue_work_duration_seconds |
控制器处理单个工作项耗时 | P99 > 30s |
| 工作队列深度 | workqueue_depth |
各控制器工作队列积压数 | 持续 > 1000 |
| 调谐失败 | workqueue_retries_total |
工作项重试次数 | 重试率 > 10% |
| 节点状态 | node_collector_unhealthy_nodes_in_zone |
不健康节点数量（按区域） | 比例 > 20% |
排查技巧：当Deployment无法扩容时，首先检查
workqueue_depth{name="deployment"} 是否积压。如果队列深度持续上升，说明Controller Manager的处理能力不足或API Server响应变慢。
2.6 CoreDNS — 集群DNS服务
CoreDNS 是Kubernetes集群的默认DNS组件，负责Service名称解析、Pod DNS记录、外部域名转发等。虽然它通常以Deployment形式运行在集群中，但作为控制面基础设施的一部分，其可用性直接影响集群通信。
核心职责
- Service解析：将Service名称（如
my-svc.ns.svc.cluster.local）解析为Cluster IP。 - Pod DNS：为Pod提供A/AAAA记录（需启用
pods插件）。 - 外部转发：将集群外域名转发到上游DNS服务器。
- 缓存：缓存DNS查询结果以减少上游请求。
关键可观测性指标
| 指标类别 | 指标名称（Prometheus） | 说明 | 告警阈值参考 |
|---|---|---|---|
| DNS查询速率 | coredns_dns_requests_total |
按类型（A/AAAA/SRV）和zone统计的查询数 | 突增 > 3σ |
| DNS查询延迟 | coredns_dns_request_duration_seconds |
DNS查询处理耗时 | P99 > 500ms |
| DNS错误率 | coredns_dns_responses_total{rcode!="NOERROR"} |
非成功响应（NXDOMAIN、SERVFAIL等） | 错误率 > 5% |
| 缓存命中率 | coredns_cache_hits_total / coredns_cache_misses_total |
缓存命中与未命中次数 | 命中率 < 50% 需优化 |
注意：CoreDNS的Pod通常只有2个副本，如果集群规模较大（>1000节点），建议增加副本数并开启
ready 插件进行健康检查。DNS解析失败会导致服务间调用超时，表现为间歇性连接错误。
2.7 组件指标全景对比
下表汇总了五大组件最核心的监控维度，便于快速定位问题组件：
| 组件 | 最敏感指标 | 典型故障模式 | 优先监控项 |
|---|---|---|---|
| API Server | 请求延迟P99 | Watch积压、etcd慢、Webhook超时 | apiserver_request_duration_seconds |
| etcd | 磁盘fsync延迟 | Leader切换、DB满、磁盘IO瓶颈 | etcd_disk_wal_fsync_duration_seconds |
| Scheduler | 调度延迟 | 资源不足、调度器扩展慢、队列积压 | scheduler_scheduling_duration_seconds |
| Controller Manager | 工作队列深度 | 控制器死锁、API Server不可达 | workqueue_depth |
| CoreDNS | DNS查询延迟 | 上游DNS故障、缓存失效、Pod重启 | coredns_dns_request_duration_seconds |
2.8 本章小结
Kubernetes控制面的五个组件各司其职，但通过API Server紧密耦合。在构建可观测性体系时，应遵循以下原则：
- 分层监控：先确保etcd和API Server的基础健康，再关注Scheduler和Controller Manager的业务指标。
- 关注P99延迟：控制面组件的平均延迟往往掩盖问题，P99延迟才是用户体验的真实反映。
- 建立基线：每个集群的指标基线不同，需要持续采集并设置动态告警阈值。
- 关联分析：单一指标异常时，应联动查看上下游组件的指标（如API Server慢时，同时检查etcd延迟和Webhook调用）。
下一步实践：在部署Operator方案之前，建议先使用Prometheus + kube-state-metrics + node_exporter 采集上述所有指标，并建立至少2周的基线数据。这将为后续Operator的自动调优提供关键参考。