4. Kubernetes 资源模型概述:Pod、Deployment、StatefulSet、DaemonSet、Service、HPA 的核心资源指标

在 Kubernetes 生态中,资源模型是监控与性能优化的基础。不同的工作负载类型(Workload)和网络抽象层,暴露出的 Prometheus 指标维度与语义截然不同。本章将系统梳理 Pod、Deployment、StatefulSet、DaemonSet、Service 和 HPA 这六类核心 Kubernetes 资源的关键监控指标,为后续 Helm 应用性能优化建立统一的指标认知框架。

4.1 资源模型分层与监控视角

Kubernetes 资源模型可划分为三个监控层次:基础设施层(Node、Volume)、工作负载层(Pod、Deployment、StatefulSet、DaemonSet)和网络与弹性层(Service、HPA)。Prometheus 通过 kube-state-metrics、cAdvisor 和 kubelet 暴露这些资源的指标。

关键原则: 工作负载层的指标最终都聚合自 Pod 级别的资源使用数据。Deployment、StatefulSet 和 DaemonSet 的监控本质是对其管理的 Pod 集合进行标签聚合与统计。
Kubernetes 资源模型分层与 Prometheus 指标采集架构 Kubernetes 资源模型分层与 Prometheus 指标采集架构 基础设施层 (Infrastructure) Node (CPU/Mem/Disk/Network) · Volume (IOPS/Throughput/Latency) 工作负载层 (Workload) Pod (Container-level Resource Usage · Restarts · Phase) Deployment · StatefulSet · DaemonSet (Replica Status · Rollout · Availability) 网络与弹性层 (Network & Elasticity) Service (Endpoint · Traffic) · HPA (Target Utilization · Replica Count) Prometheus 采集源 kube-state-metrics cAdvisor / kubelet

4.2 Pod 核心资源指标

Pod 是 Kubernetes 最小的调度和资源分配单元。Prometheus 监控 Pod 时,主要关注资源使用、状态和生命周期三类指标。

指标类别 Prometheus 指标示例 说明 告警阈值参考
CPU 使用率 rate(container_cpu_usage_seconds_total[1m]) 容器 CPU 使用时间速率,按 Pod 聚合 > 80% request 持续 5m
内存使用量 container_memory_working_set_bytes 容器工作集内存,接近实际物理内存占用 > 90% limit 持续 5m
磁盘 I/O rate(container_fs_reads_bytes_total[1m]) 容器文件系统读写速率 根据应用基线设定
网络流量 rate(container_network_receive_bytes_total[1m]) 容器网络接收/发送字节速率 根据应用基线设定
Pod 状态 kube_pod_status_phase Pod 当前阶段:Pending/Running/Succeeded/Failed/Unknown Failed 或 Unknown 立即告警
容器重启次数 kube_pod_container_status_restarts_total 容器重启累计次数,反映 CrashLoopBackOff > 3 次 / 10m
监控技巧: 使用 kube_pod_container_resource_requests{resource="cpu"} 和 kube_pod_container_resource_limits{resource="memory"} 可以计算 Pod 的资源超分比(Overcommit Ratio),这是容量规划的关键输入。

4.3 Deployment 核心资源指标

Deployment 管理一组无状态 Pod 的声明式更新。监控 Deployment 的核心是副本状态和滚动更新健康度。

  • 期望副本数 vs 可用副本数: kube_deployment_spec_replicas 与 kube_deployment_status_replicas_available 的差值直接反映服务容量是否充足。
  • 更新进度: kube_deployment_status_observed_generation 与 kube_deployment_metadata_generation 不一致时,表示滚动更新尚未完成。
  • 副本不可用率: (kube_deployment_status_replicas_unavailable / kube_deployment_spec_replicas) * 100,超过 0% 即需关注。
常见陷阱: Deployment 的 maxUnavailable 和 maxSurge 参数直接影响滚动更新期间的 Pod 可用性。监控时需结合 kube_deployment_status_replicas_unavailable 判断更新是否导致服务降级。

4.4 StatefulSet 核心资源指标

StatefulSet 用于管理有状态应用,每个 Pod 拥有稳定的网络标识和持久化存储。监控重点在于有序部署和存储卷状态。

指标 Prometheus 表达式 监控意义
当前副本数 kube_statefulset_status_replicas 实际运行的 Pod 数量
就绪副本数 kube_statefulset_status_replicas_ready 通过 Readiness Probe 的 Pod 数量
当前序号 kube_statefulset_status_current_revision 当前应用的 StatefulSet 版本,用于追踪灰度更新
PVC 状态 kube_persistentvolumeclaim_status_phase PVC 是否处于 Bound 状态,Pending 表示存储未就绪
有状态应用监控要点: StatefulSet 的 Pod 名称具有确定性(如 mysql-0, mysql-1),建议为每个 Pod 单独设置资源使用基线和告警,避免因单个 Pod 异常影响整个集群。

4.5 DaemonSet 核心资源指标

DaemonSet 确保每个 Node 上运行一个 Pod 副本,常用于日志采集、监控代理和网络插件。监控核心是节点覆盖率和调度一致性。

  • 调度节点数: kube_daemonset_status_desired_number_scheduled 表示期望调度的节点数。
  • 当前就绪数: kube_daemonset_status_number_ready 表示就绪的 Pod 数量。
  • 不可用节点: kube_daemonset_status_number_unavailable 表示未运行就绪 Pod 的节点数。
  • 节点覆盖率公式: (number_ready / desired_number_scheduled) * 100,低于 100% 表示部分节点缺少 DaemonSet Pod。
DaemonSet 节点覆盖率监控示意图 DaemonSet 节点覆盖率监控示意图 Node-1 DaemonSet Pod ✓ Node-2 DaemonSet Pod ✓ Node-3 DaemonSet Pod ✗ Node-4 DaemonSet Pod ✓ Prometheus 监控指标 desired_number_scheduled = 4 number_ready = 3 节点覆盖率 = 75% → 触发告警

4.6 Service 核心资源指标

Service 提供稳定的网络访问入口,其监控核心是端点可用性和流量分布。

指标 Prometheus 表达式 说明
端点数量 kube_endpoint_address_available Service 后端就绪的 Pod 端点数量
不可用端点 kube_endpoint_address_not_ready 未就绪的端点数量,通常为 0
请求成功率 sum(rate(istio_requests_total{response_code=~"5.*"}[1m])) / sum(rate(istio_requests_total[1m])) 基于 Service Mesh 的 5xx 错误率(如使用 Istio)
请求延迟 histogram_quantile(0.99, sum(rate(istio_request_duration_milliseconds_bucket[1m])) by (le, destination_service)) P99 延迟,反映 Service 响应性能
无 Service Mesh 环境: 如果未使用 Istio/Linkerd,可以通过 kube-proxy 暴露的指标或直接监控 Pod 的 container_network_receive_bytes_total 来间接评估 Service 流量。

4.7 HPA 核心资源指标

Horizontal Pod Autoscaler(HPA)根据 CPU/内存利用率或自定义指标自动调整副本数。监控 HPA 的关键是扩缩容状态和目标利用率。

  • 当前副本数: kube_horizontalpodautoscaler_status_current_replicas
  • 期望副本数: kube_horizontalpodautoscaler_status_desired_replicas
  • 目标指标利用率: kube_horizontalpodautoscaler_spec_target_metric 与 kube_horizontalpodautoscaler_status_current_metric 的对比。
  • 扩缩容事件: 通过 kube_horizontalpodautoscaler_status_condition{condition="AbleToScale"} 判断 HPA 是否正常工作。
HPA 抖动问题: 当 Pod 数量频繁波动时(Thrashing),检查 --horizontal-pod-autoscaler-sync-period 和 --horizontal-pod-autoscaler-downscale-stabilization 参数。监控 kube_horizontalpodautoscaler_status_desired_replicas 的变化频率可以快速发现抖动。

4.8 资源指标聚合与 PromQL 最佳实践

在实际监控中,通常需要将上述指标按工作负载类型进行聚合。以下是一些常用的 PromQL 聚合模式:

# 按 Deployment 聚合 CPU 使用率
sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m])) by (pod)
  / on(pod) group_left(owner_name)
  kube_pod_owner{owner_kind="Deployment"}

# 按 StatefulSet 聚合内存使用量
sum(container_memory_working_set_bytes{namespace="database"}) by (pod)
  / on(pod) group_left(owner_name)
  kube_pod_owner{owner_kind="StatefulSet"}

# 检测 DaemonSet 节点覆盖率
(kube_daemonset_status_number_ready / kube_daemonset_status_desired_number_scheduled) * 100 < 100

# HPA 扩缩容事件频率
changes(kube_horizontalpodautoscaler_status_desired_replicas[15m]) > 3
核心原则: 始终使用 kube_pod_owner 或 kube_pod_labels 将 Pod 级别的指标关联到上层工作负载(Deployment/StatefulSet/DaemonSet),避免直接依赖 Pod 名称中的模式匹配,因为名称可能因滚动更新而改变。