Kubernetes Pod Creation — What happen when we are create a pod?

Recently, we were discussing most about how to troubleshooting the issues on Kubernetes, part of that, today will see complete operation details happens part of Kubernetes pod creation to understand, what happens when we deploy a pod separately or with some service. This is one of the important topics to understand for troubleshooting or identifying what went wrong in your cluster.

When pods are getting created? Answer will be when we execute a rolling update, scale deployments, or every new release, or every job and cronjob, etc. Right, anytime thought or asked what happens when you hit kubectl apply? Well, lets see what happens with some scenarios also, here.

For that lets take one sample pod.yaml for this tutorials and walk with that.

apiVersion: v1
kind: Pod
metadata:
  name: pod-demo
spec:
  containers:
    - name: webserver
      image: nginx
      ports:
        - name: webserver
          containerPort: 80

As we know we can just apply this yaml with following command,

kubectl apply -f pod.yaml

What happens, now? Let’s see.

You can watch this post in video also

Store the state in Etcd

When you apply the definition will be received and inspected by the API servers and same time it stores in etcd. Also, it will be add to the Scheduler’s queue.

Once it is added to schedule, kube-scheduler inspected the yaml file and collect the details defined in that like resources etc, based on that it picks the best node to run it using filters and predicates.

At last, the pod will be marked as scheduled, node assigned and state stored in Etcd. This is not end, so we have crossed just phase 1, and so far, all completed in control plane or master node and stored the state in the database.

Well, what is next and what happen next

The kubelet — the Kubernetes agent

We all know Kubelet’s job to poll the control plane or master node for updates.

If there is any pod to create, it will collect the details and creates it.

Again, Not done yet.

The kubelet doesn’t create the Pod by itself. Instead, it delegates the work to three other components:

1. The Container Runtime Interface (CRI) — the component that creates the containers for the Pod.
2. The Container Network Interface (CNI) — the component that connects the containers to the cluster network and assigns IP addresses.
3. The Container Storage Interface (CSI) — the component that mounts volumes in your containers.

If you worked on docker, then you may aware how the containers are getting created, same done by the Container Runtime Interface (CRI), as like the below command,

docker run -d <image-name>

The Container Networking Interface (CNI) is always interesting because it is in charge of:

1. Generating a valid IP address for the Pod.
2. Connecting the container to the network.

When the Container Network Interface finishes its job, the Pod is connected to the network and with valid IP address assigned.

Good, is this end? As we the pod got created and IP got assigned, you may ask now the traffic should serve right, there is a trick. This two-operation done on node or in Kubelet side, so far control plane or master node thinks, still the pod is getting created. So far, all the details only know by Kubelet, so there is no traffic will be routed by the control plane.

It’s the role of the kubelet to collect all the details of the Pod such as the IP address and report them back to the control plane it will be stored on etcd.

If you query in etcd, it will show status of the pod and IP address details.

Good, The Pod is created and ready to use.

Again, this is end of journey if the pod not part any service. If the pod is part of any service, still there some additional steps to complete. What is that? Let’s see.

Continue Reading it on: https://foxutech.com/kubernetes-pod-creation/