Kubernetes: Pod Creation Flow

Here’s a breakdown of the Pod creation flow in Kubernetes, explaining the key components and steps involved:

There are multiple ways for user to send pod creation request:
The starting point: A user (or an automated process) initiates the creation of a Pod. This can be done through various methods like:
kubectl: The command-line interface for interacting with Kubernetes.
Kubernetes API: Directly calling the Kubernetes API using tools like curl or libraries.
Declarative YAML/JSON: Defining Pod specifications in YAML or JSON files, which are then applied to the cluster.
CI/CD pipelines: Automating Pod creation as part of a continuous delivery process.

A Kubernetes cluster consists of worker node/compute node that run our containerized applications. Every Kubernetes cluster has at least one worker node. But a cluster usually runs multiple nodes, providing fault tolerance and high availability.

Kubernetes Architecture

Kubernetes worker nodes host the PODs. A POD is a group of one or more connected containers. And those containers share resources like storage, networking, and a specification of how they should run. So, in a generic analogy, a POD is an element that performs the function of a “logical host”.

Kubernetes control plane manages the nodes and PODs in the cluster. In Production environment its recommended that control plane must have atleast three nodes to ensure high availability.

The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane.

The kube apiserver exposes an HTTP API that allows users, using a command-line tool called kubectl, to perform various container management and orchestration tasks, such as: creating, updating, modifying, or deleting resources, deploying applications, performing updates, and accessing container logs.

In addition to the command line interface, user can also use GUI dashboards from Kubernetes Orchestrators tools. And it is also possible to access the APIs directly through REST calls from an application,
for example. Creating a POD involves several steps. Everything starts on the control plane.

POD Lifecycle

1. If you are using command line interface to create pod use kubectl and performing the “kubectl run” command, a user requests the kubeapi server to create a new POD in the cluster. The first operation is the API server authenticates and validates the user credentials.
2. Once the authentication and validation competes, API server writes the configuration to the etcd. ETCD is the source of trust for the cluster and ensures that its state remains consistent.
   The ETCD acknowledged to the kubeapi server that it has made a successful write for this request.
3. Now api server returns to the kubectl that the POD was created! This fast answer is possible because the etcd already defined a desired state of the cluster. From here onwards, the kubernetes components will drive the flow to make this desired state equal to the actual state of the cluster. So, till now, we only have new POD recorded in the desired state for this cluster.
4. Now scheduler job will start as it keeps an eye on the workloads that need to be created. It also determines which node will be suitable to place the requested workload. What it is doing, in a nutshell,it is pinging the API server at regular intervals and checking if any workloads need to be scheduled.
   At this moment, the API server informs that a new POD needs to get created in one of the available nodes. The scheduler looks at the available nodes. It will rule out any unsatisfactory nodes due to resource limitations.
   Finally, the scheduler chooses the best node to run the workload by considering all the factors.
5. Once the scheduler identifies a node, it sends the information about the node to the API server where the POD creation must be performed.
6. Now the api server updates the desired configuration in the ETCD database. After the successful write in the etcd, there is information about the desired state versus the actual state. With the updated information, the API server knows what it needs to do to make the actual state meet the desired state.
   Now ETCD acknowledge to the API server that it has made a successful write for this request.
7. As part of next steps now api server then sends API instructions to a node agent called the kubelet.
   The kubelet is an agent that runs on each kubernetes node and is responsible for activity like registering the node with the cluster and sending periodic health checks to the kubeapi server. It also creates and destroys workloads as directed by the kubeapi server.
   So, summarizing the details of these APIs calls, the API server sends an API message to the kubelet like this: create this POD using worker node x.
8. Now kubelet forwards the request to the CRI-O(container runtime interface) using the CRI gRPC interface.
9. In this step now container root file directory is created.
10. CRI-O uses the containers/image library to pull the image from a container registry(depends on organization to organization which registry they are using).
11. The downloaded image is unpacked into the container root filesystem and stored in the containers/storage library. Now the container image is created.
12. CRI-O then generates the container OCI runtime specification, a config.json.
13. CRI-O then launches the runc runtime to start the container creation process.
14. The runc receives the OCI(open container initiative) runtime specification and interacts with the Linux Kernel to deploy the container.
15. Now in this step runtime asks Linux for a clone or fork system call. The clone system call is used to create a new process with a specific namespace, and c-groups limit the resources available to the container. In this way, the clone system call plays a critical role in the implementation of containers in Linux, allowing for the creation of isolated and resource-controlled environments for applications and services
16. As kubelet is a agent that watches for POD changes, it will collect the information about the request that the POD was created
17. Now since pod created, it will registered with the API Server by the kubelet.
18. And finally POD creation information is written in ETCD by API server.

Last but not least now scheduler checks whether the desired state matches the actual state on subsequent pings.

Once pod creation request is fulfilled no other activity should be performed.

References Links:
https://kubernetes.io/docs/concepts/architecture/cri/ https://opensource.com/article/21/8/container-linux-technology
https://kubernetes.io/docs/concepts/overview/components/