Kubernetes
Pods, their state and where they run, read from your cluster telemetry.
How pods appear #
A pod appears when your telemetry carries a k8s.pod.name attribute. Pods are discovered from spans, logs and metrics together, so a workload that only writes logs is still listed.
Pod fields #
- Name and namespace — the pod's identity and where it lives.
- Cluster and node — from your
k8s.*attributes. - Phase — Running, Pending, Succeeded or Failed.
- Ready containers — how many of the pod's containers are ready.
- Restart count — cumulative restarts for the pod.
- CPU and memory — averaged over the window.
Phase, readiness and restarts #
Phase, readiness and restart counts come from kube-state metrics. Collect these series and the pod views fill in automatically.
kube_pod_status_phase
kube_pod_container_status_ready
kube_pod_container_status_restarts_total
kube_pod_container_status_waiting_reason
Emit a kube-state series per pod
Send one series per pod with the pod's name in a tag and the phase as the series name. This is what lets the pod views show state rather than names alone.
Crash loops #
A pod whose waiting reason is CrashLoopBackOff is flagged on the list, so a crash loop is visible without opening every pod.
Finding the problem pod #
- Filter to Failed or CrashLoopBackOff phase.
- Sort by restart count to find the pod that has restarted most.
- Open the pod to see its node, then check that node's host detail.
A pod that appears with an empty phase is reporting spans and logs but no kube-state metrics. Add the kube-state series and the state columns fill in.
Onward #
A crash-looping pod usually points at its machine: check the node in Hosts. To compare the cluster's workloads against everything else telemetry reports, Resource catalogue.