Delete a Stuck or Terminating Kubernetes Pod

A few seconds of Terminating is normal graceful shutdown. Minutes with a deletion timestamp usually mean the kubelet, a finalizer, or volume detach is still in progress. This walkthrough runs deletes in terminating-lab, inspects what blocks removal, and applies force delete only when graceful paths cannot finish.

Quick reference

Run these steps on the stuck Pod before you force delete. Replace POD and NS with your Pod name and namespace.

How Kubernetes Terminates a Pod

When you delete a Pod, Kubernetes does not remove the API object instantly. The normal sequence:

1. API server records deletionTimestamp and the active grace period
2. Kubelet starts local shutdown
3. A selected Service endpoint is marked terminating and ready=false; it is not necessarily removed from its EndpointSlice immediately
4. Kubelet runs preStop when configured and grace is non-zero
5. The runtime sends the configured stop signal, image STOPSIGNAL, or runtime default—commonly SIGTERM
6. Any remaining process is killed when the grace budget expires
7. The API object disappears after local cleanup completes and its finalizer list is empty

Terminating is a kubectl display status based on the deletion timestamp, not a Pod phase. Terminating EndpointSlice entries normally have ready=false; Services using publishNotReadyAddresses: true are an exception.

Brief Terminating in kubectl get is expected during graceful shutdown. The troubleshooting starts when STATUS stays Terminating long after the grace period should have ended.

Terminating status and deletion metadata

A non-empty deletionTimestamp means deletion is in progress. Compare elapsed time to the active grace period recorded in metadata, not only the Pod spec default.

Grace period, preStop, stop signal, and EndpointSlices

spec.terminationGracePeriodSeconds sets the Pod's default graceful-shutdown budget (30 seconds when omitted). The grace-period countdown begins before preStop. The hook and the application's response to the stop signal share the same budget. If preStop is still running when the period expires, kubelet requests a one-time two-second extension.

A long preStop script that sleeps 60 seconds needs a grace period longer than 60—not a force delete on day one. Hook behaviour and the full shutdown sequence are in Kubernetes Pods and Pod lifecycle.

Prepare the Terminating Pod Lab

Create the namespace for delete experiments:

kubectl create namespace terminating-lab

The sections below create and delete Pods inside that namespace.

Confirm Whether Deletion Is Actually Stuck

Inspect deletion timestamp and active grace period

Create a Pod with a deliberately long preStop hook so it remains observable during deletion:

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: Pod
metadata:
  name: inspect-pod
  namespace: terminating-lab
spec:
  terminationGracePeriodSeconds: 90
  containers:
  - name: app
    image: busybox:1.36
    command: ["sleep", "3600"]
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "echo preStop-start; sleep 60"]
YAML

kubectl wait pod/inspect-pod -n terminating-lab --for=condition=Ready --timeout=120s

Request deletion:

kubectl delete pod inspect-pod -n terminating-lab --wait=false

This guarantees enough time to inspect the deleting object.

Check STATUS, age, and node while shutdown runs:

kubectl get pod inspect-pod -n terminating-lab -o wide

Read the active deletion grace period:

kubectl get pod inspect-pod -n terminating-lab -o jsonpath='deletionTimestamp={.metadata.deletionTimestamp}{"\n"}deletionGrace={.metadata.deletionGracePeriodSeconds}{"\n"}specGrace={.spec.terminationGracePeriodSeconds}{"\n"}'

Sample output:

deletionTimestamp=2026-07-26T14:06:21Z
deletionGrace=90
specGrace=90

metadata.deletionGracePeriodSeconds records the active deletion grace separately from spec.terminationGracePeriodSeconds. A later delete with --grace-period=10 should show deletionGrace=10 while specGrace can still show 30.

Check Events, finalizers, and node reachability

Read events and finalizers:

kubectl describe pod inspect-pod -n terminating-lab | grep -A10 '^Events:'

kubectl get pod inspect-pod -n terminating-lab -o jsonpath='{.metadata.finalizers}{"\n"}'

Empty finalizers and no warning events usually indicate normal shutdown only when the active deletion grace period has not expired and the assigned node remains reachable. If the object remains beyond that period, inspect node reachability and kubelet communication.

A node that cannot reach the API server can leave deletion pending significantly longer than the requested grace period.

Check the Pod node and node conditions when shutdown stalls:

kubectl get pod <pod-name> -n <namespace> -o wide

kubectl get node <node-name>

kubectl describe node <node-name> | grep -A6 'Conditions:'

Node recovery and repair are outside this article's scope.

Resolve Graceful Shutdown Delays

Delete normally

Create a standalone Pod and request standard graceful deletion:

kubectl run normal-pod -n terminating-lab --image=busybox:1.36 --restart=Never --command -- sleep 3600

kubectl wait pod/normal-pod -n terminating-lab --for=condition=Ready --timeout=120s

kubectl delete pod normal-pod -n terminating-lab

Sample output:

pod "normal-pod" deleted from terminating-lab namespace

A bare Pod like normal-pod is gone after shutdown completes—it is not replaced. Controller-owned Pods (Deployment, StatefulSet, DaemonSet) are recreated when the controller notices the missing replica.

Shorten the grace period

Create a Pod with a controlled shutdown and request a shorter grace window:

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: Pod
metadata:
  name: grace-pod
  namespace: terminating-lab
spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: app
    image: busybox:1.36
    command: ["sleep", "3600"]
    lifecycle:
      preStop:
        exec:
          command: ["sh", "-c", "sleep 20"]
YAML

kubectl wait pod/grace-pod -n terminating-lab --for=condition=Ready --timeout=120s

kubectl delete pod grace-pod -n terminating-lab --grace-period=10 --wait=false

Inspect the actual override:

kubectl get pod grace-pod -n terminating-lab -o jsonpath='deletionGrace={.metadata.deletionGracePeriodSeconds}{"\n"}'

Sample output:

deletionGrace=10

Then wait for deletion:

kubectl wait pod/grace-pod -n terminating-lab --for=delete --timeout=30s

--grace-period=10 sets the maximum graceful-shutdown budget to ten seconds. It does not make Kubernetes wait ten seconds when the process exits earlier. kubectl wait --for=delete is supported specifically for confirming object removal.

Use this when the default 30-second window is unnecessarily long, not as a substitute for fixing finalizers or node issues.

Fix long preStop hooks and signal handling

When applications ignore SIGTERM or preStop consumes the entire budget, fix signal handling or increase terminationGracePeriodSeconds before force deleting. A grace period is a maximum shutdown budget, not a mandatory delay.

Resolve Blocking Finalizers

Finalizers are metadata keys that block object removal until a controller finishes cleanup.

Identify the responsible controller

Create a Pod with a blocking finalizer for demonstration:

kubectl apply -f - <<'YAML'
apiVersion: v1
kind: Pod
metadata:
  name: finalizer-pod
  namespace: terminating-lab
  finalizers:
  - example.com/block-delete
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ["sleep", "3600"]
YAML

kubectl wait pod/finalizer-pod -n terminating-lab --for=condition=Ready --timeout=120s

Delete it and wait until the timestamp exists:

kubectl delete pod finalizer-pod -n terminating-lab --wait=false

kubectl wait pod/finalizer-pod -n terminating-lab --for=jsonpath='{.metadata.deletionTimestamp}' --timeout=30s

Inspect:

kubectl get pod finalizer-pod -n terminating-lab -o jsonpath='deletionTimestamp={.metadata.deletionTimestamp}{" finalizers="}{.metadata.finalizers}{"\n"}'

Sample output:

deletionTimestamp=2026-07-26T14:05:38Z finalizers=["example.com/block-delete"]

The container may already have stopped while the finalizer continues holding the API object. example.com/block-delete is intentionally a dead custom finalizer: no controller owns it, so it never clears automatically.

Remove a dead finalizer only when safe

Do not remove finalizers as the first step. Confirm no controller will complete the cleanup—broken operator, orphaned object, or lab resource.

Finalizers keep an object present after its deletion timestamp is set until every finalizer is removed. Manual removal should happen only after understanding and otherwise completing the intended cleanup.

Remove finalizers with a JSON patch:

kubectl patch pod finalizer-pod -n terminating-lab --type=json -p='[{"op": "remove", "path": "/metadata/finalizers"}]'

Sample output:

pod/finalizer-pod patched

Verify deletion:

kubectl wait pod/finalizer-pod -n terminating-lab --for=delete --timeout=30s

Alternatively, kubectl edit pod finalizer-pod -n terminating-lab and delete the finalizers list entries manually.

Force Delete a Pod

When graceful deletion cannot complete and you accept API-level removal without kubelet confirmation:

kubectl run force-pod -n terminating-lab --image=busybox:1.36 --restart=Never --command -- sleep 3600

kubectl wait pod/force-pod -n terminating-lab --for=condition=Ready --timeout=120s

kubectl delete pod force-pod -n terminating-lab --grace-period=0 --force --wait=false

Sample output:

Warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "force-pod" force deleted from terminating-lab namespace

What force deletion changes

• --grace-period=0 removes the graceful-shutdown delay, while --force allows deletion without kubelet confirmation. Finalizers can still prevent final removal.
• A controller may create a replacement Pod immediately if one owned the deleted Pod
• On an unreachable node, the old process may still run until the runtime or node recovery stops it

--grace-period=0 --force does not make an unknown finalizer safe to remove; finalizers must still be investigated separately.

Stateful and duplicate-process risks

Force deletion removes the API object without waiting for confirmation that its processes stopped. This can allow duplicate processes with the same logical identity and cause data inconsistency.

Verify the object is gone:

kubectl get pod force-pod -n terminating-lab

Sample output:

Error from server (NotFound): pods "force-pod" not found

Verify Standalone and Controller-Owned Deletion

For a standalone Pod, confirm the name no longer exists. For controller-owned Pods, confirm a new instance with a new UID:

kubectl create deployment web -n terminating-lab --image=nginx:1.27.0 --replicas=1

kubectl rollout status deployment/web -n terminating-lab --timeout=120s

OLD_POD=$(kubectl get pods -n terminating-lab -l app=web -o jsonpath='{.items[0].metadata.name}')

OLD_UID=$(kubectl get pod "$OLD_POD" -n terminating-lab -o jsonpath='{.metadata.uid}')

Delete and wait until the original object is gone:

kubectl delete pod "$OLD_POD" -n terminating-lab

Wait for the replacement:

kubectl wait pod -n terminating-lab -l app=web --for=condition=Ready --timeout=120s

NEW_POD=$(kubectl get pods -n terminating-lab -l app=web -o jsonpath='{.items[0].metadata.name}')

NEW_UID=$(kubectl get pod "$NEW_POD" -n terminating-lab -o jsonpath='{.metadata.uid}')

printf 'old=%s %s\nnew=%s %s\n' "$OLD_POD" "$OLD_UID" "$NEW_POD" "$NEW_UID"

This proves the replacement has both a new name and UID rather than relying only on a representative Pod row. Replica count should match the Deployment spec.

Troubleshoot Common Terminating Pod Causes

What's Next

• Fix a Kubernetes Deployment Not Creating Pods
• Fix Kubernetes Node NotReady and kubelet Errors
• Troubleshoot Kubernetes Control Plane Components

References

• Pod termination — grace period, preStop, and endpoint updates
• Force delete workload resources — official force-delete guidance and risks
• Finalizers — how deletion blocking works

Summary

Terminating is normal for a short window while the kubelet runs preStop, sends SIGTERM, and waits within the active grace budget. Stuck deletion means the API recorded deletionTimestamp but something still blocks removal—slow shutdown, a finalizer, volume detach, or an unreachable node.

In terminating-lab, graceful delete cleared normal-pod within the grace window, a custom finalizer held finalizer-pod until patched away, and a Deployment replaced deleted Pods with new names and UIDs. Use shorter --grace-period when shutdown should be faster, not as the first response to every stall.

Reserve --grace-period=0 --force for cases where the API object must clear and you accept that the kubelet might not have stopped the process—especially on unreachable nodes. For Pods that fail before they run, use Pending and ContainerCreating troubleshooting instead of force delete.