Quick answer
Run kubectl delete pod <pod-name> --namespace <ns> --force --grace-period=0 — but only after you've confirmed the node isn't just temporarily unreachable.
Why your pod is stuck in Terminating
You delete a pod and it hangs in Terminating status for minutes, hours, forever. What's actually happening here is the kubelet on the node that ran the pod isn't confirming the deletion. The API server marks the pod for deletion, sets a grace period (default 30 seconds), and then waits for the kubelet to report that the containers have shut down.
That confirmation never comes in most cases for one of two reasons:
- The node is gone or unreachable. The kubelet is dead, the node was terminated in the cloud provider, or there's a network partition. The API server can't get a response, so the pod sits there.
- A finalizer is stuck. Finalizers are just keys on the pod's metadata that block deletion until some controller clears them. If a controller is buggy, crashed, or never runs, that finalizer never gets removed, and the pod stays in
Terminatingforever.
The grace period only matters if processes in the containers need time to shut down. When the kubelet is dead, the grace period is a fantasy — nothing's actually listening. That's why the force delete below uses --grace-period=0.
Step-by-step force delete
Step 1: Confirm the pod is actually stuck
Run this and look at the STATUS column:
kubectl get pods --all-namespaces | grep TerminatingIf you see Terminating for more than a couple of minutes, it's stuck. Also check the node status — if the node shows NotReady or Unknown, that's almost certainly your cause.
kubectl get nodesStep 2: Identify the node and finalizers
Get the pod's YAML so you can see which node it was on and whether any finalizers are present:
kubectl get pod <pod-name> -n <namespace> -o yamlLook for the nodeName field and the finalizers array. A finalizer like kubernetes.io/pv-protection is normal and usually fine — it's only a problem if it never clears.
Step 3: Verify the node is truly dead (if applicable)
If the node is unreachable, try to confirm it's not coming back. Check the cloud console or run kubectl describe node <node-name> and look at the Conditions section. If you see Ready: Unknown or a timestamp older than a few minutes, and the node is a VM you don't plan to recover, it's safe to proceed.
Step 4: Force delete the pod
Here's the command. It tells the API server to drop the pod immediately, bypassing the kubelet's confirmation:
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0If the pod still doesn't disappear — that's when you have a stuck finalizer. The force delete above should remove the pod from the API server's etcd, but in some versions it leaves a finalizer behind. You'll see an error like error: unable to delete pod ... the server could not find the requested resource or the pod just stays.
If force delete fails: kill the finalizer
When the pod won't go even with --force, you need to clear the finalizer manually. Export the pod's JSON, remove the finalizers array, and put it back:
kubectl get pod <pod-name> -n <namespace> -o json > pod.jsonEdit pod.json and delete the finalizers field entirely, or set it to an empty array. Then use a JSON patch to push that change:
kubectl replace --raw "/api/v1/namespaces/<namespace>/pods/<pod-name>/finalize" -f pod.jsonWait a few seconds and check if the pod is gone. This works because a pod can't be deleted while any finalizer exists — removing the finalizer is the last lock.
What's actually happening here is you're directly telling the API server to finalize the pod, which bypasses the controller that should have done it. It's a bit of a hack, but it's safe in most cases as long as you're not deleting a pod that still has attached volumes — if so, you might leave the volume provisioned. In practice, if the pod is already stuck, the volume is likely orphaned anyway.
Alternative: just delete the whole node
If the pod is stuck because the node itself is dead and you don't care about any other pods on it, delete the node object:
kubectl delete node <node-name>That will clean up all pods that were assigned to that node. This is often the cleanest approach when you've replaced a dead VM.
Prevention tip: set proper termination grace periods
The best way to avoid this pain is to make sure your pods can shut down gracefully in normal conditions. Set a reasonable terminationGracePeriodSeconds in your pod spec — 30 seconds is the default, which is fine for most apps. If your app needs to drain connections or flush data, give it 60 or 90 seconds.
But the real prevention is monitoring. Set up alerts for pods stuck in Terminating or nodes in NotReady state. Tools like Prometheus plus Alertmanager can trigger on kube_pod_status_phase or use kubectl get events to catch these early. When a node goes down, you want to know before users start complaining.
One more thing: if you're using a DaemonSet or StatefulSet, force-deleting a pod can cause issues. StatefulSets rely on pod identity — force-deleting one can leave the underlying PVC orphaned, and a new pod with the same name might attach to the wrong volume. In those cases, prefer to delete the whole StatefulSet or use kubectl scale to zero replicas first, then address the pod.
Force delete is a tool, not a habit. Use it when you've confirmed the node is dead or the finalizer is truly stuck, and you won't have to explain to your team why a volume is missing.