cloud-controller-manager 是一个 Kubernetes 控制平面 组件，它内嵌了特定于云的控制逻辑。云控制器管理器允许你将集群连接到云提供商的 API，并将那些与云平台交互的组件与那些仅与集群交互的组件分离开来。
通过解耦 Kubernetes 与底层云基础设施之间的互操作性逻辑，云控制器管理器组件使云提供商能够以与主 Kubernetes 项目不同的速度发布功能。
作为 云提供商抽取工作 的一部分，所有特定于云的控制器都必须从 kube-controller-manager 中移出。所有在 kube-controller-manager 中运行云控制器的现有集群必须迁移，改为在特定于云提供商的 cloud-controller-manager 中运行这些控制器。
领导者迁移（Leader Migration）提供了一种机制，使得高可用（HA）集群能够在升级复制控制平面的过程中，通过两个组件之间的共享资源锁，安全地在 kube-controller-manager 和 cloud-controller-manager 之间迁移“特定于云”的控制器。对于单节点控制平面，或者如果可以容忍升级期间控制器管理器不可用，则不需要领导者迁移，可以忽略本指南。
可以通过在 kube-controller-manager 或 cloud-controller-manager 上设置 --enable-leader-migration 来启用领导者迁移。领导者迁移仅在升级期间适用，在升级完成后可以安全地禁用或保持启用。
本指南将引导你完成手动升级控制平面的过程，从使用内置云提供商的 kube-controller-manager 转向同时运行 kube-controller-manager 和 cloud-controller-manager。如果你使用工具来部署和管理集群，请参考该工具和云提供商的文档以获取迁移的具体说明。
假设控制平面当前运行的是 Kubernetes N 版本，即将升级到 N + 1 版本。虽然可以在同一版本内进行迁移，但理想情况下，迁移应作为升级的一部分执行，以便配置更改能够与每个版本保持一致。N 和 N + 1 的确切版本取决于每个云提供商。例如，如果云提供商构建了一个 cloud-controller-manager 以与 Kubernetes 1.24 配合使用，则 N 可以是 1.23，N + 1 可以是 1.24。
控制平面节点应运行启用了领导者选举（这是默认设置）的 kube-controller-manager。截至 N 版本，必须设置 --cloud-provider 标志以使用树内云提供商，且此时不应部署 cloud-controller-manager。
树外云提供商必须构建一个实现了领导者迁移的 cloud-controller-manager。如果云提供商导入了 v0.21.0 或更高版本的 k8s.io/cloud-provider 和 k8s.io/controller-manager，则可以使用领导者迁移。但是，对于 v0.22.0 之前的版本，领导者迁移处于 alpha 阶段，需要在 cloud-controller-manager 中启用特性门控 ControllerManagerLeaderMigration。
本指南假设每个控制平面节点的 kubelet 将 kube-controller-manager 和 cloud-controller-manager 作为其清单（manifest）定义的静态 Pod 启动。如果组件在不同的环境中运行，请相应地调整步骤。
关于授权，本指南假设集群使用 RBAC。如果其他授权模式向 kube-controller-manager 和 cloud-controller-manager 组件授予权限，请以匹配该模式的方式授予必要的访问权限。
控制器管理器的默认权限仅允许访问它们的主要租约（Lease）。为了使迁移工作，需要访问另一个租约。
你可以通过修改 system::leader-locking-kube-controller-manager 角色，授予 kube-controller-manager 对 leases API 的完全访问权限。本任务指南假设迁移租约的名称为 cloud-provider-extraction-migration。
kubectl patch -n kube-system role 'system::leader-locking-kube-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge`
对 system::leader-locking-cloud-controller-manager 角色执行相同的操作。
kubectl patch -n kube-system role 'system::leader-locking-cloud-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge`
领导者迁移可以选择性地使用配置文件，该文件表示控制器到管理器的分配状态。目前，在使用树内云提供商时，kube-controller-manager 运行 route、service 和 cloud-node-lifecycle。以下示例配置显示了该分配。
可以在不使用配置的情况下启用领导者迁移。详情请参阅 默认配置。
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
- name: route
component: kube-controller-manager
- name: service
component: kube-controller-manager
- name: cloud-node-lifecycle
component: kube-controller-manager
或者，由于控制器可以在任一控制器管理器下运行，因此为迁移双方将 component 设置为 * 可以使配置文件在迁移双方之间保持一致。
# wildcard version
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
- name: route
component: *
- name: service
component: *
- name: cloud-node-lifecycle
component: *
在每个控制平面节点上，将内容保存到 /etc/leadermigration.conf，并更新 kube-controller-manager 的清单，以便将该文件挂载到容器内的相同位置。同时，更新同一清单以添加以下参数：
--enable-leader-migration：在控制器管理器上启用领导者迁移--leader-migration-config=/etc/leadermigration.conf：设置配置文件在每个节点上重启 kube-controller-manager。此时，kube-controller-manager 已启用领导者迁移，并为迁移做好准备。
在 N + 1 版本中，控制器到管理器的理想分配状态可以用一个新的配置文件来表示，如下所示。请注意，每个 controllerLeaders 的 component 字段从 kube-controller-manager 更改为了 cloud-controller-manager。或者，使用上面提到的通配符版本，效果相同。
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
- name: route
component: cloud-controller-manager
- name: service
component: cloud-controller-manager
- name: cloud-node-lifecycle
component: cloud-controller-manager
当创建 N + 1 版本的控制平面节点时，应将内容部署到 /etc/leadermigration.conf。应以与 N 版本的 kube-controller-manager 相同的方式更新 cloud-controller-manager 的清单以挂载配置文件。同样，将 --enable-leader-migration 和 --leader-migration-config=/etc/leadermigration.conf 添加到 cloud-controller-manager 的参数中。
创建一个带有已更新 cloud-controller-manager 清单的 N + 1 版本控制平面节点，并将 kube-controller-manager 的 --cloud-provider 标志设置为 external。N + 1 版本的 kube-controller-manager 必须禁用领导者迁移，因为在使用外部云提供商时，它不再运行已迁移的控制器，因此不参与迁移。
请参阅 云控制器管理器管理，了解有关如何部署 cloud-controller-manager 的更多详细信息。
此时，控制平面包含 N 和 N + 1 版本的节点。N 版本的节点仅运行 kube-controller-manager，而 N + 1 版本的节点同时运行 kube-controller-manager 和 cloud-controller-manager。已迁移的控制器（如配置中所指定）根据持有迁移租约的控制器管理器，在 N 版本的 kube-controller-manager 或 N + 1 版本的 cloud-controller-manager 下运行。在任何时间点，控制器都不会同时在两个控制器管理器下运行。
以滚动方式，创建一个新的 N + 1 版本控制平面节点，并停用一个 N 版本节点，直到控制平面仅包含 N + 1 版本的节点。如果需要从 N + 1 版本回滚到 N 版本，请将为 kube-controller-manager 启用了领导者迁移的 N 版本节点重新添加到控制平面，每次替换一个 N + 1 版本节点，直到只剩下 N 版本节点。
现在控制平面已升级为同时运行 N + 1 版本的 kube-controller-manager 和 cloud-controller-manager，领导者迁移已完成其任务，可以安全地禁用以节省一个租约资源。为了将来回滚，重新启用领导者迁移是安全的。
在滚动管理器中，更新 cloud-controller-manager 的清单以取消设置 --enable-leader-migration 和 --leader-migration-config= 标志，同时移除 /etc/leadermigration.conf 的挂载，最后移除 /etc/leadermigration.conf。要重新启用领导者迁移，请重新创建配置文件，并将其挂载以及启用领导者迁移的标志添加回 cloud-controller-manager。
从 Kubernetes 1.22 开始，领导者迁移提供了一个适用于默认控制器到管理器分配的默认配置。可以通过设置 --enable-leader-migration 但不设置 --leader-migration-config= 来启用默认配置。
对于 kube-controller-manager 和 cloud-controller-manager，如果没有标志启用任何树内云提供商或更改控制器的所有权，则可以使用默认配置来避免手动创建配置文件。
如果你的云提供商提供了 Node IPAM 控制器的实现，你应该切换到 cloud-controller-manager 中的实现。通过在 N + 1 版本的 kube-controller-manager 的标志中添加 --controllers=*,-nodeipam 来禁用其中的 Node IPAM 控制器。然后将 nodeipam 添加到已迁移控制器列表中。
# wildcard version, with nodeipam
kind: LeaderMigrationConfiguration
apiVersion: controllermanager.config.k8s.io/v1
leaderName: cloud-provider-extraction-migration
resourceLock: leases
controllerLeaders:
- name: route
component: *
- name: service
component: *
- name: cloud-node-lifecycle
component: *
- name: nodeipam
- component: *