Understanding Kubernetes Endpoint Propagation and Graceful Pod Deletion
Deleting a pod triggers endpoint removal, but various components like kube-proxy, CoreDNS, and ingress controllers may still route traffic until the endpoint fully propagates, so you must wait or use preStop hooks to delay deletion and handle SIGTERM gracefully within the configurable shutdown period.
When you run kubectl delete pod , the pod is removed and the endpoint controller deletes the pod's IP address and port from the Service and etcd. You can observe this with kubectl describe service .
Multiple components synchronize the change to their local endpoint lists:
kube-proxy uses the local endpoint list to write iptables rules.
CoreDNS reconfigures DNS based on the endpoint list.
Ingress controllers, Istio, and similar components also rely on the endpoint information.
All of these components eventually delete the old endpoint, so no traffic can reach it. At the same time, kubelet receives the notification and deletes the pod.
Unfortunately, if kubelet deletes the pod before the other components have removed the endpoint, you will experience downtime because kube-proxy, CoreDNS, ingress controllers, etc., are still routing traffic to the stale IP address.
What can you do? Wait for the endpoint propagation to complete before the pod is removed.
If you wait long enough, in‑flight traffic can still be resolved and new traffic can be directed to other pods.
How does kubelet delete a pod? It follows three steps:
Trigger the preStop hook (if defined).
Send a SIGTERM signal.
After the default 30‑second grace period, send a SIGKILL signal.
You can use a preStop hook to insert an artificial delay before the pod is terminated.
Your application can also listen for the SIGTERM signal, perform a graceful shutdown, and exit after the work is finished. Kubernetes gives you 30 seconds for this (configurable).
There is no single answer for how long you should wait—10, 20, or 30 seconds—because endpoint propagation may take only a few seconds, but Kubernetes does not guarantee any specific timing or that all components finish simultaneously.
If you want to explore further, see these resources:
https://learnk8s.io/graceful-shutdown
https://freecontent.manning.com/handling-client-requests-properly-with-kubernetes/
https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods
https://medium.com/tailwinds-navigator/kubernetes-tip-how-to-gracefully-handle-pod-deletion-b28d23644ccc
https://medium.com/flant-com/kubernetes-graceful-shutdown-nginx-php-fpm-d5ab266963c2
https://www.openshift.com/blog/kubernetes-pods-life
System Architect Go
Programming, architecture, application development, message queues, middleware, databases, containerization, big data, image processing, machine learning, AI, personal growth.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.