In the field of robotics and automation, the control loop is a non-terminating loop that is used to regulate the state of the system.
This is an example of a control loop: a thermostat in a room.
After setting the temperature, we will tell the thermostat the state we want. The actual room temperature is the current state. The thermostat brings the current state closer to the desired state by turning the device on or off.
In Kubernetes, controllers are control loops. They monitor the state of the cluster and then make changes or request changes when needed. Each controller will try to move the current cluster state closer to the desired state.
Controller mode
The controller tracks at least one Kubernetes resource type. The spec field of these objects represents the desired state. The controller of this resource is responsible for bringing the current state closer to the desired state.
The controller can perform operations on its own; more commonly, in Kubernetes, the controller sends messages with side effects to the API server. We will see the example below.
Control via API server
The Job controller is an example of Kubernetes' built-in controller. The built-in controller manages the state by interacting with the cluster API server.
Job is a Kubernetes resource that runs Pods or may be multiple Pods to perform tasks and then stop.
(Once scheduled (please look forward to ~~), the Pod object will become part of the state required by the kubelet).
When the job controller sees a new task, it ensures that at some point in the cluster, the kubelet on a set of nodes runs the correct number of pods to complete the work. The job controller itself will not run any pods or containers. Instead, the job controller informs the API server to create or delete a Pod. The other components in the rudder surface act according to the new information (there are new Pod plans and operations) and finally complete the work.
After creating a new job, the desired status for the job is complete. The job controller brings the current state of the job closer to the state we want: create a Pod to complete the work we want to do on the job, so that the job is close to completion.
The controller also updates the objects that configure them. For example, after completing the work of the job, the job controller will update the job object to mark it as "complete".
(It's a bit like how some thermostats turn off the lights to indicate that our room is now at the temperature we set).
Direct control
Compared with Job, some controllers need to make changes outside the cluster.
For example, if we use a control loop to ensure that there are enough nodes in the cluster, the controller needs content outside the current cluster to set up new nodes when needed.
The controller that interacts with the external state finds the required state from the API server, and then directly communicates with the external system to make the current state closer.
(In fact, there is a controller that can horizontally scale the nodes in the cluster, please refer to cluster self-scaling (please look forward to ~~)).
Expected state and current state
Kubernetes uses cloud-native systems to try and be able to handle constant changes.
As the work progresses, our cluster may change anytime and anywhere, and the control loop will automatically repair the fault. This means that our cluster may never reach a stable state.
As long as the controllers in our cluster are running and able to make useful changes, it does not matter whether the overall state is stable.
design
As its purpose, Kubernetes uses many controllers, each of which manages specific aspects of the cluster state. Most commonly, a particular control loop (controller) uses one resource as its desired state, and uses another resource to try to make the desired state occur. For example, the controller for Job tracks Job objects (to discover new jobs) and Pod objects (to run Jobs, and then see when the jobs are completed). In this case, something else will create a job, and the job controller will create a Pod.
It is useful to use a simple controller instead of a group of interconnected monolithic control loops. The controller may fail, so Kubernetes aims to solve this problem.
Note: Multiple controllers can create or update objects of the same type. Behind the scenes, the Kubernetes controller ensures that only resources linked to the control resources are concerned.
For example, we can have "deployment and operations"; these have created Pods. The job controller will not delete the Pods created by our Deployment because the controller can use some information (labels) to distinguish these Pods.
Controller operating mode
Kubernetes comes with a set of built-in controllers running inside kube-controller-manager. These built-in controllers provide important core behaviors.
Deployment controllers and Job controllers are examples of controllers that are part of Kubernetes itself ("built-in" controllers). Kubernetes allows us to run flexible rudder surfaces so that if any of the built-in controllers fail, another part of the rudder surface will take over.
We can find controllers running outside the rudder to extend Kubernetes. Or, if needed, we can write a new controller ourselves. We can run our controller as a set of Pods, or we can run it outside of Kubernetes. The most suitable choice depends on the function of the particular controller.
What's next
- Read about the rudder of Kubernetes
- Explore some basic Kubernetes objects
- Learn more about Kubernetes API for more information
- If you want to write your own controller, please refer to the expansion mode in Kubernetes (please look forward to ~~)
