使用云基础设施技术,你可以在公有云、私有云或者混合云环境中运行 Kubernetes。
Kubernetes 的信条是基于自动化的、API 驱动的基础设施,同时避免组件间紧密耦合。
cloud-controller-manager
组件是基于一种插件机制来构造的,
这种机制使得不同的云厂商都能将其平台与 Kubernetes 集成。
![Kubernetes 组件]
云控制器管理器以一组多副本的进程集合的形式运行在控制面中,通常表现为 Pod
中的容器。每个 cloud-controller-manager
在同一进程中实现多个。
你也可以用 Kubernetes
的形式而不是控制面中的一部分来运行云控制器管理器。
云控制器管理器中的控制器包括:
节点控制器负责在云基础设施中创建了新服务器时为之更新对象。
节点控制器从云提供商获取当前租户中主机的信息。节点控制器执行以下功能:
某些云驱动实现中,这些任务被划分到一个节点控制器和一个节点生命周期控制器中。
Route 控制器负责适当地配置云平台中的路由,以便 Kubernetes 集群中不同节点上的容器之间可以相互通信。
取决于云驱动本身,路由控制器可能也会为 Pod 网络分配 IP 地址块。
与受控的负载均衡器、
IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。
服务控制器与云驱动的 API 交互,以配置负载均衡器和其他基础设施组件。
你所创建的 Service 资源会需要这些组件服务。
本节分别讲述云控制器管理器为了完成自身工作而产生的对各类 API 对象的访问需求。
节点控制器只操作 Node 对象。它需要读取和修改 Node 对象的完全访问权限。
v1/Node
:
路由控制器会监听 Node 对象的创建事件,并据此配置路由设施。
它需要读取 Node 对象的 Get 权限。
v1/Node
:
服务控制器监测 Service 对象的 create、update 和 delete 事件,
并配置对应服务的 Endpoints 对象
(对于 EndpointSlices,kube-controller-manager 按需对其进行管理)。
为了访问 Service 对象,它需要 list 和 watch 访问权限。
为了更新 Service 对象,它需要 patch 和 update 访问权限。
为了能够配置 Service 对应的 Endpoints 资源,
它需要 create、list、get、watch 和 update 等访问权限。
v1/Service
:
在云控制器管理器的实现中,其核心部分需要创建 Event 对象的访问权限,
并创建 ServiceAccount 资源以保证操作安全性的权限。
v1/Event
:
v1/ServiceAccount
:
用于云控制器管理器
的 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
[云控制器管理器的管理]
给出了运行和管理云控制器管理器的指南。
要升级 HA 控制平面以使用云控制器管理器,
请参见[将复制的控制平面迁移以使用云控制器管理器]。
想要了解如何实现自己的云控制器管理器,或者对现有项目进行扩展么?
cloud.go
]CloudProvider
接口),从而使得针对各种云平台的具体实现都可以接入。CloudProvider
接口。