The kubernetes documentation page: Kubernetes Components - Kubernetes states that both these control plane components; “kube-controller-manager” and “cloud-controller-manager” run the Node-controller.
How is it that both these components run the same controller process. Are there two instances of the process running at all times as a part of the two components?
Cloud-controller-manager has its own specifications like cloud services, load balancing and routing. If you are connecting your cluster with any Cloud providers. It will create a cloud controller to manage activities like AKS, EKS, GKE has their own cloud controller manager.
I think they have different responsibilities.
cloud-controller-manager is specific to the underlying cloud/iaas and can update the node status based on status from the cloud/iaas.
kube-controller-manager is cloud/iaas agnostic and contains Kubernetes specific logic related to nodes like what to do when a node is considered down.
Kind regards,
Stephen
@tej-singh-rana @stephendotcarter, Thanks for your reply. I agree that both the cloud-controller-manager and kube-controller-manager have their own use cases. One being cloud specific and another being cloud provider agnostic.
However, my question is more related to the “node-controller” which the documentation says runs as a part of the combined binary service in both the cloud and kube controller managers.
Given that a controller (in this case node-controller), is a single process or a control loop, how does it have different implementations when it comes to running with cloud-controller or kube-controller manager. Also the documentation specifically mentions that the role of the node-controller is really the same in both cases as to detect the underlying node status (if it is down).
I was trying to describe this in my last comment but wasn’t clear enough.
The node-controller isn’t a single process.
The node-controller code inside kube-controller-manager monitors the API server and if nodes are flagged as down it will take some action for example to get pods rescheduled.
But kube-controller-manager has no concept of AWS, GCP, vSphere, etc… it just interacts with the API server and reads whatever status is stored there.
The node-controller code cloud-controller-manager implements the logic to query the underlying cloud infrastructure to check the health of nodes and update them in the API server. But itself is not really taking action to reschedule pods, it’s only updating the status.
@stephendotcarter I think I now have a better understanding of this concept.
Just to verify, can we say that the node-controller running on kube-controller-manager actually uses the node status in kube-api-server which is is actually made available by the node-controller running on the cloud-controller-manager, which actually checks the status of physical (or virtual machines) in the cloud?
Thank you 