k8s.martindbrv

cloud-controller-manager

2 min read

The CCM is similar to the kube-controller-manager as it is also a single binary running independent control loops. It’s supposed to run as a part of the k8s control plane to enable the linkage of the underlying cloud provider’s API with the reliant k8s primitives. The list of cloud dependant CM controllers is as follows:

Background

In the past, every major cloud provider’s controller logic was directly implemented in the k8s core CM (in-tree). This made it difficult for cloud providers to iterate quickly, as features in the Kubernetes core must go through the upstream release cycle.

The CCM was introduced to remove this provider-specific logic from the core, allowing faster iteration and avoiding unnecessary code in on-premises clusters.

According to KEP-2392, cloud providers must develop their platform code in outside repositories (out-of-tree) and connect their controller logic through the CCM interfaces, so when they host their own k8s cloud solutions they compile the CCM with their dependencies.

Note

Every cloud provider should fully implement the logic for each relevant controller, though they can still reuse core Kubernetes controller libraries.

Administering a CCM

When you want to use a CCM, additional cluster configuration is necessary. The kube-apiserver, kubelet, and the kube-controller-manager should be started with the --cloud-provider='external'. This way work meant for the CM controllers above is delegated to the controllers in the CCM.

Sources

Graph View

Backlinks