Unknown: The control plane has lost contact with the node and cannot report the pod's state

A pod phase of Unknown means the API server cannot get the pod's status, almost always because the kubelet on its node has stopped reporting. It is a statement about the connection, not about the pod.

Applies to: All Kubernetes versions

What it means

The pod phase Unknown is set when the state of the pod could not be obtained — typically a failure in communication with the node hosting it. Critically, it says nothing about whether the containers are still running. They usually are: a node that has lost its network path to the control plane keeps running its workloads. This is why the recovery behaviour is conservative. Kubernetes waits, applies the node.kubernetes.io/unreachable taint, and only after a toleration period begins evicting the pods, because assuming a pod is dead when it is merely unreachable is how you end up with two of something that must be unique.

Most common causes

• The kubelet on the node has crashed or been stopped.
• The node has lost network connectivity to the control plane, while remaining otherwise healthy.
• The node was shut down or terminated abruptly — a spot instance reclaim, a hardware failure, an unplanned reboot.
• The node is so overloaded that the kubelet cannot complete its status updates within the timeout.
• Certificate expiry on the kubelet, so it can no longer authenticate to the API server.
• A control-plane problem preventing status updates from being recorded.

How to diagnose it

1. Check the node first, not the pod: kubectl get nodes. A NotReady or missing node is the whole story.
2. Look at the node's conditions and last heartbeat: kubectl describe node NODE.
3. If you can reach the node, check the kubelet directly: systemctl status kubelet and journalctl -u kubelet -n 200.
4. Check for an expired kubelet client certificate, which produces authentication errors in the kubelet log.
5. Confirm from outside the cluster whether the workload is still serving traffic — it often is, which changes what is safe to do next.

How to fix it

1. Restore the node — restart the kubelet, fix the network path, or renew the certificate.
2. If the node is permanently gone, delete the node object. That lets the control plane resolve its pods and lets controllers schedule replacements.
3. Let the eviction timers do their work rather than force-deleting pods, unless you have confirmed the containers are genuinely stopped.
4. For chronically overloaded nodes, reduce workload density or raise kubelet resource reservations so status reporting is not starved.

Notes

Because the containers frequently keep running, this state is where split-brain risk lives. Anything that must run as a single instance should be a StatefulSet with its ordering guarantees, or should use an external lease, rather than relying on Kubernetes noticing a node is gone quickly.

Related

• NotReady — The node is not accepting work
• Terminating — Pod stuck in deletion

Sources

• Kubernetes documentation — Pod Lifecycle: pod phase
• Kubernetes documentation — Nodes: node controller and heartbeats
• Kubernetes documentation — Taints and Tolerations: taint-based evictions