在 Kubernetes（K8s）环境中，容器监控需覆盖“容器- Pod - Node - 集群”多层级，既要关注资源使用效率，也要关联业务稳定性。以下是 K8s 容器监控的核心关键指标与经过实践验证的最佳实践，帮助精准定位性能瓶颈、预防故障。
一、K8s 容器监控的关键指标
K8s 容器监控的指标可分为 4 大类，覆盖资源、状态、业务、集群维度，每类指标需结合告警阈值实现“异常可感知”。
1. 容器资源指标（基础核心）
容器的资源指标直接反映硬件资源消耗，是判断“资源是否充足”“是否存在资源浪费”的核心依据。
| 指标名称 | 含义说明 | 正常范围参考 | 告警阈值建议 | 采集来源 |
|---|---|---|---|---|
| CPU 使用率 | 容器实际使用的 CPU 核心数占分配限额（resources.limits.cpu）的比例 |
30%~70% | 持续 5 分钟 > 85% 或 < 10% | cAdvisor、node-exporter |
| 内存使用率 | 容器实际使用的内存（RSS + 缓存）占分配限额（resources.limits.memory）的比例 |
40%~80% | 持续 3 分钟 > 90% 或 OOM 事件 | cAdvisor、node-exporter |
| 网络吞吐量 | 容器的网络接收（Rx）/ 发送（Tx）速率（按字节/秒计算） | 无固定范围，需结合业务基线 | 突增/突降超过基线 200% | cAdvisor、Metricbeat |
| 磁盘 I/O 使用率 | 容器对挂载卷的读写速率（IOPS 或 MB/s） | 无固定范围，需结合业务基线 | 读写延迟 > 500ms 或 IO 队列堆积 | cAdvisor、node-exporter |
| CPU 节流（Throttling） | 容器因 CPU 限额不足，被 K8s 内核限制运行的时长占比 | 0% | 持续 1 分钟 > 5% | cAdvisor |
| 内存页面交换（Swap） | 容器内存不足时使用 Swap 分区的大小 | 0（建议关闭 Swap） | 任何 Swap 使用均告警 | node-exporter |
2. K8s 资源状态指标（稳定性保障）
这类指标反映 K8s 资源（Pod、Deployment、Node）的运行状态，是判断“调度是否正常”“服务是否可用”的关键。
| 指标名称 | 含义说明 | 正常范围参考 | 告警阈值建议 | 采集来源 |
|---|---|---|---|---|
| Pod 重启次数 | 容器在 1 小时内的重启次数（含 CrashLoopBackOff 状态） | 0次 | 1 小时内 > 3 次 | kube-state-metrics |
| Pod 就绪率 | Deployment 中处于 Ready 状态的 Pod 数占总副本数的比例 | 100% | 持续 2 分钟 < 100% | kube-state-metrics |
| Node 就绪状态 | Node 节点是否处于 Ready 状态（0=未就绪，1=就绪） | 1 | 任何 Node 状态变为 0 告警 | kube-state-metrics |
| Pod 调度失败次数 | Pod 因资源不足、节点污点（Taint）等原因调度失败的次数 | 0次 | 10 分钟内 > 1 次 | kube-state-metrics |
| 容器健康检查失败次数 | 容器的 Liveness/Readiness Probe 检查失败次数 | 0次 | 连续 3 次失败（触发重启） | kube-state-metrics |
3. 应用业务指标（业务关联性）
仅监控资源指标不足以判断“应用是否正常服务”，需结合业务指标（如接口响应时间、错误率），实现“资源问题→业务影响”的关联分析。
| 指标名称 | 含义说明 | 正常范围参考 | 告警阈值建议 | 采集来源 |
|---|---|---|---|---|
| 接口响应时间（RT） | 应用接口的平均响应时间（P50/P95/P99 分位值，P95 更具参考价值） | 视业务而定（如 < 300ms） | P95 持续 2 分钟 > 500ms | 应用内置 Prometheus 客户端（如 Micrometer） |
| 接口 QPS | 应用接口每秒处理的请求数 | 视业务峰值而定 | 突降 < 基线 50%（可能服务不可用） | 应用内置 Prometheus 客户端 |
| 接口错误率 | 应用接口返回错误（如 HTTP 5xx/4xx）的请求数占总请求数的比例 | < 0.1% | 持续 1 分钟 > 1% | 应用内置 Prometheus 客户端 |
| 数据库连接池使用率 | 应用连接池的活跃连接数占最大连接数的比例 | < 70% | 持续 2 分钟 > 90% | 应用内置 Prometheus 客户端 |
4. 集群维度指标（全局资源管控）
针对 K8s 集群整体，需监控资源调度效率与组件健康状态，避免集群级故障。
| 指标名称 | 含义说明 | 正常范围参考 | 告警阈值建议 | 采集来源 |
|---|---|---|---|---|
| Node 资源使用率（集群级） | 集群所有 Node 的 CPU/内存平均使用率 | CPU < 70%，内存 < 80% | CPU 持续 10 分钟 > 85% 或内存 > 90% | kube-state-metrics + Prometheus 聚合 |
| etcd 健康状态 | etcd 集群的 leader 状态、键值存储大小、请求延迟 | leader 正常，延迟 < 100ms | leader 切换 > 1 次/小时，存储 > 80% 限额 | etcd 内置 metrics 接口 |
| API Server 请求延迟 | K8s API Server 处理请求（如创建 Pod、查询 Node）的平均延迟 | < 200ms | 持续 2 分钟 > 500ms | kube-state-metrics |
| PV/PVC 绑定状态 | 未绑定的 PVC 数量（反映存储资源是否充足） | 0个 | 未绑定 PVC 存在 > 5 分钟 | kube-state-metrics |
二、K8s 容器监控的最佳实践
基于指标采集、存储、可视化、告警全流程，结合 K8s 动态性（Pod 频繁创建/销毁、Node 扩容缩容），需遵循以下实践原则：
1. 指标采集：轻量化、无侵入、全覆盖
- 优先使用 DaemonSet 部署采集器：
对 Node 级指标（如 CPU/内存），用 DaemonSet 部署node-exporter或Metricbeat，确保每个 Node 都能被采集，避免遗漏边缘节点。 - 利用 K8s 原生服务发现：
避免静态配置容器 IP（Pod 重建后 IP 变化），通过 PrometheusServiceMonitor或 Datadog K8s 自动发现，基于 Service/Pod 标签动态匹配监控目标。 - 控制采集频率，避免资源消耗：
基础资源指标（CPU/内存）采集频率设为 10~30 秒，业务指标（QPS/响应时间）设为 5~10 秒，集群级指标（etcd/API Server）设为 30 秒~1 分钟，避免采集器过度占用资源。 - 业务指标无侵入采集：
应用集成轻量级监控客户端（如 Java 用Micrometer、Python 用prometheus-client），通过/metrics接口暴露业务指标，无需修改核心代码。
2. 指标存储：适配时序数据，控制成本
- 选择时序数据库（TSDB）：
容器指标属于“时间序列数据”，优先用 Prometheus TSDB（开源）或 InfluxDB，支持高写入、高查询性能；大规模集群（1000+ Node）可考虑 Thanos（Prometheus 分布式扩展），实现指标长期存储与跨集群聚合。 - 设置指标保留策略：
避免存储冗余数据：短期（15~30 天）指标保留原始粒度，长期（3~6 个月）指标通过降采样（如从 10 秒粒度聚合为 5 分钟粒度）减少存储成本。 - 按 Namespace 隔离指标：
在 Prometheus 中通过标签（namespace）隔离不同业务线的指标，查询时添加namespace=xxx过滤，避免跨业务指标干扰。
3. 可视化：多层级联动，聚焦核心
- 仪表盘按“层级”设计：
避免单一仪表盘堆砌所有指标，需拆分 3 类仪表盘：- 集群概览：展示 Node 资源使用率、Pod 就绪率、etcd 状态，快速判断集群健康度；
- 业务服务仪表盘：按 Deployment 分组，展示该服务下所有容器的 CPU/内存、接口 QPS/响应时间，关联 Pod 状态；
- 容器详情仪表盘：针对单个容器，展示 CPU 节流、内存 Swap、磁盘 I/O 等细粒度指标，用于故障定位。
- 使用预置模板，减少重复开发：
Grafana 提供大量 K8s 监控模板（如 ID1860对应 Node 监控、13786对应容器监控），直接导入后微调阈值即可使用。
4. 告警：精准、分级、降噪
- 按“严重程度”分级告警：
避免所有告警同等对待，按影响范围分级：- P0（紧急）：Node 宕机、Pod 大规模重启、OOM 事件（需 5 分钟内响应）；
- P1（重要）：CPU/内存使用率超阈值、接口错误率升高（需 30 分钟内响应）；
- P2（提示）：Pod 调度失败、资源使用率偏低（可工作时间处理）。
- 设置“告警抑制”，避免风暴：
例如：“Node 宕机”告警触发后，自动抑制该 Node 上所有容器的“CPU 使用率异常”告警，避免同一故障产生大量重复通知（Prometheus Alertmanager 支持抑制规则）。 - 关联业务上下文，避免无效告警：
告警信息需包含 Namespace、Pod 名称、指标当前值、业务线标签，例如：“[P1] 业务线=支付，Namespace=prod，Pod=payment-xxx 的 CPU 使用率达 92%（阈值 85%）”，方便运维快速定位归属。
5. 故障定位：日志与指标联动
- “指标异常→日志检索”闭环：
当容器 CPU 突增或接口错误率升高时，需快速关联容器日志定位原因。推荐用 ELK Stack（Filebeat 采集容器日志）或 Loki（轻量级日志系统），在 Grafana 中实现“指标图表→日志查询”一键跳转，例如：点击“CPU 突增时间点”，自动检索该容器在对应时间的日志。 - 利用 K8s 事件补充上下文：
K8s 事件（如 Pod 调度失败、容器重启原因）包含关键故障信息，需采集到监控系统（通过kube-state-metrics或kube-event-exporter），例如：“容器重启”告警需关联 K8s 事件中的“OOMKilled”原因，快速判断是否为内存不足。
6. 资源调优：基于监控数据动态调整
- 避免“过度分配”或“分配不足”：
通过监控数据调整容器的resources.requests和limits：- 若 CPU 节流频繁（指标
container_cpu_cfs_throttled_seconds_total高），说明limits.cpu不足，需适当提高； - 若内存使用率长期 < 30%，说明
limits.memory过高，可降低以释放资源给其他容器。
- 若 CPU 节流频繁（指标
- 结合 HPA 实现自动扩缩容：
将监控指标（如接口 QPS、CPU 使用率）与 K8s HPA（Horizontal Pod Autoscaler）关联，当 QPS 超过阈值时自动增加 Pod 副本数，避免手动调整滞后。
三、总结
K8s 容器监控的核心是“从资源到业务，从局部到全局”：既要通过资源指标保障硬件效率，也要通过业务指标验证服务可用性；既要监控单个容器的细粒度数据，也要关联集群级的整体状态。
实践中需避免“为监控而监控”，需围绕“故障预防、快速定位、资源优化”三个目标，结合团队技术栈（开源/商业工具）选择方案，最终实现“异常可感知、故障可定位、资源可优化”的监控闭环。
