Kubernetes Interview: What Exactly Happens When You Delete a Pod?

Step 1: Deletion request

The client runs kubectl delete pod <pod-name> [optional flags]. The kube‑apiserver validates the request, adds two fields to the pod’s metadata— deletionTimestamp (current time + grace period) and deletionGracePeriodSeconds (default 30 s)—and writes the updated pod object to etcd, changing its phase to Terminating . All components that watch pods (endpoint‑controller, kubelet, kube‑proxy, etc.) receive the event and start their own handling flows.

Step 2: Traffic cut‑off

The endpoint‑controller removes the terminating pod from the Service’s Endpoint/EndpointSlice list. kube‑proxy sees the change and updates iptables/ipvs rules on each node so that new requests are no longer forwarded to the pod. Existing TCP connections remain open until they finish or close normally.

Step 3: kubelet starts graceful termination

kubelet detects the Terminating state and checks for a lifecycle.preStop hook. If present, the hook runs (either an exec script or an HTTP request) – common uses include nginx -s quit or deregistering from a service registry. If the hook exceeds the grace period, kubelet extends it by only 2 seconds before proceeding.

After the preStop hook finishes, kubelet calls the container runtime (containerd or CRI‑O) to send a SIGTERM (signal 15) to PID 1 inside the container. Applications that handle SIGTERM can close long‑lived connections, flush data, and exit cleanly. If the process exits before the grace period ends, kubelet moves directly to resource cleanup.

Step 4: Grace period timeout and forced kill

kubelet waits up to terminationGracePeriodSeconds (default 30 s), which covers the preStop execution time plus the time the application needs after receiving SIGTERM. If the container is still running after this window, kubelet sends SIGKILL (signal 9) to all processes in the pod, which the kernel terminates immediately without any cleanup.

Step 5: Resource cleanup

Once the container processes have exited, kubelet deletes all pod‑related resources: network namespaces, PID namespaces, network interfaces, IP addresses, and unmounts any attached volumes (PVCs, ConfigMaps, Secrets). It also removes container logs and temporary files. Finalizers are processed; if a custom finalizer is present, the pod remains in Terminating until the controller clears the finalizer – the most common cause of a pod stuck in this state.

Step 6: API server removes pod metadata

After kubelet reports that the pod is terminated and all finalizers are cleared, the apiserver deletes the pod’s entry from etcd. A subsequent kubectl get pods no longer shows the pod, confirming complete destruction.

Controller‑managed pods: automatic recreation

Most production pods are created by controllers such as Deployments, StatefulSets, or DaemonSets. When a controller‑managed pod is deleted, the controller detects that the actual replica count is below the desired count, immediately creates a new pod, and runs the full scheduling, image pull, and container start sequence. The new pod is added to the Service’s Endpoint list and begins handling traffic, ensuring continuous availability.