Every time a pod starts on your node, you think you are just spinning up your application containers. But under the hood, the kubelet is silently launching a pause container first. It sits there doing absolutely nothing, holding the network and IPC namespaces open for the rest of the pod. I have seen clusters where thousands of these tiny processes slowly chew through memory because the garbage collection policies weren’t tuned for the churn rate.

The pause container is not actually a ghost

If you look at your process tree, you will see it sitting there as a reaper for any zombie processes that might spawn inside your pod. If your application code is sloppy and forks children without waiting for them, the pause process cleans them up. The problem is that while it is minimal, it is still a process. If your node has a massive amount of pod churn, these entries stick around in the cgroup tree longer than they should.

crictl pods --name <pod-name> -o json | jq '.items[].status.runtimeSpec.linux.resources.memory.limit'

• Check your image repository for outdated versions of the pause image that might be bloated
• Verify your kubelet configuration isn’t keeping dead pods in a pending state too long
• Look at the cgroup v2 usage on the node to see if the pause processes are actually pinned in memory

Most folks never touch the pause image, and that is usually fine. But if you are hitting memory pressure alerts on nodes that aren’t even running heavy workloads, start here. Stop assuming the system-level containers are weightless. When you see memory usage creeping up without a corresponding increase in application heap, run a deep dive into the runtime overhead and see if the infrastructure itself is holding the bag.