Question

根据定义，kube_pod_container_status_waiting_reason是用来捕获处于等待状态的吊舱的原因。

我的kubernetes集群中有多个Pod，它们位于CrashLoopBackOff中，但是我看不到kube_pod_container_status_waiting_reason捕获了该原因。它仅捕获两个原因-ErrImagePull和ContainerCreating。

~$ k get pods -o wide --show-all --all-namespaces | grep Crash
cattle-system   cattle-cluster-agent-6f744c67cc-jlkjh       0/1       CrashLoopBackOff   2885       10d       10.233.121.247   k8s-4
cattle-system   cattle-node-agent-6klkh                     0/1       CrashLoopBackOff   2886       171d      10.171.201.127   k8s-2
cattle-system   cattle-node-agent-j6r94                     0/1       CrashLoopBackOff   2887       171d      10.171.201.110   k8s-3
cattle-system   cattle-node-agent-nkfcq                     0/1       CrashLoopBackOff   17775      171d      10.171.201.131   k8s-1
cattle-system   cattle-node-agent-np76b                     0/1       CrashLoopBackOff   2887       171d      10.171.201.89    k8s-4
cattle-system   cattle-node-agent-pwn5v                     0/1       CrashLoopBackOff   2859       171d      10.171.202.72    k8s-5

以普罗米修斯运行sum by (reason) (kube_pod_container_status_waiting_reason)会产生结果：

Element                       Value
{reason="ContainerCreating"}    0
{reason="ErrImagePull"}         0

我正在运行quay.io/coreos/kube-state-metrics:v1.2.0图片的kube-state-metrics。

我想念什么？为什么CrashLoopBackOff原因没有显示在查询中？我想设置一个警报，以找到处于等待状态的豆荚以及原因。因此，请考虑合并kube_pod_container_status_waiting以找到处于等待状态的豆荚，并合并kube_pod_container_status_waiting_reason以找到确切原因。

请协助。谢谢！

Answer 1

您遇到this。基本上，您似乎正在使用kube-state-metrics 1.2.0或更早的版本。您会看到ImagePullBackOff中添加了CrashLoopBackOff和1.3.0。

因此将您的图片更新为：

k8s.gcr.io/kube-state-metrics:v1.3.0
quay.io/coreos/kube-state-metrics:v1.3.0

或

k8s.gcr.io/kube-state-metrics:v1.4.0
quay.io/coreos/kube-state-metrics:v1.4.0

Prometheus kube_pod_container_status_waiting_reason无法捕获Pod CrashLoopBackOff原因

1 个答案: