Prometheus监控Kubernetes Pod状态

本文将介绍如何配置Prometheus的告警规则，实现对于Kubernetes Pod状态的监控。

1.Pod的状态类型

在Prometheus 监控Kubernetes Pod 状态时，通常可以观察到以下几种状态情况：

1. Running（运行中）

Pod 处于运行状态意味着其容器正在正常运行。在该状态下，Pod 的容器正常响应请求，并且可以正常访问。这是最理想的状态，表明应用程序正在按预期运行。

2. Pending（挂起）

当 Pod 还未分配到集群中的节点（Node）时，处于挂起状态。可能的原因包括调度器（Scheduler）尚未找到适合的节点来运行 Pod，或者节点资源不足以满足 Pod 的需求。在挂起状态下，Pod 无法提供服务。

3. Succeeded（已成功）

Pod 中的所有容器已经成功完成任务并退出。这通常在批处理任务或定时任务完成后发生。Pod 的生命周期已经结束，并且不再运行任何容器。

4. Failed（失败）

Pod 中的一个或多个容器已经失败。可能的原因包括容器启动失败、应用程序崩溃或其他运行时错误。在这种状态下，Pod 可能需要重新启动或手动处理以解决问题。

5. Unknown（未知）：

未知状态表示 Prometheus 无法获取 Pod 的状态信息。可能的原因包括 Kubernetes API 的故障，或者 Pod 已被删除但 Prometheus 仍然尝试监视它。在这种情况下，需要检查监控系统和 Kubernetes 集群的健康状态。

02.告警规则

kube_pod_status_phase 是 Pod监控的一个重要的指标，它用于表示 Pod 的当前所处的状态。

我们在Prometheus表达式显示中，查询某个该指标的情况，可看到对应上面五个状态的纪录（参见phase标签）。此时，如果Pod处于某个状态，那么该状态的指标纪录值将为1。

因此，当Pod除Running或Succeeded外的指标为1时，可以认为该Pod目前出现问题。基于这个逻辑，我们可以来编写告警规则，实现Pod的状态监控。

如下：

- name: kubernetes-pod  rules:  - alert: 'pod 状态监控'    annotations:      description: 'Pod 状态:{{ $labels.phase }}'      limit: '检测到Pod 状态异常'    expr: |      (kube_pod_status_phase{job="kube-state-metrics", phase !~ "Running|Succeeded"}  != 0     for: 2m

该规则表示当Prometheus在两分钟内，检测到Pod的kube_pod_status_phase指标非"Running和Succeeded"的纪录值为1时，则发起告警。

在配置相关规则后，你可以发现当Pod状态出现问题时，Prometheus将触发告警。

03.问题处理

如果你只是看网上的文章，那基本都是到了上面那一步就结束了。但是，实际生产环境要比实验环境复杂得多。在使用上面规则时，我就遇到了一个问题：

当服务进行发版更新时，由于Pod会重新生成，并且在创建过程处于非Running状态。因此，如果某个服务的Pod创建并正常启动的时间超过两分钟时，则会导致Prometheus发起告警。类似一些公司的算法服务，启动时间往往会比应用服务久得多。

因此，我发现经常会在每次版本发布时，由于Pod启动时间较长而出现误报情况。

那么，要怎么来解决此类问题呢？不知道你是否会想到以下两种方案。

方案一：

在发版时屏蔽相关服务的告警，等到发版完成后再启用，这样可以屏蔽期间的误报。

方案二：

将告警的等待时间延长，当等待时间大于那些Pod的启动时间时，则不会出现误报。

这两个方案合理吗？很明显，这两个想法都很一般。

方案一增加了工作量不说，还可能因为屏蔽而导致问题漏报。第二个方案也是一样，延长等待会让Pod真正出现问题时，无法及时发现。

那么，更好的解决方案是什么呢？

这里说说我最终的处理方法，我优化了上面的PromQL规则，增加了对于Pod创建时间的判断，以此来屏蔽那些刚发版的Pod。如果创建时间小于10分钟，则该Pod的状态不会触发告警，这样我们可以完美解决前面遇到的误报问题。

具体的告警规则如下 ：

(kube_pod_status_phase{job="kube-state-metrics", phase !~ "Running|Succeeded"}  !