1. 概述
Kubernetes 作为容器编排领域的主流工具，其高可用性保障是运维中的核心目标。其中，监控 Pod 状态并在异常时及时告警，是保障系统稳定运行的关键环节。Pod 故障可能由资源不足、探针失败、网络异常等多种原因引发，及时发现这些问题有助于快速响应，减少服务中断时间。
本文将围绕 Kubernetes 中 Pod 故障的监控与告警机制展开，重点介绍 Prometheus 与 Alertmanager 的集成配置方法，涵盖典型故障场景、PromQL 告警规则编写、以及高级告警策略等内容。通过实际示例，帮助读者构建一套完善的 Kubernetes 告警体系。
2. Kubernetes 监控与告警机制概述
在 Kubernetes 这类复杂的分布式系统中，Pod 可能因资源限制、配置错误或基础设施故障而失败。若缺乏有效的告警机制，故障排查将变得困难，可能导致服务中断。
Kubernetes 本身并不提供内置的告警功能，但提供了丰富的指标暴露接口（如 Metrics API），可与第三方监控系统集成。常用的监控工具有：
- ✅ Prometheus：用于采集和存储 Kubernetes 中各类组件的指标数据
- ✅ Alertmanager：负责告警通知的去重、分组和路由
- ✅ Grafana：用于可视化展示监控数据
- ✅ 自定义控制器：可根据告警触发自动恢复操作
通过这些工具组合，可以构建一个自动化的监控告警流水线，实现对 Pod 故障的实时感知和响应。
3. 在 Kubernetes 中配置告警
我们以 Prometheus 和 Alertmanager 为核心，构建 Kubernetes Pod 故障的监控告警体系。
3.1 安装 Prometheus 与 Alertmanager
推荐使用 Prometheus Operator 简化部署流程。以下是部署步骤：
$ kubectl create namespace monitoring
$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm repo update
$ helm install prometheus prometheus-community/kube-prometheus-stack --namespace monitoring
该命令将在 monitoring 命名空间下部署 Prometheus、Alertmanager 及其相关组件。
验证 Prometheus 是否运行正常：
$ kubectl port-forward svc/prometheus-kube-prometheus-prometheus 9090 -n monitoring
访问 http://localhost:9090 即可打开 Prometheus 的 Web 界面。
3.2 配置 Prometheus 抓取 Pod 指标
Prometheus 通过配置 scrape_configs 来采集指标。以下是一个抓取 Kubernetes Pod 指标的配置示例：
- scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
该配置确保 Prometheus 只抓取带有 prometheus.io/scrape=true 注解的 Pod 指标。
4. Pod 故障的常见场景
4.1 资源耗尽（CPU 或内存限制）
当 Pod 使用的资源超过其限制时，可能会被 Kubernetes 终止（OOMKilled）。以下是一个检测此类事件的 PromQL 告警规则：
- alert: HighMemoryUsage
expr: kube_pod_container_status_terminated_reason{reason="OOMKilled"} > 0
for: 2m
labels:
severity: critical
annotations:
summary: "Pod {{ $labels.pod }} 已被 OOMKilled"
description: "Pod {{ $labels.pod }} 在命名空间 {{ $labels.namespace }} 中因内存不足被终止"
⚠️ 踩坑提醒：OOMKilled 通常意味着资源分配不合理或存在内存泄漏问题，建议结合应用日志进一步排查。
4.2 探针失败（就绪/存活探针）
Kubernetes 使用就绪探针和存活探针判断 Pod 健康状态。以下是一个检测就绪探针失败的告警规则：
- alert: ReadinessProbeFailure
expr: kube_pod_container_status_ready == 0
for: 5m
labels:
severity: warning
annotations:
summary: "Pod {{ $labels.pod }} 就绪探针失败"
description: "Pod {{ $labels.pod }} 在命名空间 {{ $labels.namespace }} 中未通过就绪检查"
就绪探针失败意味着 Pod 暂时不能接收流量，可能由启动延迟、依赖服务不可用或配置错误引起。
4.3 网络问题导致的频繁重启
如果 Pod 因网络问题频繁重启，可通过以下规则检测：
- alert: NetworkUnavailable
expr: rate(kube_pod_container_status_restarts_total[5m]) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "Pod {{ $labels.pod }} 频繁重启"
description: "Pod {{ $labels.pod }} 在命名空间 {{ $labels.namespace }} 中重启次数过多，可能由网络不稳定引起"
⚠️ 踩坑提醒：频繁重启也可能是由于探针配置不合理或依赖服务不可用造成，需结合日志和事件信息综合判断。
5. 高级告警策略
5.1 基于异常检测的动态告警
相比静态阈值，基于趋势的动态告警更能适应变化的业务负载。以下是一个使用 Prometheus 内置 Holt-Winters 算法检测 CPU 异常的规则：
- alert: HighCPUUsage
expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: critical
annotations:
summary: "节点 {{ $labels.instance }} CPU 使用率过高"
description: "节点 {{ $labels.instance }} 的 CPU 使用率超过 80% 持续 5 分钟"
✅ 优势：适应业务负载波动，减少误报。
5.2 多集群告警统一管理
对于多 Kubernetes 集群的场景，可通过 Prometheus 的联邦机制统一采集指标：
scrape_configs:
- job_name: 'federate'
honor_labels: true
metrics_path: '/federate'
params:
match[]:
- '{__name__=~"kube.*"}'
static_configs:
- targets:
- 'prometheus-cluster1:9090'
- 'prometheus-cluster2:9090'
该配置会从多个 Prometheus 实例采集 Kubernetes 相关指标，并保留原始标签信息，便于统一分析和告警。
6. 总结
本文系统介绍了 Kubernetes 中 Pod 故障的监控与告警配置方法，重点讲解了 Prometheus 与 Alertmanager 的集成使用、典型故障场景的告警规则编写，以及动态告警和多集群统一监控等进阶策略。
✅ 核心要点总结：
- Kubernetes 本身不提供告警功能，需依赖 Prometheus 等第三方工具
- 常见 Pod 故障包括资源耗尽、探针失败、网络异常等
- 告警规则应尽量精确，避免“告警风暴”
- 动态告警和多集群联邦机制可提升监控的灵活性和扩展性
通过合理配置监控告警体系，不仅能提升 Kubernetes 集群的稳定性，还能显著降低运维成本，是构建高可用系统不可或缺的一环。