Kubernetes Architecture --- Concepts Underlying the Cloud Controller Manager

最初创建云控制器管理器（CCM）概念（不要与二进制文件混淆）是允许特殊的云的供应商的代码和kubernates核心相互独立发展。云控制器管理器与其他主组件（如Kubernetes controller manager，APIserver和调度程序）一起运行。它也可以作为Kubernetes插件启动，在这种情况下它运行在Kubernetes之上。

云控制器管理器的设计基于一种插件机制，允许新的云提供商通过使用插件轻松地与Kubernetes集成。有计划在Kubernetes上加入新的云提供商，以及将云提供商从旧模型迁移到新的CCM模型。

本文档讨论了云控制器管理器背后的概念，并提供了有关其相关功能的详细信息。

图中是没有云控制器管理器的Kubernetes集群的架构。

在上图中，Kubernetes和云提供商通过几个不同的组件集成：

• Kubelet
• Kubernetes controller manager
• Kubernetes APIserver

CCM整合了前三个组件中的所有依赖于云的逻辑来创建与云的单一集成点。CCM的新架构如下所示：

CCM打破了Kubernetes控制器管理器（KCM）的一些功能并将其作为一个单独的进程来运行。具体来说，它打破了KCM中依赖于云的contoller。KCM具有以下依赖于云的控制器循环：

• Node controller
• Volume controller
• Route controller
• Service controller

在1.9版中，CCM运行上面列表中的以下controller：

• Node controller
• Route controller
• Service controller

此外，它还运行另一个名为PersistentVolumeLabel controller的controller。此controller负责在GCP和AWS云中创建的PersistentVolumes上设置区域和区域标签。

注意：Volume controller 故意被抽出去不作为CCM的一部分了，由于涉及复杂性并且由于现有的努力抽象出供应商特定的卷逻辑，因此决定不将Volume controller 移动到CCM。

使用CCM支持Volume 的最初计划是使用Flex卷来支持可插拔的Volume 。然而，将会有一项有名的CSI竞争者来取代Flex。

考虑到这些动态，我们决定在CSI准备好之前停止gap measure 。

CCM从依赖于云提供商的Kubernetes组件继承其功能

CCM的大多数功能都来自KCM

• Node controller
• Route controller
• Service controller
• PersistentVolumeLabels controller

node controller

nodecontroller负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能：

1. 使用特定于云的区域/区域标签初始化node。
2. 使用特定于云的实例详细信息初始化node，例如，类型和大小。
3. 获取node的网络地址和主机名。
4. 如果node无响应，请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点，则删除Kubernetes Node对象

router controller

Route controller负责适当地配置cloud中的路由，以便Kubernetes集群中不同节点上的容器可以相互通信。Route controller仅适用于Google Compute Engine群集。

service controller

service controller负责监听service 的 创建，更新和删除事件。根据Kubernetes中当前的service 状态，它配置云负载均衡器（如ELB或Google LB）以反映Kubernetes中的service状态。此外，它还确保云负载平衡器的service后端是最新的。

PersistentVolumeLabels controller

PersistentVolumeLabels控制器在创建AWS EBS / GCE PD卷时应用标签。这样就无需用户手动设置这些卷上的标签。

这些标签对于pod的安排至关重要，因为这些volume仅限于在它们所在的区域/区域内工作。使用这些volume的任何Pod都需要在同一区域/区域中进行调度。

PersistentVolumeLabels控制器专门为CCM创建; 也就是说，在创建CCM之前它不存在。这样做是为了将Kubernetes APIserver（它是一个admission controller）中的PV标记逻辑移动到CCM。它不在KCM上运行。

Node controller 包含kubelet的依赖于云的功能。在引入CCM之前，kubelet负责使用特定于云的详细信息（如IP地址，区域/区域标签和实例类型信息）初始化节点。CCM的引入已将此初始化操作从kubelet转移到CCM。

在这个新模型中，kubelet初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加taint ，使节点不可调度，直到CCM使用特定于云的信息初始化节点。然后它消除了这个taint 

PersistentVolumeLabels控制器将Kubernetes APIserver的依赖于云的功能移动到CCM

CCM使用Go接口允许插入任何云的实现。具体来说，它使用此处定义的CloudProvider接口。

上面的四个共享controller的实现，以及一些脚手架以及共享的cloudprovider接口，将保留在Kubernetes核心中。特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。

本节分解了CCM执行其操作时各种API对象所需的访问权限

Node控制器仅适用于Node对象。它需要完全访问获取，列出，创建，更新，修补，监视和删除Node对象。

route controller侦听Node对象创建并适当地配置路由。它需要访问Node对象。

service controller 侦听Service对象创建，更新和删除事件，然后适当地为这些服务配置端点。

要访问服务，它需要list和watch访问权限。要更新服务，它需要patch和update访问权限。

要为服务设置端点，需要访问create，list，get，watch和update。

 PersistentVolumeLabels controller侦听PersistentVolume（PV）创建事件，然后更新它们。该控制器需要访问以获取和更新PV。

CCM核心的实现需要访问以创建事件，并且为了确保安全操作，它需要访问以创建ServiceAccounts。

The RBAC ClusterRole for the CCM looks like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - create
  - get
  - list
  - watch
  - update