Try Our Interactive Tutorials

概念

Kubernetes v1.12 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击 最新版本。

Edit This Page

云控制器管理器的基础概念

云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。

云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。

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

这是没有云控制器管理器的 Kubernetes 集群的架构：

没有云控制器管理器的 Kubernetes 架构

设计

在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是：

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

含有云控制器管理器的 Kubernetes 架构

CCM 的组成部分

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

在 1.9 版本中，CCM 运行前述列表中的以下控制器：

此外，它还运行另一个名为 PersistentVolumeLabels Controller 的控制器，这个控制器负责在 GCP 和 AWS 云中创建的 PersistentVolumes 的域（zone）和区（region）标签进行设置。

Note:

注意卷控制器不属于 CCM，由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。

使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷，但是现在正在计划一项名为 CSI 的项目以取代 Flex。

考虑到这些正在进行中的变化，在 CSI 准备就绪之前，我们决定停止当前的工作。

CCM 的功能

CCM 从依赖于云提供商的 Kubernetes 组件继承其功能，本节基于这些组件组织。

1. Kubernetes 控制器管理器

CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。

节点控制器

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

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

路由控制器

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

服务控制器

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

PersistentVolumeLabels 控制器

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

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

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

2. Kubelet

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

在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。

3. Kubernetes API 服务器

PersistentVolumeLabels 控制器将 Kubernetes API 服务器的依赖于云的功能移至 CCM，如前面部分所述。

插件机制

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

上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的 cloudprovider 接口，将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。

有关开发插件的更多信息，请参阅开发云控制器管理器。

授权

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

节点控制器

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

v1/Node:

路由控制器

路由控制器侦听 Node 对象创建并适当地配置路由，它需要访问 Node 对象。

v1/Node:

服务控制器

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

要访问服务，它需要列表和监视访问权限。要更新服务，它需要修补和更新访问权限。

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

v1/Service:

PersistentVolumeLabels 控制器

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

v1/PersistentVolume:

其它

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

v1/Event:

v1/ServiceAccount:

针对 CCM 的 RBAC ClusterRole 看起来像这样：

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

供应商实施

以下云服务提供商已实现了 CCM：

群集管理

这里提供了有关配置和运行 CCM 的完整说明。

反馈