What happens when we create a Deployment in Kubernetes
NOTHING WILL BE HIDDEN
- We will see in this article that what are the different steps in between from the kubectl command to finally making of a container inside our pod which is inside our deployment .
- NOTE - I recommend you to read about the basics of different components of Control Plane and Worker Nodes.
LET'S GET STARTED
In this diagram we can see one master node / control plane, three worker nodes.
We can see also see components of master and worker nodes which are responsible of their properties.
BASIC FLOW
If we talk about the basic flow of instructions -
We write our kubectl command.
It talks to API server in the master node.
Master node does it's work.
It talks to worker nodes through API server which connects to kubelet agent and creates the containers.
- Now I will elaborate on each point
DETAILED DISCUSSION
- Let's imagine we write "kubectl create deployment nginx --image nginx --replicas=5". So, by this command we want to create a deployment of name "nginx", of image "nginx" and with 5 replicas. When we write this command we are talking with our kubectl directly to API server in control plane, this way our command is sent.
After the command is sent, the API server stores an object of resource deployment in etcd database. And after that you get a message that deployment has been created, like in the above image. But this does not mean that container inside the pods are running, it just signifies that an object of your resource has been stored inside the database. We can see that containers are not running in the above image, status shows that containers are creating not running.
Controller Manager sits inside the control plane and constantly checks the database (through API server) after a constant interval to see if their any resources for it to work on. So, now it sees that it their is deployment, so it makes replicaset { Actually their are three stages in a deployment - 1. Deployment controls replicaset, 2. Replicaset controls pods} for the deployment. It agains checks the database, now it gets a replicaset resource to work on. So, now it makes 5 pods with a status of pending, which were specified inside the repicaset.
Scheduler also checks the API in every small time interval. So, now it finds 5 pods pending, which indicated that they are not yet scheduled. Scheduler does it's work and try to schedule the pods such that each worker node get's least load as possible. After, nodes are assigned to each pods that information is stored inside to etcd database.
Kubelet Agent from each worker nodes also check API server regularly to find out that are there any pods assigned to me. Now, they find that there actually pods assigned to them. And they will change there status in the etcd database to creating and will tell the container runtime to create containers. After the containers a created status get changed to running. We can see all these different stages in the below image.