云控制器管理器

云控制器管理器（Cloud Controller Manager，简称 CCM）是一个 Kubernetes 控制平面组件，嵌入了特定于云平台的控制逻辑。它允许将集群连接到云提供商的 API 之上，并将与云平台交互的组件同与集群交互的组件分离开来。

特性状态： Beta since Kubernetes v1.11

通过分离 Kubernetes 和底层云基础设施之间的互操作性逻辑，cloud-controller-manager 组件使云提供商能够以不同于 Kubernetes 主项目的步调发布新特性。

使用云基础设施技术，可以在公有云、私有云或者混合云环境中运行 Kubernetes。Kubernetes 的信条是基于自动化的、API 驱动的基础设施，同时避免组件间紧密耦合。cloud-controller-manager 组件基于一种插件机制来构造，这种机制使得不同的云厂商都能将其平台与 Kubernetes 集成。

官方文档参考

官方文档	链接
云控制器管理器（中文）	kubernetes.io/zh-cn/docs/concepts/architecture/cloud-controller

CCM 与 kube-controller-manager 的关系

在早期版本中，云相关逻辑内嵌在 kube-controller-manager 中；引入 CCM 后，与云平台交互的控制器被剥离到独立的 cloud-controller-manager 进程中。这样：

• kube-controller-manager 继续负责与具体云无关的通用控制器（如 Deployment、Endpoint 等控制器）；
• cloud-controller-manager 专注于与云 API 交互的部分（节点生命周期、路由、负载均衡等）；
• 云厂商可以独立于 Kubernetes 主项目迭代自己的云驱动。

为什么要分离

云厂商发布新特性的节奏与 Kubernetes 社区不同步。把云相关逻辑拆出来后，云厂商可以通过插件机制按自己的节奏发布功能，而不必等待 Kubernetes 大版本，也不必把云厂商代码塞进核心仓库。

设计与运行方式

运行方式	说明
多副本进程	云控制器管理器以一组多副本的进程集合的形式运行在控制面中，保证高可用
Pod 中的容器	通常表现为控制面节点上的 Pod 中的容器
插件形式	也可以用 Kubernetes 插件（Addon）的形式运行，而不是作为控制面的一部分

每个 cloud-controller-manager 在同一进程中实现多个控制器。

三大控制器

节点控制器

节点控制器负责在云基础设施中创建了新服务器时为之更新节点（Node）对象。它从云提供商获取当前租户中主机的信息，执行以下功能：

功能	说明
更新 Node 对象	使用从云平台 API 获取的对应服务器的唯一标识符更新 Node 对象
添加注解和标签	利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的区域（Region）和所具有的资源（CPU、内存等等）
获取网络信息	获取节点的网络地址和主机名
健康检查并删除 Node	检查节点的健康状况。如果节点无响应，控制器通过云平台 API 查看该节点是否已从云中禁用、删除或终止；如果节点已从云中删除，则控制器从 Kubernetes 集群中删除 Node 对象

某些云驱动实现不同

在某些云驱动实现中，上述任务被划分到一个节点控制器和一个节点生命周期控制器中。

路由控制器

路由控制器（Route Controller）负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的容器之间可以相互通信。取决于云驱动本身，路由控制器可能也会为 Pod 网络分配 IP 地址块。

服务控制器

服务控制器（Service Controller）使 Service 与受控的负载均衡器、IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。它监听 Service 对象的 create、update 和 delete 事件，并与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。

鉴权需求

本节分别列出云控制器管理器为了完成自身工作而产生的对各类 API 对象的访问需求（RBAC 权限清单）。

节点控制器

节点控制器只操作 Node 对象，它需要读取和修改 Node 对象的完全访问权限。

v1/Node：get、list、create、update、patch、watch、delete

路由控制器

路由控制器会监听 Node 对象的创建事件，并据此配置路由设施。它需要读取 Node 对象的 get 权限。

v1/Node：get

服务控制器

为了访问 Service 对象，它需要 list 和 watch 访问权限；为了更新 Service 对象，它需要针对 status 子资源的 patch 和 update 访问权限。

v1/Service：list、get、watch、patch、update

其他

在云控制器管理器的实现中，其核心部分需要创建 Event 对象的访问权限，并创建 ServiceAccount 资源以保证操作安全性的权限。

v1/Event：create、patch、update

v1/ServiceAccount：create

RBAC 示例

用于云控制器管理器 RBAC 的 ClusterRole 如下例所示：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
  - apiGroups:
      - ""
    resources:
      - events          # 事件资源
    verbs:
      - create          # 创建 Event
      - patch           # 修补 Event
      - update          # 更新 Event
  - apiGroups:
      - ""
    resources:
      - nodes           # 节点资源
    verbs:
      - '*'             # 对 Node 的完全访问权限
  - apiGroups:
      - ""
    resources:
      - nodes/status    # Node 的 status 子资源
    verbs:
      - patch
  - apiGroups:
      - ""
    resources:
      - services        # 服务资源
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - services/status # Service 的 status 子资源
    verbs:
      - patch
      - update
  - apiGroups:
      - ""
    resources:
      - serviceaccounts # 服务账号资源
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - persistentvolumes
    verbs:
      - get
      - list
      - update
      - watch

无云环境不部署

裸机与无云环境不要部署 CCM

云控制器管理器的价值在于连接云提供商的 API。在没有云基础设施的裸机环境或自建机房中，节点生命周期、路由、云负载均衡等能力都无从谈起，因此这类环境不需要（也不应该）部署 cloud-controller-manager。此时可以在 kube-controller-manager 上设置 --cloud-provider=external 之外，直接不启用 CCM；更常见的做法是保持集群组件与云解耦，由用户自行管理节点与网络。

接下来

• 云控制器管理器的管理：给出了运行和管理云控制器管理器的指南。
• 将复制的控制平面迁移以使用云控制器管理器：升级 HA 控制平面以使用 CCM 的步骤。
• 开发云控制器管理器：CCM 使用 Go 语言的接口（在 kubernetes/cloud-provider 项目中 cloud.go 文件中定义的 CloudProvider 接口），使得针对各种云平台的具体实现都可以接入。共享控制器（节点控制器、路由控制器和服务控制器等）的实现是 Kubernetes 的核心代码，特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 CloudProvider 接口。

我的总结与避坑清单

1. CCM 自 Kubernetes v1.11 起进入 Beta，本质是"从 kube-controller-manager 中剥离出来的云相关控制器集合"，不要把它和 kube-controller-manager 混为一谈。
2. 运行方式有两种：控制面中多副本进程（通常以 Pod 容器形式）或独立的插件（Addon），云厂商发行版多采用插件形式。
3. 记住三大控制器各自职责：节点控制器管 Node 对象的更新、注解标签、网络地址与健康检查删除；路由控制器管节点间路由（可能兼管 Pod 网段分配）；服务控制器管云负载均衡器等基础设施。
4. 排查 CCM 相关问题时先检查 RBAC：对 Node 是全权限，对 Service 是 list/watch + status 子资源 patch/update，对 Event 是 create/patch/update，对 ServiceAccount 是 create。
5. 健康检查失败不等于立刻删 Node：节点控制器会先通过云平台 API 确认节点是否已从云中删除/禁用/终止，确认后才删除 Node 对象。
6. 裸机集群或没有云 API 凭据的环境不要部署 CCM，否则相关控制器会持续报错却毫无作用。
7. 实现自定义云驱动时，重点是实现 kubernetes/cloud-provider 项目中定义的 CloudProvider 接口，而不是直接修改 Kubernetes 核心代码。