最初创建云控制器管理器(CCM)概念(不要与二进制混淆)是为了允许特定于云的供应商代码和 Kubernetes 核心彼此独立地发展。云控制器管理器与其它主要组件(例如 Kubernetes 控制器管理器,API 服务器和调度程序)一起运行。它也可以作为 Kubernetes 插件启动,在这种情况下,它可以在 Kubernetes 上运行。
云控制器管理器的设计基于插件机制,该机制允许新的云提供商通过使用插件轻松地与 Kubernetes 继承。已经计划在 Kubernetes 上启用新的云提供商,并将云提供商从旧模型迁移到新的 CCM 模型。
该文档概论了云控制器管理器背后的概念,并提供了有关其关联功能的详细信息。
这是没有云控制器管理器的 Kubernetes 集群的架构:
设计
在上图中,Kubernetes 和云提供商通过几个不同的组件集成在一起:
- Kubelet
- Kubernetes 控制器管理器
- Kubernetes API 服务器
CCM 整合了前三个组件中所有与云相关的逻辑,以插件与云的单点集成。CCM 的新体系结构如下所示:
CCM 的组成部分
CCM 拆解了 Kubernetes 控制器管理器(KCM)的某些功能,并将其作为单独的进程运行。具体来说,它打破了 KCM 中依赖于云的那些控制器。KCM 具有以下与云相关的控制器循环:
- 节点控制器;
- 卷控制器;
- 路由控制器;
- 服务控制器。
在 1.9 版本中,CCM 运行前面列表中的以下控制器:
- 节点控制器;
- 路由控制器;
- 服务控制器。
注意:故意将卷控制器选择为不包含在 CCM 中。由于涉及的复杂性以及由于现有的抽象出供应商特定的卷逻辑的努力,因此决定不将卷控制器移至 CCM。
使用 CCM 支持卷的最初计划是使用 Flex(敬请期待~~) 卷来支持可插拔卷。但是,正在计划开展一项名为 CSI(敬请期待~~) 的竞争性工作来替代 Flex。
考虑到这些因素,我们决定在 CSI 准备就绪之前采取中间的止损措施。
CCM 的功能
CCM 从依赖于云提供商的 Kubernetes 组件继承其功能。该部分基于这些组件进行构造。
Kubernetes 控制器管理器
CCM 的大部风能都来自 KCM。如上一部分所述,CCM 运行以下控制循环:
- 节点控制器;
- 路由控制器;
- 服务控制器。
节点控制器
节点控制器负责通过从云提供商获取有关集群中运行的节点的信息来初始化节点。节点控制器执行以下功能:
- 使用云特定的区域/区域标签初始化节点;
- 使用特定于云的实例详细信息初始化节点,例如类型和大小;
- 获取节点的网络地址和主机名;
- 如果节点无响应,请检查云以查看是否已从云中删除该节点。如果该节点已从云中删除,请删除 Kubernetes 节点对象。
路由控制器
路由控制器负责在云中适当非 i配置路由,以便 Kubernetes 集群中不同节点上的容器可以相互通信。路由控制器仅用于 Google Compute Engine 集群。
服务控制器
服务控制器负责侦听服务插件、更新和删除事件。根据 Kubernetes 中服务的当前状态,它配置云负载均衡器(例如 ELB、Google LB 或 Oracle Cloud Infrastructure LB)以反映 Kubernetes 中服务的状态。此外,它确保云负载均衡器的服务后端是最新的。
Kubelet
Node 控制器包含 kubelet 的云相关功能。在引入 CCM 之前。kubelet 负责初始化具有特定于云的详细信息(例如 IP 地址、区域/区域标签和实例类型信息)的节点。CCM 的引入已使该初始化操作从 kubelet 移至 CCM。
在该新模型中,kubelet 初始化没有云特定信息的节点。但是,它会向新插件的节点添加污点,从而使该节点不可调度,直到 CCM 使用特定于云的信息初始化该节点为止。然后,消除该污点。
插件机制
云控制器管理器使用 Go 接口来允许插入来自任何云的实现。具体来说,它使用该处定义的 CloudProvider 接口。
上面突出显示的四个共享控制器的实现以及于共享的 cloudprovider 接口一起提供的一些脚手架将保留在 Kubernetes 核心中。特定于云提供商的实现将在核心之外构建,并实现核心中定义的接口。
有关开发插件的更多信息,请参阅开发云控制器管理器(敬请期待~~)。
该部分将拆解 CCM 执行各个操作所需的各种 API 对象访问。
节点控制器
节点控制器仅适用于 Node 对象。它需要完全访问权限才能获取、列出、创建、更新、修补、观察及删除节点对象。
v1/Node:
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
路由控制器
路由控制器侦听节点对象的插件并适当地配置路由。它需要访问节点对象。
v1/Node:
- Get
服务控制器
服务控制器侦听服务对象的插件、更新和删除时间,然后为那些服务适当地配置端点。
要访问服务,它需要列表和观察权限。要更新服务,它需要修补和更新访问权限。
要为服务设置端点,它需要创建、列出、获取、观察及更新等权限。
v1/Service:
- List
- Get
- Watch
- Patch
- Update
其它
CCM 核心的实现需要创建事件,并且为了确保安全操作,它需要创建 ServiceAccounts。
v1/Event:
- Create
- Patch
- Update
v1/ServiceAccount:
- Create
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 的完整说明。