kubernetes - How does components talk to Each Other

Now that we have seen how each component works, lets see how each of the control plane , work node components work together in creating a resource for us. Below is the communication flow that happens between the components,

Let’s say we are creating a deployment in k8 by running a sample deployment manifest file like below, 

[root@manja17-I13330 kubenetes-config]# cat basic-deployment.yml
apiVersion: apps/v1beta1

kind: Deployment

metadata:

  name: test-service-deploy

spec:

  replicas: 2

  template:

    metadata:

      labels:

        app: test-service

    spec:

      containers:

      - name: test-ser

        image: docker.io/jagadesh1982/testing-service

        ports:

        - containerPort: 9876

        env:

        - name: VERSION

          value: "0.5"

In the above manifest file, we are creating a deployment , replica set and a container by the name test-ser with the image “docker.io/jagadesh1982/testing-service”

1. Before even submitting the request for the above deployment to create , we have controllers , scheduler on control plane and kubelet on worker node are watching for the change updates from Api Server . these components watch for their specific resource changes.
2. Using the kubectl command, we send a HTTP Post request to the Api server. The command is “kubectl create -f <Location of the above manifest file>.
3. The Api server receives the request and perform

             Authentication to authenticate the user 

   Authorization to make sure user has enough permissions to create the deployment

   Admission Control check to make sure the request manifest is altered based

        on certain criteria

   Once all are done successfully. It saves the manifest to the etcd server and

       sends the response to the kubelet running on the worker node.

4. Now once the data is saved to Etcd, Api server will send a notification to the deployment controller in controllers. The deployment controller watch for events from Api server on deployment resource. This then create a Deployment object and create a Replica set and sends back the details to the Api server.
5. Once the replica set is created, a replication controller is triggered from the controller which in-turn read the replica set and identify the pod details. Api server will in-turn sends a notification to the Replication controller.
6. Once the pod details are observed , pods are created in the Api server. The scheduler then comes into picture.
7. Api server sends a notification to scheduler that pod need to be created. The scheduler will in turn contact Api server for all node details in the cluster from Etcd and based on algorithms it finds suitable nodes to be used for hosting the pods. The details are sent back to the Api server
8. Once the pods details along with node details are obtained, based on the nodes the corresponding kubelet on that node is sent with a notification with the pod details.
9. Once the kubelet receives the pod details, it calls the underlying container runtime to download the image and start the container.