PLEG is not healthy: The kubelet's container state loop is taking too long, so the node reports NotReady

The Pod Lifecycle Event Generator polls the container runtime for state. When that poll does not complete within its threshold, the kubelet marks the node NotReady — almost always because the runtime is slow, not because the kubelet is.

Applies to: All Kubernetes versions

What it means

The kubelet's PLEG periodically lists containers from the runtime and turns the differences into pod lifecycle events. It records the time of each successful pass, and if the gap exceeds a threshold — three minutes by default — the kubelet reports itself unhealthy with PLEG is not healthy: pleg was last seen active … and the node goes NotReady. The important interpretation is that this is nearly always a symptom of a slow or wedged container runtime rather than a kubelet defect. The runtime call is what blocks, so the investigation belongs at containerd or CRI-O, at the node's disk, or at whatever is making the runtime slow.

Most common causes

• The container runtime is unresponsive or extremely slow, often under heavy I/O.
• Very high pod density on the node, so each relisting pass takes longer.
• Disk I/O saturation, which slows every runtime operation.
• A container stuck in a state the runtime cannot resolve, blocking the listing.
• Kernel-level problems such as a hung filesystem or a device error.
• Resource starvation of the kubelet or the runtime by pods, when reservations are not configured.

How to diagnose it

1. Read the node's condition message, which includes how long ago PLEG was last active: kubectl describe node NODE.
2. Check the runtime's responsiveness directly on the node: time a crictl ps call. If it is slow, that is the answer.
3. Check disk I/O saturation: iostat -x or the equivalent.
4. Count pods on the node — density well above the usual limit makes this more likely.
5. Read the runtime's own logs: journalctl -u containerd.
6. Look for stuck containers that will not stop.

How to fix it

1. Restart the container runtime, which resolves most transient cases. The node recovers once relisting completes.
2. Address the underlying I/O saturation — faster disks, or workloads that write less.
3. Reduce pod density on affected nodes.
4. Configure kubeReserved and systemReserved so the kubelet and runtime are not starved by pods.
5. Remove containers that the runtime cannot clean up, if one is blocking relisting.
6. Replace nodes where this recurs, since it usually indicates a hardware or configuration problem specific to them.

Notes

Because this makes the node NotReady, the standard eviction machinery moves the pods elsewhere after the toleration period. On a cluster where several nodes hit this at once — usually from a shared storage slowdown — that rescheduling can cascade onto the remaining nodes and make things worse.

Related

• NotReady — The node is not accepting work
• ContainerStatusUnknown — The kubelet lost track of a container's outcome

Sources

• Kubernetes documentation — Node Status
• Kubernetes documentation — Nodes
• Kubernetes documentation — System Logs