Before studying the K8S workflow, we need to review kube-controller-manager, which is a collection of processes of many controllers in K8S.
Examples such as Deployment controller (DeploymentController) and JobController (JobController) are typical examples of built-in controllers in Kubernetes. In Kubernetes, a controller tracks at least one type of Kubernetes resource. These resource objects have a spec field that represents the expected state. The controller of the resource is responsible for keeping the current state of the owning object close to the desired state.
The interaction between the controller and apiserver
How does the controller of the resource mentioned above ensure that the current state of the resource object is close to the desired state?
Of course, the metadata of resource objects in Apiserver (query ETCD) is constantly synchronized, and the object properties are constantly updated. Is that right?
When there are tens of millions of resource objects in a cluster, the HTTP synchronization request from the optical controller is enough for Apiserver to drink, which is obviously not great. So Kubernetes uses a mechanism called Informer. Informer is a core toolkit in Client-Go.
Here,informerThe main functions of this implementation are as follows:
-
Return List/Get requests faster and reduce direct calls to the Kubenetes API
Using the Lister() method of the Informer instance, the Informer does not request the Kubernetes API to List/Get objects in Kubernetes. Instead, the Informer directly looks for data cached in local memory. Depending on Etcd’s List&Watch mechanism, the client is informed of the changes in the state of these objects and then updates the local cache. In this way, the client maintains a data for these API objects that is almost the same as the data in the Etcd database. Then, the controller and other clients can directly access the cache to obtain the information of the objects. Instead of going directly to Apiserver. In this way, Informer can return results faster and reduce direct calls to the Kubernetes API.
-
Listen for events and trigger callback functions
Informer listens for all events under a resource through the Kubernetes Watch API. Watch API is essentially a mechanism for APIServer to actively push Kubernetes resource modification and creation to the client. In this way, we can get changes to the resource and update the object state in time.
K8s informer: Kubenetes informer
From the above we know that the controller listens for the update of the resource object in apiserver through the Watch API. Let’s get to the topic: K8S workflow.
Two, K8S workflow
Let’s look at the general process for deploying a POD through Deployment:
-
Kubectl sends deployment requests to Apiserver (for example using kubectl create -f deployment.yml)
-
Apiserver persists Deployment to ETCD; Etcd makes an HTTP communication with apiserver.
-
The Controller Manager listens on the Apiserver via the Watch API, and the Deployment Controller sees a newly created Deplayment object and pulls it out of the queue. Create a ReplicaSet based on the Deployment description and return the ReplicaSet object to apiserver and persist it back to ETCD.
Similarly, when the Replicaset controller sees the newly created Replicaset object, it pulls it out of the queue and creates a POD object based on its description.
-
Then the Scheduler sees the unscheduled POD object, selects a schedulable node according to the scheduling rule, loads it into the nodeName field in the POD description, and returns the POD object to apiserver and writes it to etCD.
-
When kubelet sees a POD object whose nodeName field belongs to this node, it pulls it out of the queue and creates the container described in pod through the container runtime.
The relationship between deployment-Replicaset-pod and replicaset-pod is as follows:
I hope the essay is helpful to you. Please correct me if there is any mistake in the content.
You are free to reprint, modify and publish this article without my consent. Iqsing.github. IO