3. Kubernetes 控制面组件：kube-apiserver、kube-controller-manager、kube-scheduler、etcd 的监控要点

在 Kubernetes 控制面弹性伸缩场景中，控制面组件自身的健康与性能直接决定了扩缩容决策的时效性与准确性。Prometheus 监控必须覆盖四个核心组件：kube-apiserver、kube-controller-manager、kube-scheduler 和 etcd。每个组件都有其独特的指标语义和故障模式，本节将逐一拆解其监控要点。

3.1 控制面组件监控架构总览

下图展示了 Prometheus 对 Kubernetes 控制面组件的采集架构。每个组件通过 /metrics 端点暴露指标，Prometheus 使用 kubernetes-service-endpoints 或 kubernetes-pods 服务发现自动抓取。

3.2 kube-apiserver 监控要点

kube-apiserver 是控制面的流量入口，所有扩缩容请求（如 scale、patch、update）都经过它。监控重点在于请求延迟、错误率和队列积压。

3.2.1 核心指标清单

3.2.2 弹性伸缩场景中的故障模式

• 请求积压导致扩缩容延迟：当 apiserver_current_inflight_requests 持续接近上限时，新的 scale 请求被排队，HPA 或 Cluster Autoscaler 的决策无法及时下发。
• watch 连接泄漏：大量 apiserver_longrunning_gauge 连接未正常关闭，导致 APIServer 内存持续增长，最终 OOM。
• etcd 慢查询传导：APIServer 的 P99 延迟突增往往由 etcd 慢查询引起，需联动监控 etcd 指标。

# 查看 APIServer 当前 inflight 请求分布
kubectl get --raw /metrics | grep apiserver_current_inflight_requests

# 按 verb 和 resource 分析 P99 延迟
histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"CREATE|UPDATE|PATCH"}[5m])) by (le, resource))

3.3 kube-controller-manager 监控要点

kube-controller-manager（KCM）负责运行各种控制器，包括 Deployment Controller、ReplicaSet Controller、HorizontalPodAutoscaler Controller 等。在弹性伸缩中，HPA Controller 和 Node Lifecycle Controller 的响应速度至关重要。

3.3.1 核心指标清单

3.3.2 弹性伸缩场景中的故障模式

• HPA 控制器队列积压：当 workqueue_depth{name="horizontalpodautoscaler"} 持续增长时，HPA 无法及时处理指标变化，导致扩缩容滞后。
• ReplicaSet 控制器调谐失败：controller_runtime_reconcile_total{controller="replicaset", result="error"} 突增，可能导致 Pod 创建/删除卡住。
• informer 与 APIServer 断连：workqueue_adds_total 速率降为 0，表示控制器无法收到资源变更事件。

3.4 kube-scheduler 监控要点

kube-scheduler 负责将新创建的 Pod 分配到合适的节点。在弹性伸缩场景中，调度延迟直接影响 Pod 的就绪时间，进而影响扩缩容的生效速度。

3.4.1 核心指标清单

3.4.2 弹性伸缩场景中的故障模式

• 调度延迟导致扩容生效慢：HPA 触发扩容后，新 Pod 长时间处于 Pending 状态，scheduler_pod_scheduling_duration_seconds P99 升高。
• 节点资源不足导致调度失败：scheduler_unschedulable_pods 持续 > 0，且原因标签为 InsufficientMemory 或 InsufficientCPU，说明集群资源已耗尽。
• 调度队列积压：scheduler_pending_pods 突增，同时 scheduler_queue_incoming_pods_total 速率正常，说明调度器处理速度跟不上 Pod 创建速度。

# 按优先级类查看 P99 调度延迟
histogram_quantile(0.99, sum(rate(scheduler_pod_scheduling_duration_seconds_bucket[5m])) by (le, priority))

# 查看无法调度的 Pod 原因分布
sum by (reason) (scheduler_unschedulable_pods)

3.5 etcd 监控要点

etcd 是 Kubernetes 控制面的持久化存储，所有控制面组件的读写操作最终都依赖 etcd。etcd 的性能直接决定了整个控制面的响应速度，尤其在弹性伸缩场景中，频繁的 Pod 创建/删除事件会产生大量 etcd 写入。

3.5.1 核心指标清单

3.5.2 弹性伸缩场景中的故障模式

• 磁盘 I/O 瓶颈：大规模扩缩容时，大量 Pod 事件写入 etcd，etcd_disk_wal_fsync_duration_seconds P99 升高，导致写入延迟增大，APIServer 响应变慢。
• 数据库空间不足：频繁的 Pod 创建/删除会产生大量历史版本，etcd_db_total_size_in_bytes 快速增长，接近配额时 etcd 会拒绝写入。
• Leader 频繁切换：网络抖动或磁盘慢导致心跳超时，etcd_server_leader_changes_seen_total 突增，集群进入选举状态，期间无法提供服务。

3.6 控制面组件监控指标对比总结

下表从延迟敏感度、队列深度、错误率和资源消耗四个维度对比四个组件的监控重点：

3.7 控制面组件监控的 Prometheus 配置示例

以下是一个使用 Prometheus Operator ServiceMonitor 采集控制面组件的配置片段：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-apiserver
  namespace: monitoring
spec:
  endpoints:
  - port: https
    scheme: https
    tlsConfig:
      caFile: /etc/prometheus/secrets/etcd-certs/ca.crt
      certFile: /etc/prometheus/secrets/etcd-certs/client.crt
      keyFile: /etc/prometheus/secrets/etcd-certs/client.key
    bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/
    interval: 10s
    scrapeTimeout: 8s
  selector:
    matchLabels:
      component: apiserver
      provider: kubernetes
---
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: kube-controller-manager
  namespace: monitoring
spec:
  podMetricsEndpoints:
  - port: metrics
    interval: 10s
    scrapeTimeout: 8s
  selector:
    matchLabels:
      component: kube-controller-manager
  namespaceSelector:
    matchNames:
    - kube-system