ContainerStatusUnknown: The kubelet lost track of a container's outcome and cannot say how it ended

ContainerStatusUnknown means the kubelet could not determine what happened to a container — usually because the kubelet or the node restarted while the container was running. It is a reporting gap, not a specific failure.

Applies to: Kubernetes 1.20 and later

What it means

The kubelet tracks container state by polling the container runtime. If that relationship is broken while a container is running — the kubelet restarts, the node reboots unexpectedly, or the runtime is restarted underneath it — the kubelet may resume with no record of how the container ended. Rather than inventing a reason, it reports ContainerStatusUnknown. The pod is usually marked Failed. The useful interpretation is that something disrupted the node, not that the application did anything wrong, so investigating the application here is generally wasted effort.

Most common causes

• The kubelet was restarted, upgraded, or crashed while containers were running.
• The node rebooted unexpectedly — power loss, a kernel panic, or an abrupt instance termination.
• The container runtime was restarted independently of the kubelet.
• Severe node resource exhaustion that prevented the kubelet from completing status reconciliation.
• Disk problems on the node corrupting the kubelet's local state.

How to diagnose it

1. Correlate with node events: kubectl describe node NODE and the node's uptime. A recent reboot explains it.
2. Check the kubelet's own restart history on the node: systemctl status kubelet and journalctl -u kubelet --since '1 hour ago'.
3. Look for a cluster-wide pattern. Several pods on one node with this reason points squarely at the node; the same reason spread across many nodes points at an upgrade or a rollout of the runtime.
4. Check for kernel-level events in the node's system log around the timestamp.

How to fix it

1. Address the node-level instability — the reboot cause, the kubelet crash, or the resource exhaustion.
2. For planned kubelet or runtime upgrades, cordon and drain nodes first so workloads move rather than being caught mid-flight.
3. Ensure workloads are managed by a controller so a replacement is scheduled automatically; a bare pod in this state is simply gone.
4. Clean up the failed pod objects once the cause is understood — they hold no resources but clutter the namespace.

Notes

Because the outcome is genuinely unknown, this reason should not be counted as an application crash in reliability metrics. Doing so attributes node maintenance to the service, which quietly corrupts error budgets.

Related

• Unknown — The control plane lost contact with the node
• NotReady — The node is not accepting work

Sources

• Kubernetes documentation — Pod Lifecycle: container states
• Kubernetes documentation — Nodes
• Kubernetes documentation — Debug Running Pods