You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: Concepts Underlying the Cloud Controller Manager
2
+
title: Cloud Controller Manager
3
3
content_template: templates/concept
4
4
weight: 40
5
5
---
6
6
7
7
{{% capture overview %}}
8
8
9
-
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.
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.
11
+
Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds.
12
+
Kubernetes believes in automated, API-driven infrastructure without tight coupling between
13
+
components.
12
14
13
-
This document discusses the concepts behind the cloudcontrollermanager and gives details about its associated functions.
The cloud-controller-manager is structured using a plugin
18
+
mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
18
19
19
20
{{% /capture %}}
20
21
21
-
22
22
{{% capture body %}}
23
23
24
24
## Design
25
25
26
-
In the preceding diagram, Kubernetes and the cloud provider are integrated through several different components:
27
-
28
-
* Kubelet
29
-
* Kubernetes controller manager
30
-
* Kubernetes API server
31
-
32
-
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:
33
-
34
-
35
-
36
-
## Components of the CCM
37
-
38
-
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:
The cloud controller manager runs in the control plane as a replicated set of processes
29
+
(usually, these are containers in Pods). Each cloud-controller-manager implements
30
+
multiple {{< glossary_tooltip text="controllers" term_id="controller" >}} in a single
31
+
process.
44
32
45
-
In version 1.9, the CCM runs the following controllers from the preceding list:
46
-
47
-
* Node controller
48
-
* Route controller
49
-
* Service controller
50
33
51
34
{{< note >}}
52
-
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.
35
+
You can also run the cloud controller manager as a Kubernetes
36
+
{{< glossary_tooltip text="addon" term_id="addons" >}} rather than as part
37
+
of the control plane.
53
38
{{< /note >}}
54
39
55
-
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.
56
-
57
-
Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
58
-
59
-
## Functions of the CCM
60
-
61
-
The CCM inherits its functions from components of Kubernetes that are dependent on a cloud provider. This section is structured based on those components.
62
-
63
-
### 1. Kubernetes controller manager
64
-
65
-
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:
The controllers inside the cloud controller manager include:
72
43
73
-
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:
44
+
###Node controller
74
45
75
-
1. Initialize a node with cloud specific zone/region labels.
76
-
2. Initialize a node with cloud specific instance details, for example, type and size.
77
-
3. Obtain the node's network addresses and hostname.
78
-
4. In case a node becomes unresponsive, check the cloud to see if the node has been deleted from the cloud.
79
-
If the node has been deleted from the cloud, delete the Kubernetes Node object.
46
+
The node controller is responsible for creating {{< glossary_tooltip text="Node" term_id="node" >}} objects
47
+
when new servers are created in your cloud infrastructure. The node controller obtains information about the
48
+
hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
80
49
81
-
#### Route controller
50
+
1. Initialize a Node object for each server that the controller discovers through the cloud provider API.
51
+
2. Annotating and labelling the Node object with cloud-specific information, such as the region the node
52
+
is deployed into and the resources (CPU, memory, etc) that it has available.
53
+
3. Obtain the node's hostname and network addresses.
54
+
4. Verifying the node's health. In case a node becomes unresponsive, this controller checks with
55
+
your cloud provider's API to see if the server has been deactivated / deleted / terminated.
56
+
If the node has been deleted from the cloud, the controller deletes the Node object from your Kubernetes
57
+
cluster.
82
58
83
-
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.
59
+
Some cloud provider implementations split this into a node controller and a separate node
60
+
lifecycle controller.
84
61
85
-
#### Service Controller
86
-
87
-
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.
88
-
89
-
### 2. Kubelet
90
-
91
-
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.
92
-
93
-
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.
62
+
### Route controller
94
63
95
-
## Plugin mechanism
64
+
The route controller is responsible for configuring routes in the cloud
65
+
appropriately so that containers on different nodes in your Kubernetes
66
+
cluster can communicate with each other.
96
67
97
-
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).
68
+
Depending on the cloud provider, the route controller might also allocate blocks
69
+
of IP addresses for the Pod network.
98
70
99
-
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.
71
+
### Service controller
100
72
101
-
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
73
+
{{< glossary_tooltip text="Services" term_id="service" >}} integrate with cloud
74
+
infrastructure components such as managed load balancers, IP addresses, network
75
+
packet filtering, and target health checking. The service controller interacts with your
76
+
cloud provider's APIs to set up load balancers and other infrastructure components
77
+
when you declare a Service resource that requires them.
102
78
103
79
## Authorization
104
80
105
-
This section breaks down the access required on various API objects by the CCM to perform its operations.
81
+
This section breaks down the access that the cloud controller managers requires
82
+
on various API objects, in order to perform its operations.
The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
101
+
The route controller listens to Node object creation and configures
102
+
routes appropriately. It requires Get access to Node objects.
124
103
125
-
v1/Node:
104
+
`v1/Node`:
126
105
127
106
- Get
128
107
129
-
### Service controller
108
+
### Service controller {#authorization-service-controller}
130
109
131
-
The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
110
+
The service controller listens to Service object Create, Update and Delete events and then configures Endpoints for those Services appropriately.
132
111
133
-
To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
112
+
To access Services, it requires List, and Watch access. To update Services, it requires Patch and Update access.
134
113
135
-
To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
114
+
To set up Endpoints resources for the Services, it requires access to Create, List, Get, Watch, and Update.
136
115
137
-
v1/Service:
116
+
`v1/Service`:
138
117
139
118
- List
140
119
- Get
141
120
- Watch
142
121
- Patch
143
122
- Update
144
123
145
-
### Others
124
+
### Others {#authorization-miscellaneous}
146
125
147
-
The implementation of the core of CCM requires access to create events, and to ensure secure operation, it requires access to create ServiceAccounts.
126
+
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.
148
127
149
-
v1/Event:
128
+
`v1/Event`:
150
129
151
130
- Create
152
131
- Patch
153
132
- Update
154
133
155
-
v1/ServiceAccount:
134
+
`v1/ServiceAccount`:
156
135
157
136
- Create
158
137
159
-
The RBAC ClusterRole for the CCM looks like this:
138
+
The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole for the cloud
139
+
controller manager looks like:
160
140
161
141
```yaml
162
142
apiVersion: rbac.authorization.k8s.io/v1
@@ -220,27 +200,16 @@ rules:
220
200
- update
221
201
```
222
202
223
-
## Vendor Implementations
224
-
225
-
The following cloud providers have implemented CCMs:
has instructions on running and managing the cloud controller manager.
239
207
208
+
Want to know how to implement your own cloud controller manager, or extend an existing project?
240
209
241
-
## Cluster Administration
210
+
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).
242
211
243
-
Complete instructions for configuring and running the CCM are provided
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.
245
213
214
+
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
Copy file name to clipboardExpand all lines: content/en/docs/concepts/overview/components.md
+15-12Lines changed: 15 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,26 +50,29 @@ the same machine, and do not run user containers on this machine. See
50
50
51
51
These controllers include:
52
52
53
-
* Node Controller: Responsible for noticing and responding when nodes go down.
54
-
* Replication Controller: Responsible for maintaining the correct number of pods for every replication
53
+
* Node controller: Responsible for noticing and responding when nodes go down.
54
+
* Replication controller: Responsible for maintaining the correct number of pods for every replication
55
55
controller object in the system.
56
-
* Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
57
-
* Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
56
+
* Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
57
+
* Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
58
58
59
59
### cloud-controller-manager
60
60
61
-
[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.
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.
63
+
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
64
+
If you are running Kubernetes on your own premises, or in a learning environment inside your
65
+
own PC, the cluster does not have a cloud controller manager.
64
66
65
-
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.
67
+
As with the kube-controller-manager, the cloud-controller-manager combines several logically
68
+
independent control loops into a single binary that you run as a single process. You can
69
+
scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
66
70
67
-
The following controllers have cloud provider dependencies:
71
+
The following controllers can have cloud provider dependencies:
68
72
69
-
* Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
70
-
* Route Controller: For setting up routes in the underlying cloud infrastructure
71
-
* Service Controller: For creating, updating and deleting cloud provider load balancers
72
-
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider to orchestrate volumes
73
+
* Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
74
+
* Route controller: For setting up routes in the underlying cloud infrastructure
75
+
* Service controller: For creating, updating and deleting cloud provider load balancers
Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic.
8
-
7
+
Control plane component that integrates Kubernetes with third-party cloud providers.
9
8
aka:
10
9
tags:
11
10
- core-object
12
11
- architecture
13
12
- operation
14
13
---
15
-
Cloud Controller Manager is a Kubernetes component that embeds cloud-specific control logic.
14
+
A Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} component
15
+
that embeds cloud-specific control logic. The cloud controller manager lets you link your
16
+
cluster into your cloud provider's API, and separates out the components that interact
17
+
with that cloud platform from components that just interact with your cluster.
18
+
19
+
<!--more-->
16
20
17
-
<!--more-->
21
+
By decoupling the interoperability logic between Kubernetes and the underlying cloud
22
+
infrastructure, the cloud-controller-manager component enables cloud providers to release
23
+
features at a different pace compared to the main Kubernetes project.
18
24
19
-
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.
0 commit comments