Kubernetes Cluster & Process Flow of a POD creation

• Kubernetes in a production environment will have a collection of clusters.
  
• In this kind of setup, generally one of the server will be a master node and rest of the nodes will be worker nodes
  
• Master node does not run any workload and is in-charge of distributing tasks to the worker nodes. You can run workloads on master node too but this is very unusual in a production environment
  
• Master nodes which hosts the control plane usually runs across multiple servers providing fault-tolerance and high availability
  

• When a user asks Kubernetes to create a deployment using kubectl like below, this is how the process works
  
  • kubectl apply -f k8s-deployment.yml
    
• kubectl converts the yaml resource into JSON and sends it to API Server inside the master node or control plane
  
• API Server receives the request & persists the deployment details or object definition to the database.
  
• etcd is a highly-available key value store used to store the data by Kubernetes.
  
• etcd is a crucial component for Kubernetes as it stores the entire state of the cluster: its configuration, specifications, and the statuses of the running workloads.
  
• When a new deployment resource is stored in etcd store, the controller manager is notified and it creates enough Pod resources to match the replicas in the Deployment.
  
• At this point the state of the deployment in etcd is Pending state
  
• Scheduler sees the Pending state and inspect the status of the infrastructure and does filtering and ranking of nodes to decide where to schedule the Pods and then executes its business logic to fill out the nodeName field in the pod’s Spec with the name of the Schedulable Node and persists the scheduled Pods object in etcd with Scheduled state
  
• At this stage , no Pods have been created just the objects are created, updated and stored in etcd.
  
• On each worker Node , there is a kubelet which is in charge of talking to the master Node or control plane. It provides an interface between the Kubernetes control plane and the container runtime on each server in the cluster.
  
• The kubelet makes sure containers are running in a pod. When the control plane needs something to happen in a node, the kubelet executes the action.
  
• If our deployment spec had instruction to create 3 replicas. At this stage each of this will be marked as scheduled in etcd.
  
• Kubelet retrieves the template for the Pods and delegates creating the container to the Docker daemon.
  
• When the Docker daemon completes the task, the kubelet checks readiness and liveness probes and the Pod is finally marked as running.
  

This was a simplified version of the process that happens when we try to deploy a POD . The components that i shared api server, controller manager etc has many more sub components and activities.

The idea of the blog was to share high level process of the structure of Kubernetes cluster and what goes behind the scene when we try to deploy a POD.