Understanding the Kubernetes pod's lifecycle
Civo Academy - Introduction to the Lifecycle of a Pod in Kubernetes
Description
Run through the complete lifecycle of a Kubernetes pod and discover what happens when a pod is created and given a command.
Transcription
Introduction to a pod's lifecycle
In this video, we will go through a pod's complete lifecycle. What happens when we create a pod? When we give a command, kubectl apply -f or create -f, and provide a YAML file, it's first converted to JSON and sent to API Server. Here, the request is authenticated using our kube config credentials, and then it's authorized whether the user is actually authorized to perform this particular command to create a pod. Then if any admission controllers are there, they are checked before it gets persisted to etcd datastore.
Now, after it is persisted in the etcd datastore, it goes to pending state. Then the scheduler pitches in and tries to find the best match for the node where it has to be spawned. It will go through the cluster and find the best fit node based on the resources, etc., and if the image is already present on the node because that has some reference. Once it gets the node, it will fill the label spec node name and send it to the API server, and now, that particular request is also stored in etcd.
API server in a pod's lifecycle
Now, the API server instructs the kubelet, "Hey, there is one pod that has to be spawned on this particular node." The kubelet is responsible for fetching the image from the image registry. It can be any image registry, and then the CRI does that, and the CNI will get the IP attached to the pod, and then that particular IP will be sent again back to the API Server, then again, it is stored in etcd. From there, it goes to ContainerCreating when the scheduler selects the node, and after that, when everything is there, the image is pulled, and then it goes to the running state. We can see the state when we use the kubectl get pods command.
What are liveness and readiness probes in a pod's lifecycle
Now there can be other advanced things that happen, or whenever the process dies too many times within a pod, it can also go to crashloopbackoff, and whenever it is succeeded, it will be in the succeeded state. Another advanced kind of lifecycle includes liveliness, so we can have a /health and a /ready. These are known as liveness and readiness probes. The pod will keep on checking that, and if it fails, it can lead to the crashloopbackoff.
Using hooks and init containers in a pod's lifecycle
There are some of the hooks that can be implemented. For example, if there are some actions that you want to perform after the main container just starts, you can have a post-start hook, and if you want to perform before the main container gets terminated, you will have to have a pre-stop hook. There is also something called the init container that will be running before actually starting the main container.
Conclusion
All in all, this is a complete lifecycle of a pod. First, it goes to the API server, and the scheduler finds the node. Then, the kubelet is responsible for running it and attaching the IP address, and then only the API server is the one that interacts with the etcd. After that, the states go from pending, ContainerCreating, and running. If any process is restarted, it restarts multiple times, goes to crashloopbackoff, and succeeds if the job is completed or whatever the task of the pod is completed.
Suppose you want to find events of the pod. In that case, you can use the kubectl describe pod command to find specific events happening because sometimes a pod is in a pending state for a long time. For example, you might have to check whether the resources are sufficient, whether you have to auto scale or whether you have to remove some pods from a node so that it goes to the ContainerCreating state. That was it about this lecture. Thank you for watching.