Hello, readers! This article talks about the Kubernetes Pod Lifecycle throughout its existence for an application.
So, let us begin! 🙂
Kubernetes Pod – Overview
As we read in the previous article about Pods, it clearly states that in a nutshell, a Kubernetes Pod is the smallest instance of an application.
Docker offers us the concept of containers to package all the application-related libraries and dependencies to host our application in the cloud infrastructure. Though it offers us a lot of features by running an app within a container, it still has a drawback. That is, as the containers increase in number the management of the same becomes difficult and problematic.
For the same, Kubernetes came ahead with the concept of container orchestration. It helps us manage the containers and introduces a Pod as the concept to hold our containers. Yes, we can consider a Pod as a shell over our containers in an isolated space known as a namespace.
A Pod hosts all the containers into it and is the running instance of your application.
Pods are ephemeral in nature, the moment we spin up a pod, it schedules itself on a Node and stays on the same node until its entire lifecycle ends. That is, once a Pod gets scheduled to a node, it does not jump to some other nodes and a unique ID (UID) gets attached to the Pod to track it.
Moreover, a Pod never heals by itself. That is, when a pod gets scheduled on the node and then fails, it then gets deleted. Plus, a Pod does not survive if there is a lack of resources either on the namespace or the node level.
The moment a pod gets deleted or is deleted, the ephemeral volume offered by it gets deleted as well. That is when we can make use of Persistent Volume and Persistent Volume Claim for persistent storage.
Also, a Pod can never be rescheduled once deleted. Instead, we can spin up a new pod with the same specifications but once spun up, it would take up a new UID.
Phases of a Pod
Right from the time a pod is spun up till it gets deleted, a Pod goes through the below phases-
- Pending: If a pod is in pending state, it means that the pod has been accepted by the cluster. But, one or more container’s setup is still is process and is in the process of being ready.
- Succeeded: The pod has performed the task, all the containers within it have teriminated successfully and they wont restart.
- Failed: Every container within the pod has terminated but one or more containers has exited with a failure.
- Running: The pod has been scheduled on a node and at least one container within the pod is running.
- Unknown: The kubelet is unable to get the state of the pod for some reason. Usually it happens when the connection to the node on which the pod should sit fails.
Types of Pod Status
Once a pod is up for the run, we can even get the status of the pod that is the condition of the pod which can be one of the following:
- PodScheduled: the pod has been successfully scheduled on the node.
- ContainersReady state: All the containers are healthy and ready within the pod.
- Ready: The pod is ready to accept requests from the associated Service.
- Initialized: Every init container has been successfully started.
By this, we have reached the end of this topic. Feel free to comment below, in case you come across any questions.
For more such posts related to Kubernetes, Stay tuned with us.
Till then, Happy Learning!! 🙂