Revise cloud-controller-manager documentation
This commit is contained in:
Tim Bannister
parent
355c7f27cb
commit
5db3af4938
|
|
@ -1,114 +1,92 @@
|
|||
---
|
||||
title: Concepts Underlying the Cloud Controller Manager
|
||||
title: Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
The cloud controller manager (CCM) concept (not to be confused with the binary) was originally created to allow cloud specific vendor code and the Kubernetes core to evolve independent of one another. The cloud controller manager runs alongside other master components such as the Kubernetes controller manager, the API server, and scheduler. It can also be started as a Kubernetes addon, in which case it runs on top of Kubernetes.
|
||||
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
|
||||
|
||||
The cloud controller manager's design is based on a plugin mechanism that allows new cloud providers to integrate with Kubernetes easily by using plugins. There are plans in place for on-boarding new cloud providers on Kubernetes and for migrating cloud providers from the old model to the new CCM model.
|
||||
Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds.
|
||||
Kubernetes believes in automated, API-driven infrastructure without tight coupling between
|
||||
components.
|
||||
|
||||
This document discusses the concepts behind the cloud controller manager and gives details about its associated functions.
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="The cloud-controller-manager is">}}
|
||||
|
||||
Here's the architecture of a Kubernetes cluster without the cloud controller manager:
|
||||
|
||||
|
||||
The cloud-controller-manager is structured using a plugin
|
||||
mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Design
|
||||
|
||||
In the preceding diagram, Kubernetes and the cloud provider are integrated through several different components:
|
||||
|
||||
|
||||
* Kubelet
|
||||
* Kubernetes controller manager
|
||||
* Kubernetes API server
|
||||
The cloud controller manager runs in the control plane as a replicated set of processes
|
||||
(usually, these are containers in Pods). Each cloud-controller-manager implements
|
||||
multiple {{< glossary_tooltip text="controllers" term_id="controller" >}} in a single
|
||||
process.
|
||||
|
||||
The CCM consolidates all of the cloud-dependent logic from the preceding three components to create a single point of integration with the cloud. The new architecture with the CCM looks like this:
|
||||
|
||||
|
||||
|
||||
## Components of the CCM
|
||||
|
||||
The CCM breaks away some of the functionality of Kubernetes controller manager (KCM) and runs it as a separate process. Specifically, it breaks away those controllers in the KCM that are cloud dependent. The KCM has the following cloud dependent controller loops:
|
||||
|
||||
* Node controller
|
||||
* Volume controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
|
||||
In version 1.9, the CCM runs the following controllers from the preceding list:
|
||||
|
||||
* Node controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
|
||||
{{< note >}}
|
||||
Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
|
||||
You can also run the cloud controller manager as a Kubernetes
|
||||
{{< glossary_tooltip text="addon" term_id="addons" >}} rather than as part
|
||||
of the control plane.
|
||||
{{< /note >}}
|
||||
|
||||
The original plan to support volumes using CCM was to use [Flex](/docs/concepts/storage/volumes/#flexVolume) volumes to support pluggable volumes. However, a competing effort known as [CSI](/docs/concepts/storage/volumes/#csi) is being planned to replace Flex.
|
||||
## Cloud controller manager functions {#functions-of-the-ccm}
|
||||
|
||||
Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
|
||||
The controllers inside the cloud controller manager include:
|
||||
|
||||
## Functions of the CCM
|
||||
### Node controller
|
||||
|
||||
The CCM inherits its functions from components of Kubernetes that are dependent on a cloud provider. This section is structured based on those components.
|
||||
The node controller is responsible for creating {{< glossary_tooltip text="Node" term_id="node" >}} objects
|
||||
when new servers are created in your cloud infrastructure. The node controller obtains information about the
|
||||
hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
|
||||
|
||||
### 1. Kubernetes controller manager
|
||||
1. Initialize a Node object for each server that the controller discovers through the cloud provider API.
|
||||
2. Annotating and labelling the Node object with cloud-specific information, such as the region the node
|
||||
is deployed into and the resources (CPU, memory, etc) that it has available.
|
||||
3. Obtain the node's hostname and network addresses.
|
||||
4. Verifying the node's health. In case a node becomes unresponsive, this controller checks with
|
||||
your cloud provider's API to see if the server has been deactivated / deleted / terminated.
|
||||
If the node has been deleted from the cloud, the controller deletes the Node object from your Kubernetes
|
||||
cluster.
|
||||
|
||||
The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:
|
||||
Some cloud provider implementations split this into a node controller and a separate node
|
||||
lifecycle controller.
|
||||
|
||||
* Node controller
|
||||
* Route controller
|
||||
* Service controller
|
||||
### Route controller
|
||||
|
||||
#### Node controller
|
||||
The route controller is responsible for configuring routes in the cloud
|
||||
appropriately so that containers on different nodes in your Kubernetes
|
||||
cluster can communicate with each other.
|
||||
|
||||
The Node controller is responsible for initializing a node by obtaining information about the nodes running in the cluster from the cloud provider. The node controller performs the following functions:
|
||||
Depending on the cloud provider, the route controller might also allocate blocks
|
||||
of IP addresses for the Pod network.
|
||||
|
||||
1. Initialize a node with cloud specific zone/region labels.
|
||||
2. Initialize a node with cloud specific instance details, for example, type and size.
|
||||
3. Obtain the node's network addresses and hostname.
|
||||
4. In case a node becomes unresponsive, check the cloud to see if the node has been deleted from the cloud.
|
||||
If the node has been deleted from the cloud, delete the Kubernetes Node object.
|
||||
### Service controller
|
||||
|
||||
#### Route controller
|
||||
|
||||
The Route controller is responsible for configuring routes in the cloud appropriately so that containers on different nodes in the Kubernetes cluster can communicate with each other. The route controller is only applicable for Google Compute Engine clusters.
|
||||
|
||||
#### Service Controller
|
||||
|
||||
The Service controller is responsible for listening to service create, update, and delete events. Based on the current state of the services in Kubernetes, it configures cloud load balancers (such as ELB , Google LB, or Oracle Cloud Infrastructure LB) to reflect the state of the services in Kubernetes. Additionally, it ensures that service backends for cloud load balancers are up to date.
|
||||
|
||||
### 2. Kubelet
|
||||
|
||||
The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.
|
||||
|
||||
In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.
|
||||
|
||||
## Plugin mechanism
|
||||
|
||||
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
|
||||
|
||||
The implementation of the four shared controllers highlighted above, and some scaffolding along with the shared cloudprovider interface, will stay in the Kubernetes core. Implementations specific to cloud providers will be built outside of the core and implement interfaces defined in the core.
|
||||
|
||||
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
{{< glossary_tooltip text="Services" term_id="service" >}} integrate with cloud
|
||||
infrastructure components such as managed load balancers, IP addresses, network
|
||||
packet filtering, and target health checking. The service controller interacts with your
|
||||
cloud provider's APIs to set up load balancers and other infrastructure components
|
||||
when you declare a Service resource that requires them.
|
||||
|
||||
## Authorization
|
||||
|
||||
This section breaks down the access required on various API objects by the CCM to perform its operations.
|
||||
This section breaks down the access that the cloud controller managers requires
|
||||
on various API objects, in order to perform its operations.
|
||||
|
||||
### Node Controller
|
||||
### Node controller {#authorization-node-controller}
|
||||
|
||||
The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.
|
||||
The Node controller only works with Node objects. It requires full access
|
||||
to read and modify Node objects.
|
||||
|
||||
v1/Node:
|
||||
`v1/Node`:
|
||||
|
||||
- Get
|
||||
- List
|
||||
|
|
@ -118,23 +96,24 @@ v1/Node:
|
|||
- Watch
|
||||
- Delete
|
||||
|
||||
### Route controller
|
||||
### Route controller {#authorization-route-controller}
|
||||
|
||||
The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
|
||||
The route controller listens to Node object creation and configures
|
||||
routes appropriately. It requires Get access to Node objects.
|
||||
|
||||
v1/Node:
|
||||
`v1/Node`:
|
||||
|
||||
- Get
|
||||
|
||||
### Service controller
|
||||
### Service controller {#authorization-service-controller}
|
||||
|
||||
The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
|
||||
The service controller listens to Service object Create, Update and Delete events and then configures Endpoints for those Services appropriately.
|
||||
|
||||
To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
|
||||
To access Services, it requires List, and Watch access. To update Services, it requires Patch and Update access.
|
||||
|
||||
To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
|
||||
To set up Endpoints resources for the Services, it requires access to Create, List, Get, Watch, and Update.
|
||||
|
||||
v1/Service:
|
||||
`v1/Service`:
|
||||
|
||||
- List
|
||||
- Get
|
||||
|
|
@ -142,21 +121,22 @@ v1/Service:
|
|||
- Patch
|
||||
- Update
|
||||
|
||||
### Others
|
||||
### Others {#authorization-miscellaneous}
|
||||
|
||||
The implementation of the core of CCM requires access to create events, and to ensure secure operation, it requires access to create ServiceAccounts.
|
||||
The implementation of the core of the cloud controller manager requires access to create Event objects, and to ensure secure operation, it requires access to create ServiceAccounts.
|
||||
|
||||
v1/Event:
|
||||
`v1/Event`:
|
||||
|
||||
- Create
|
||||
- Patch
|
||||
- Update
|
||||
|
||||
v1/ServiceAccount:
|
||||
`v1/ServiceAccount`:
|
||||
|
||||
- Create
|
||||
|
||||
The RBAC ClusterRole for the CCM looks like this:
|
||||
The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole for the cloud
|
||||
controller manager looks like:
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
|
|
@ -220,27 +200,16 @@ rules:
|
|||
- update
|
||||
```
|
||||
|
||||
## Vendor Implementations
|
||||
|
||||
The following cloud providers have implemented CCMs:
|
||||
|
||||
* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)
|
||||
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
|
||||
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
|
||||
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
|
||||
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
|
||||
* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager)
|
||||
* [HUAWEI CLOUD](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)
|
||||
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
|
||||
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
|
||||
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)
|
||||
|
||||
|
||||
## Cluster Administration
|
||||
|
||||
Complete instructions for configuring and running the CCM are provided
|
||||
[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
|
||||
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
|
||||
has instructions on running and managing the cloud controller manager.
|
||||
|
||||
Want to know how to implement your own cloud controller manager, or extend an existing project?
|
||||
|
||||
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
|
||||
|
||||
The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
|
||||
|
||||
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -50,26 +50,29 @@ the same machine, and do not run user containers on this machine. See
|
|||
|
||||
These controllers include:
|
||||
|
||||
* Node Controller: Responsible for noticing and responding when nodes go down.
|
||||
* Replication Controller: Responsible for maintaining the correct number of pods for every replication
|
||||
* Node controller: Responsible for noticing and responding when nodes go down.
|
||||
* Replication controller: Responsible for maintaining the correct number of pods for every replication
|
||||
controller object in the system.
|
||||
* Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
|
||||
* Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
|
||||
* Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
|
||||
* Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
|
||||
|
||||
### cloud-controller-manager
|
||||
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6.
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
|
||||
|
||||
cloud-controller-manager runs cloud-provider-specific controller loops only. You must disable these controller loops in the kube-controller-manager. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager.
|
||||
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
|
||||
If you are running Kubernetes on your own premises, or in a learning environment inside your
|
||||
own PC, the cluster does not have a cloud controller manager.
|
||||
|
||||
cloud-controller-manager allows the cloud vendor's code and the Kubernetes code to evolve independently of each other. In prior releases, the core Kubernetes code was dependent upon cloud-provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to cloud-controller-manager while running Kubernetes.
|
||||
As with the kube-controller-manager, the cloud-controller-manager combines several logically
|
||||
independent control loops into a single binary that you run as a single process. You can
|
||||
scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
|
||||
|
||||
The following controllers have cloud provider dependencies:
|
||||
The following controllers can have cloud provider dependencies:
|
||||
|
||||
* Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
|
||||
* Route Controller: For setting up routes in the underlying cloud infrastructure
|
||||
* Service Controller: For creating, updating and deleting cloud provider load balancers
|
||||
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
|
||||
* Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
|
||||
* Route controller: For setting up routes in the underlying cloud infrastructure
|
||||
* Service controller: For creating, updating and deleting cloud provider load balancers
|
||||
|
||||
## Node Components
|
||||
|
||||
|
|
|
|||
|
|
@ -544,7 +544,7 @@ region and/or zone.
|
|||
If the admission controller doesn't support automatic labelling your PersistentVolumes, you
|
||||
may need to add the labels manually to prevent pods from mounting volumes from
|
||||
a different zone. PersistentVolumeLabel is DEPRECATED and labeling persistent volumes has been taken over by
|
||||
[cloud controller manager](/docs/tasks/administer-cluster/running-cloud-controller/).
|
||||
the {{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}.
|
||||
Starting from 1.11, this admission controller is disabled by default.
|
||||
|
||||
### PodNodeSelector {#podnodeselector}
|
||||
|
|
|
|||
|
|
@ -2,18 +2,23 @@
|
|||
title: Cloud Controller Manager
|
||||
id: cloud-controller-manager
|
||||
date: 2018-04-12
|
||||
full_link: /docs/tasks/administer-cluster/running-cloud-controller/
|
||||
full_link: /docs/concepts/architecture/cloud-controller/
|
||||
short_description: >
|
||||
Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic.
|
||||
|
||||
Control plane component that integrates Kubernetes with third-party cloud providers.
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- architecture
|
||||
- operation
|
||||
---
|
||||
Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic.
|
||||
A Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} component
|
||||
that embeds cloud-specific control logic. The cloud controller manager lets you link your
|
||||
cluster into your cloud provider's API, and separates out the components that interact
|
||||
with that cloud platform from components that just interact with your cluster.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
By decoupling the interoperability logic between Kubernetes and the underlying cloud
|
||||
infrastructure, the cloud-controller-manager component enables cloud providers to release
|
||||
features at a different pace compared to the main Kubernetes project.
|
||||
|
||||
Originally part of the kube-controller-manager, the cloud-controller-manager is responsible to decoupling the interoperability logic between Kubernetes and the underlying cloud infrastructure, enabling cloud providers to release features at a different pace compared to the main project.
|
||||
|
|
|
|||
|
|
@ -10,35 +10,35 @@ content_template: templates/concept
|
|||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.11" state="beta" >}}
|
||||
In upcoming releases, Cloud Controller Manager will
|
||||
be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
|
||||
can develop their features independently from the core Kubernetes release cycles.
|
||||
|
||||
{{< feature-state for_k8s_version="v1.8" state="alpha" >}}
|
||||
|
||||
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) is satisfied.
|
||||
|
||||
To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/6371aabbd7a7726f4b358444cca40def793950c2/plugins.go#L55-L63) where a global variable of available cloud providers is updated.
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="The cloud-controller-manager is">}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Background
|
||||
|
||||
Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
|
||||
|
||||
The Kubernetes project provides skeleton cloud-controller-manager code with Go interfaces to allow you (or your cloud provider) to plug in your own implementations. This means that a cloud provider can implement a cloud-controller-manager by importing packages from Kubernetes core; each cloudprovider will register their own code by calling `cloudprovider.RegisterCloudProvider` to update a global variable of available cloud providers.
|
||||
|
||||
## Developing
|
||||
|
||||
### Out of Tree
|
||||
### Out of tree
|
||||
|
||||
To build an out-of-tree cloud-controller-manager for your cloud, follow these steps:
|
||||
To build an out-of-tree cloud-controller-manager for your cloud:
|
||||
|
||||
1. Create a go package with an implementation that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go).
|
||||
2. Use [main.go in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your main.go. As mentioned above, the only difference should be the cloud package that will be imported.
|
||||
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go).
|
||||
2. Use [`main.go` in cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) from Kubernetes core as a template for your `main.go`. As mentioned above, the only difference should be the cloud package that will be imported.
|
||||
3. Import your cloud package in `main.go`, ensure your package has an `init` block to run [`cloudprovider.RegisterCloudProvider`](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go).
|
||||
|
||||
Using existing out-of-tree cloud providers as an example may be helpful. You can find the list [here](/docs/tasks/administer-cluster/running-cloud-controller.md#examples).
|
||||
Many cloud providers publish their controller manager code as open source. If you are creating
|
||||
a new cloud-controller-manager from scratch, you could take an existing out-of-tree cloud
|
||||
controller manager as your starting point.
|
||||
|
||||
### In Tree
|
||||
### In tree
|
||||
|
||||
For in-tree cloud providers, you can run the in-tree cloud controller manager as a [Daemonset](/examples/admin/cloud/ccm-example.yaml) in your cluster. See the [running cloud controller manager docs](/docs/tasks/administer-cluster/running-cloud-controller.md) for more details.
|
||||
For in-tree cloud providers, you can run the in-tree cloud controller manager as a {{< glossary_tooltip term_id="daemonset" >}} in your cluster. See [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) for more details.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -3,17 +3,17 @@ reviewers:
|
|||
- luxas
|
||||
- thockin
|
||||
- wlan0
|
||||
title: Kubernetes Cloud Controller Manager
|
||||
title: Cloud Controller Manager Administration
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
|
||||
|
||||
Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
|
||||
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. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
|
||||
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.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
|
@ -43,11 +43,11 @@ Keep in mind that setting up your cluster to use cloud controller manager will c
|
|||
* 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.
|
||||
|
||||
|
||||
As of v1.8, cloud controller manager can implement:
|
||||
The cloud controller manager can implement:
|
||||
|
||||
* node controller - responsible for updating kubernetes nodes using cloud APIs and deleting kubernetes nodes that were deleted on your cloud.
|
||||
* service controller - responsible for loadbalancers on your cloud against services of type LoadBalancer.
|
||||
* route controller - responsible for setting up network routes on your cloud
|
||||
* Node controller - responsible for updating kubernetes nodes using cloud APIs and deleting kubernetes nodes that were deleted on your cloud.
|
||||
* Service controller - responsible for loadbalancers on your cloud against services of type LoadBalancer.
|
||||
* Route controller - responsible for setting up network routes on your cloud
|
||||
* any other features you would like to implement if you are running an out-of-tree provider.
|
||||
|
||||
|
||||
|
|
@ -55,14 +55,9 @@ As of v1.8, cloud controller manager can implement:
|
|||
|
||||
If you are using a cloud that is currently supported in Kubernetes core and would like to adopt cloud controller manager, see the [cloud controller manager in kubernetes core](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager).
|
||||
|
||||
For cloud controller managers not in Kubernetes core, you can find the respective projects in repos maintained by cloud vendors or sig leads.
|
||||
For cloud controller managers not in Kubernetes core, you can find the respective projects in repositories maintained by cloud vendors or by SIGs.
|
||||
|
||||
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
|
||||
* [keepalived](https://github.com/munnerz/keepalived-cloud-provider)
|
||||
* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager)
|
||||
* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
|
||||
|
||||
For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
|
||||
For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a DaemonSet in your cluster, use the following as a guideline:
|
||||
|
||||
{{< codenew file="admin/cloud/ccm-example.yaml" >}}
|
||||
|
||||
|
|
@ -77,18 +72,19 @@ Cloud controller manager does not implement any of the volume controllers found
|
|||
|
||||
### Scalability
|
||||
|
||||
In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very large clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.
|
||||
The cloud-controller-manager queries your cloud provider's APIs to retrieve information for all nodes. For very large clusters, consider possible bottlenecks such as resource requirements and API rate limiting.
|
||||
|
||||
### Chicken and Egg
|
||||
|
||||
The goal of the cloud controller manager project is to decouple development of cloud features from the core Kubernetes project. Unfortunately, many aspects of the Kubernetes project has assumptions that cloud provider features are tightly integrated into the project. As a result, adopting this new architecture can create several situations where a request is being made for information from a cloud provider, but the cloud controller manager may not be able to return that information without the original request being complete.
|
||||
|
||||
A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
|
||||
A good example of this is the TLS bootstrapping feature in the Kubelet. TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
|
||||
|
||||
As this initiative evolves, changes will be made to address these issues in upcoming releases.
|
||||
|
||||
## Developing your own Cloud Controller Manager
|
||||
{{% /capture %}}
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
To build and develop your own cloud controller manager, read the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
|
||||
To build and develop your own cloud controller manager, read [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
Loading…
Reference in New Issue