How the Kubernetes Controller Works

The core of Kubernetes is control theory. The control loop implemented in the Kubernetes controller is a closed-loop feedback control system. This type of control system compares the current state of the target system with a predefined desired state based on a feedback loop. The difference of is used as an error signal to generate a control output as the input of the controller to reduce or eliminate the error between the current state and the desired state of the target system, as shown in Figure 1. This control loop is also called a tuning loop on Kubernetes.

Figure 1 Feedback control loop

 For Kubernetes, no matter how simple or complex the implementation of the controller is, it basically completes the control task by periodically repeating the following three steps.

(1) Read the desired state and current state of the resource object from the API Server.

(2) Compare the difference between the two, and then run the necessary code in the controller to operate the resource object in reality, and correct the real state of the resource object to the desired state defined in the Spec, such as creating or deleting a Pod object, and launching a cloud Serving API requests, etc.

(3) After the change operation is executed successfully, the result status is stored in the status field of the target resource object on the API Server.

As shown in Figure 3, the working schematic diagram of Kubernetes control loop.

Figure 2 Kubernetes control loop

 A huge number of control loops are running simultaneously on a Kubernetes cluster with heavy tasks. Each loop has a specific set of tasks to be processed. In order to prevent the API Server from being flooded with requests, it is necessary to set the control loop to run at a lower frequency. By default, every 3 every minute. At the same time, in order to trigger the change of the expected state submitted by the client in time, the controller registers with the API Server to monitor the controlled resource objects. Any change in the expected state of these resource objects will be notified by the Informer component to the controller for immediate execution without waiting for the next step. One round of the control loop. The controller uses the work queue to queue the control loops that need to be run, so as to ensure that control tasks are missed as little as possible in scenarios where there are many controlled objects or resource objects change frequently.

For the purpose of simplifying management, Kubernetes integrates dozens of built-in controller programs into a single application called kube-controller-manager, and runs as an independent single daemon process, which is an important component of the control plane. It is also the control center of the entire Kubernetes cluster.

Guess you like

Origin blog.csdn.net/m0_60258751/article/details/128421738