containerd in Production: 5 Day-2 Failure Patterns at High Pod Density

This post originally appeared on Rack2Cloud . All patterns were observed across production Kubernetes environments running 400–1,000 containers per node. Your containerd metrics look healthy. Pod density is climbing. Node CPU is stable. Memory pressure is low. Then somewhere around 800–900 containers per node, something quiet happens: containerd-shim processes begin accumulating memory. 4 GB. 6 GB. Eventually the Linux OOM killer steps in and starts terminating containers that Kubernetes never asked it to kill. Your dashboards still say the node is healthy. Your workloads disagree. This is the Day-2 reality of containerd in production at scale. Not a configuration error. Not a software bug. A set of predictable failure patterns that appear after your cluster reaches the density thresholds that most documentation never discusses. The containerd Runtime Stack: What Actually Runs Your Containers Before diagnosing failures, the execution chain needs to be precise. When Kubernetes schedules