All About Kubernetes Pods Termination Lifecycle

Today, We'll learn about what all series of events happen when a pod is deleted.

As we know, pods are the smallest components in K8s that run our application. These are created and scheduled to K8s nodes (servers) where they remain until termination or deletion - these are ephemeral and they have a lifecycle.

There are different states in its lifecycle like Waiting, Running, and Terminated. Kubernetes keeps track of the states of each Pod.

Here, we're just talking about the terminating state of a pod. So, when are pods in the terminating state? There are many reasons for it. If we update our deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If a Node dies, Kubernetes terminates all pods on that node, and so on.

Kubernetes termination lifecycle

A typical Pod termination in Kubernetes involves the following steps:

• A request is made to delete a pod using a command (like $ kubectl delete pod [pod-name]) or API call and then the request hits Api Server which is the entry point to the K8s cluster.
• Api Server updates the Pod status from Running to Terminating state. This in turn notifies Controller Manager to remove endpoint connections. At this time, the pod stops receiving new requests.
• Simultaneously, Kubernetes send a SIGTERM termination signal to the Pod for graceful shutdown. It offers a grace period of 30 seconds by default.
• Before the expiration of the grace period, a number of things happen like removing database connection, saving the current state, and so on.
• When the grace period expires, Kubernetes issues a SIGKILL signal for immediate termination to any processes still running in the Pod.
• If the above tasks take more than 30s, increase the grace period value with terminationGracePeriodSeconds option in the YAML file for graceful shutdown.
• Kubernetes removes the Pod from the Node.

Thank you for reading this blog! If you liked it, please do share and leave a like \o/