PIDPressure: The node is running out of process IDs

PIDPressure means too many processes exist on the node. It is rarer than memory or disk pressure and almost always means one workload is forking without limit or leaking zombie processes.

Applies to: All Kubernetes versions

What it means

A Linux system has a finite number of process IDs, and the kubelet tracks how many remain. When the available count falls below its threshold, PIDPressure is set and pods are evicted to reclaim them. Running out of PIDs is a serious condition because it prevents anything new from starting, including the tools you would use to investigate. In practice it is almost never a capacity issue: it is one container creating processes without bound, or accumulating zombie processes because its PID 1 does not reap children — which is exactly what happens when an application binary is used as the container entrypoint without an init process.

Most common causes

• A container spawning processes in a loop without waiting for them.
• Zombie processes accumulating because the container's PID 1 does not reap children.
• A shell script entrypoint spawning a subprocess per iteration.
• A thread-per-request server under load, where threads count towards the same limit on Linux.
• No per-pod PID limit configured, so one pod can consume the node's whole allocation.
• A fork bomb, whether deliberate or accidental.

How to diagnose it

1. Confirm the condition: kubectl describe node NODE.
2. On the node, count processes and compare to the maximum: ps -eLf | wc -l against sysctl kernel.pid_max.
3. Find the heaviest cgroup — process counts are visible per container through the cgroup filesystem.
4. Look for zombies specifically: ps -eo stat,ppid,pid,comm | grep -w Z. A large number points at a missing init process rather than at real work.
5. Check whether the growth is steady, which indicates a leak, or bursty, which indicates load.

How to fix it

1. Use a proper init process as PID 1 so child processes are reaped. Most runtimes support this directly, and it is the fix for zombie accumulation.
2. Set a per-pod PID limit in the kubelet configuration so a single pod cannot exhaust the node.
3. Fix the application's process handling — wait for children, or use a process pool rather than unbounded spawning.
4. Raise kernel.pid_max on the node as a mitigation, but not as a substitute for finding the leak.
5. Bound thread pools in thread-per-request servers.

Notes

Threads count against the same limit as processes on Linux, so a server creating a thread per connection can trigger this without ever forking. The distinction between processes and threads is not one the kernel makes here.

Related

• Evicted — Pod removed because the node ran short of resources
• NotReady — The node is not accepting work

Sources

• Kubernetes documentation — Node-pressure Eviction
• Kubernetes documentation — Process ID Limits And Reservations
• Kubernetes documentation — Node Status