Why your pod keeps getting stuck in terminating mode

Technical Briefing | 9/26/2026

You have definitely seen it. A pod stays in Terminating for ten minutes because some sidecar or kernel hook just refuses to exit. You hit it with force delete, you prune the namespace, and yet the resource hangs there like a bad memory. It is rarely the fault of the binary itself, but rather how the kernel is handling the SIGTERM signals when cgroup controllers get backed up.

The ghost in the finalizer

Kubernetes uses finalizers to prevent object deletion until specific cleanup tasks are done. If you have an external storage driver or a network plugin that failed to release a lock, the API server will hold that pod hostage. When you see this, check the object metadata for lingering finalizers. Most of the time, manually editing the resource to clear the finalizer list is the only way out, but watch for zombie network interfaces that might stay bound on the node after the API entry is gone.

kubectl patch pod <pod-name> -p '{"metadata":{"finalizers":null}}' --type=merge

Digging into the process state

• Check if your entrypoint script ignores signals by using exec in the Dockerfile
• Inspect the node logs for kernel deadlocks on the cgroup hierarchy
• Verify if any local storage mounts are stuck in D state on the host
• Use crictl inspect to see the exact PID that failed to exit

If the process is stuck in uninterruptible sleep, even a kill -9 won’t touch it because the kernel is waiting on I/O. Stop trying to force delete the pod repeatedly; go to the node itself. Find the process, trace why it is waiting on the kernel, and if you have to, force the mount unmount. It is messy, but at least your nodes will stay sane.