Kubernetes 控制面承载着集群的全部决策逻辑：kube-apiserver 负责接收所有 API 请求，etcd 保存集群状态数据，kube-scheduler 决定 Pod 运行在哪个节点上，kube-controller-manager 则持续驱动集群向期望状态收敛。这四个组件中任何一个出现异常，都可能导致集群层面的问题，例如 Pod 无法调度、Service 无法更新、节点状态滞留等。因此，掌握控制面的指标采集与健康检查方法，是集群运维和故障排查中非常关键的一环。本文将从组件指标、健康探活、常见异常判断和监控方案搭建四个方面详细展开。
一、控制面组件暴露了哪些关键指标
Kubernetes 的每个控制面组件都内置了 Prometheus 格式的指标端点，默认通过 HTTPS 端口暴露。kube-apiserver 使用 6443 端口的 /metrics 路径，kube-scheduler 和 kube-controller-manager 在启用身份认证后也提供同样的端点。要查看这些指标，最简单的方式是直接请求对应端点：
# 查看 apiserver 指标（需要认证） kubectl get --raw /metrics | head -20 # 或者通过端口转发访问 scheduler 指标 kubectl -n kube-system port-forward pod/kube-scheduler-master 10259:10259 curl -k https://127.0.0.1:10259/metrics
kube-apiserver 最重要的指标集中在请求延迟和错误率上。apiserver_request_duration_seconds 是一个直方图指标，按 verb、resource 等维度拆分了 API 请求的处理耗时；apiserver_request_total 统计各类请求的总量，配合 code 标签可以计算出 5xx 错误率；apiserver_request_queue_duration_seconds 反映请求在队列中排队的时间，如果这个值持续升高，说明 apiserver 处理能力已经饱和，通常是 etcd 慢或者流量过大导致的。
etcd 的核心指标包括 etcd_server_slow_apply_total（慢 apply 操作次数）、etcd_disk_wal_fsync_duration_seconds（WAL 文件 fsync 延迟）和 etcd_disk_backend_commit_duration_seconds（后端提交延迟）。官方建议 WAL fsync 的 P99 延迟应低于 50ms，后端提交延迟 P99 应低于 100ms，超过这个水平说明磁盘 IO 已经成为瓶颈，需要更换更快的存储或排查 IO 争用。
对于 kube-scheduler，重点关注 scheduler_schedule_attempts_total，它按 result 标签区分调度成功和失败。失败原因又通过 reason 细分为 unschedulable、error 等，如果 unschedulable 的增长率持续不为零，说明有 Pod 因为资源不足或亲和性约束无法被调度。kube-controller-manager 的关键指标是 workqueue_depth 和 workqueue_retries_total，前者反映各控制器工作队列的积压深度，后者统计重试次数，这两个值异常升高往往意味着控制器卡住或 API 写入失败。
二、健康检查端点的正确用法
除了指标，控制面组件还提供了专门的健康检查端点。kube-apiserver 暴露了 /healthz、/livez 和 /readyz 三类探活路径。/livez 用于存活探针，判断进程是否存活；/readyz 用于就绪探针，判断组件是否已经可以对外提供服务；/healthz 则是较老的综合健康端点。三者背后的检查项可以通过 /readyz?verbose 参数查看明细：
# 查看就绪检查的详细结果 kubectl get --raw '/readyz?verbose' # 输出示例 # [+]ping ok # [+]log ok # [+]etcd ok # [+]poststarthook/start-apiserver-identity-controller ok # ... # readyz check passed
其中 etcd 检查项非常关键，apiserver 的就绪状态直接依赖与 etcd 的连通性。如果 etcd 集群不可用，apiserver 会自动将自己置为未就绪，负载均衡器（如 kube-apiserver 前面的 HAProxy 或云厂商 LB）就会把流量摘除，避免请求打到一台无法正常工作的 apiserver 上。这也是多 apiserver 高可用部署能自动故障转移的基础。
对于 kubelet 而言，控制面组件的静态 Pod 配置中通常会写入存活探针。以 kubeadm 部署的集群为例，kube-apiserver 的静态 Pod 清单位于 /etc/kubernetes/manifests/kube-apiserver.yaml，探针配置大致如下：
livenessProbe:
failureThreshold: 8
httpGet:
path: /livez
port: 6443
scheme: HTTPS
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 15
readinessProbe:
failureThreshold: 3
httpGet:
path: /readyz
port: 6443
scheme: HTTPS
periodSeconds: 1
timeoutSeconds: 15注意 failureThreshold 的设置：apiserver 的存活探针允许连续 8 次失败才重启，周期 10 秒加上超时 15 秒，意味着组件最多可以忍受约 3 分钟的异常而不被强制重启。这个容忍度是刻意设计的，因为重启 apiserver 的代价很高，会中断所有 API 连接。如果你自定义了探针参数，不建议把 failureThreshold 调得太小，否则 etcd 短暂抖动就会引发 apiserver 反复重启，反而加剧故障。
三、常见异常场景与指标判断
掌握了指标和探活端点后，更重要的是能在故障发生时快速判断哪个组件出了问题。第一种典型场景是 API 请求变慢。这时应先看 apiserver_request_duration_seconds 的 P99 值，如果 LIST 类请求延迟很高，再结合 etcd_disk_backend_commit_duration_seconds 判断是否为 etcd 磁盘瓶颈。常见的根因是集群中存在大量对象（比如几万个 Pod 或 Endpoint），大范围的 LIST all-namespaces 请求会拖慢整个 etcd。
第二种场景是 Pod 一直处于 Pending 状态。排查顺序应该是：先执行 kubectl describe pod 查看 Events 中的调度失败原因，再检查 scheduler_schedule_attempts_total{result="unschedulable"} 的增长情况。如果调度器本身没有报错但 Pod 长时间无人处理，则要确认 scheduler 进程是否正常，可以通过其 10259 端口的 /healthz 端点确认。还有一种容易被忽视的情况是 scheduler 与 apiserver 之间的连接断开，此时 scheduler 进程存活但无法工作，表现为所有新建 Pod 都无人调度。
第三种场景是节点状态长时间不更新、Deployment 扩容无响应，这通常是 controller-manager 的问题。查看 workqueue_depth 是否持续大于零且不下降，配合 rest_client_requests_total{code="5xx"} 判断是否为写 API 失败导致控制器反复重试。此外还可以用一条 PromQL 快速发现无主 Pod：
# 过去5分钟内没有任何调度成功的集群告警
increase(scheduler_schedule_attempts_total{result="scheduled"}[5m]) == 0etcd 相关的告警规则建议至少配置以下几条：WAL fsync P99 超过 500ms 持续 5 分钟、leader 变更次数 etcd_server_leader_changes_seen_total 在短时间内超过 3 次、以及 etcd 集群成员数低于预期值。leader 频繁切换是大集群最危险的前兆，往往伴随整个控制面的间歇性不可用，必须优先处理磁盘和网络问题。
四、搭建可持续的控制面监控方案
生产环境中不应该依赖手工 curl 去检查控制面状态，而是要用 Prometheus 加 Grafana 建立常态化的监控体系。kube-prometheus-stack 是目前最主流的方案，它内置了 etcd、kube-apiserver、kube-scheduler 和 kube-controller-manager 的 ServiceMonitor 和告警规则。部署时只需要确认各组件的 metrics 端口已被 Service 暴露，Prometheus 就能自动发现并抓取。
使用 kubeadm 部署的集群中，控制面组件以静态 Pod 形式运行在 master 节点上，kube-prometheus-stack 提供的 kube-prometheus-stack-self-monitoring 相关配置已经包含了对这些端点的抓取。如果是二进制部署，需要手动创建 Service 并打上合适的标签：
apiVersion: v1
kind: Service
metadata:
name: kube-scheduler-prometheus-discovery
namespace: kube-system
labels:
app.kubernetes.io/name: kube-scheduler
spec:
type: ClusterIP
clusterIP: None
ports:
- name: https-metrics
port: 10259
targetPort: 10259
protocol: TCP指标采集起来之后，建议在 Grafana 中关注几块核心面板：apiserver 请求 QPS 与错误率、请求延迟 P99 分布、etcd 磁盘延迟、scheduler 调度吞吐与延迟、以及各组件 workqueue 深度。这些面板组合起来，基本可以覆盖控制面 90% 以上的故障场景。社区 ID 为 15760 的 Grafana 面板专门用于 etcd 监控，可以直接导入使用。
最后要强调一点：控制面监控本身也有失效的可能，例如 Prometheus 与 apiserver 之间的网络中断会造成大面积指标缺失，这种缺失本身就是重要的告警信号。建议为每个控制面组件的 up 指标配置抓取失败告警，同时用集群外的黑盒探测（例如从管理节点定期请求 apiserver 的 /readyz）作为最后一道防线，确保控制面真正不可用时你能第一时间收到通知，而不是在用户报障后才发现问题。
Kubernetes控制面组件健康检查修改时间：2026-09-02 08:36:41