Cloud Controller Manager Administration

--- reviewers: - luxas - thockin - wlan0 title: Cloud Controller Manager Administration content_type: concept weight: 110 ---  {{< feature-state state="beta" for_k8s_version="v1.11" >}} Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}` binary allows cloud vendors to evolve independently from the core Kubernetes code. The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.  ## Administration ### Requirements Every cloud has their own set of requirements for running their own cloud provider integration, it should not be too different from the requirements when running `kube-controller-manager`. As a general rule of thumb you'll need: * cloud authentication/authorization: your cloud may require a token or IAM rules to allow access to their APIs * kubernetes authentication/authorization: cloud-controller-manager may need RBAC rules set to speak to the kubernetes apiserver * high availability: like kube-controller-manager, you may want a high available setup for cloud controller manager using leader election (on by default). ### Running cloud-controller-manager Successfully running cloud-controller-manager requires some changes to your cluster configuration. * `kubelet`, `kube-apiserver`, and `kube-controller-manager` must be set according to the user's usage of external CCM. If the user has an external CCM (not the internal cloud controller loops in the Kubernetes Controller Manager), then `--cloud-provider=external` must be specified. Otherwise, it should not be specified. Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways: * Components that specify `--cloud-provider=external` will add a taint `node.cloudprovider.kubernetes.io/uninitialized` with an effect `NoSchedule` during initialization. This marks the node as needing a second initialization from an external controller before it can be scheduled work. Note that in the event that cloud controller manager is not available, new nodes in the cluster will be left unschedulable. The taint is important since the scheduler may require cloud specific information about nodes such as their region or type (high cpu, gpu, high memory, spot instance, etc). * cloud information about nodes in the cluster will no longer be retrieved using local metadata, but instead all API calls to retrieve node information will go through cloud controller manager. This may mean you can restrict access to your cloud API on the kubelets for better security. For larger clusters you may want to consider if cloud controller manager will hit rate limits since it is now responsible for almost all API calls to your cloud from within the cluster.

This document describes the administration of the Cloud Controller Manager (CCM), which abstracts provider-specific code from the core Kubernetes project. It details the requirements for running CCM, including cloud and Kubernetes authentication/authorization and high availability. It also outlines the necessary cluster configuration changes, such as setting flags for kubelet, kube-apiserver, and kube-controller-manager, and the implications of using CCM, including node taints and API call routing.