From Confused to Proficient: Methods to Understand Controllers of Kubernetes Clusters
By Sheng Dong, Alibaba Cloud After-Sales Technical Expert
When trying to understand the working principle of Kubernetes clusters, we find that it is difficult to understand the working principle of controllers because there are too many controllers with different implementations and some of them use obscure mechanisms for implementation. However, controllers cannot be ignored because they are “cluster brains.”
In this article, we analyze the design process of a simple refrigerator to deeply understand the development, functions, and implementation of cluster controllers.
The following figure shows the core components of a Kubernetes cluster, including etcd (database), scheduler, API server (cluster portal), controller, kube-proxy (proxy server), and kubelet that manages business containers. These components are logically divided into three parts, the core component etcd, the API server that operates etcd, and other components.
The other components are classified into one part because they can be used as cluster controllers.
Let’s discuss the working principle of cluster controllers in the following sections.
Although the controller of a Kubernetes cluster is a complex component, controllers are quite commonly used in most every day things. For example, the operation of washing machines, refrigerators, and air conditioners depends on controllers.
This section, talks about the design process of an easy refrigerator to help you understand the working principle of a Kubernetes cluster controller.
Simple Refrigerator Principle
Refrigerator components include the cabinet, refrigeration system, lighting system, thermostat, and door. A refrigerator has only two functions. When you open the refrigerator door of the cold storage space, the light inside turns on. When you press the thermostat, the refrigeration system adjusts the temperature according to the temperature settings.
Let’s abstract a refrigerator into two parts: the central portal, and all the components of the refrigerator. The central portal is used to operate the refrigerator. This portal provides the interfaces to open and close doors and adjust the temperature using the thermostat.
On executing the two interfaces, the portal adjusts the refrigerator door and thermostat status.
Controllers are developed for the preceding issue. Controllers enable user operations to guide the correct status of each refrigerator component. When you open the door, a controller observes the door change and turns on the light in the refrigerator.
When you press the thermostat, a controller observes the set temperature and manages the refrigeration system to adjust the temperature in the refrigerator.
A refrigerator has a lighting system and a refrigeration system. One controller for each component is more appropriate than a single controller for two components. Additionally, a controller manager maintains all the controllers to ensure that they work properly.
The functions of the controller and controller manager seem to be great. However, as the refrigerator functions increase, many new controllers are added. The new controllers monitor the status changes of the components they care about at all times through the refrigerator portal. For example, the lighting system controller needs to monitor the refrigerator door status at all times. Communication between many controllers and the portal increases the pressure on the portal.
In this case, a new module, SharedInformer monitors the status changes of the refrigerator components. As the controller proxy, SharedInformer monitors the status changes of the refrigerator components for controllers and notifies the corresponding controllers of the status changes of different components according to the controllers’ preferences. Using such optimization, SharedInformer relieves much of the pressure on the refrigerator portal.
If SharedInformer communicates with the refrigerator portal through HTTP, chunked transfer encoding of HTTP is a good choice for ListWatcher. A controller sends a query request to the refrigerator portal through ListWatcher. When the status of any refrigerator component changes, the portal sends a chunked HTTP response to the controller. The controller thinks that response data sending is not complete and continues to wait.
The evolution of a simple refrigerator explains the significance, role, and implementation of controllers. Let’s go back to Kubernetes clusters. Kubernetes clusters implement a large number of controllers. In the foreseeable future, new controllers with new functions will constantly emerge and some old controllers will phase out.
Currently, common controllers include pod controllers, deployment controllers, service controllers, and ReplicaSet controllers. While kube-controller-manager implements and manages some of the controllers, Cloud Controller Manager (CCM) implements route controllers and service controllers.
CCM appears because the implementation of some controllers in different cloud environments varies greatly with cloud vendors and cloud environments. Cloud vendors implements these controllers with CCM.
Let’s consider the route controller and service controller implemented by CCM of Alibaba Cloud Kubernetes clusters to describe how Kubernetes controllers work.
First, a user sends a request to the API server to create a LoadBalancer service. The API server receives the request and writes details of this service to the etcd database. The service controller observes the change and understands the LoadBalancer service. In addition to the service records stored in etcd, Server Load Balancer (SLB) is needed as the service portal and several endpoints are needed as service back ends.
Therefore, the service controller sends a request to the API server and the cloud API of SLB to create off-premises SLB resources and endpoints in clusters.
In the preceeding section about cluster networks, when a node is added to a Kubernetes cluster, an additional route is required in the Virtual Private Cloud (VPC) routing table to create the main channel between the new node and the pod network. This is done by the route controller. The process is similar to that of the service controller.
Basically, controllers of Kubernetes clusters play the role of the brains of a cluster. With controllers, Kubernetes clusters get rid of both mechanical and passive power and become an automatic, intelligent, and useful system.