迁移复制的控制平面以使用云控制器管理器
cloud-controller-manager 是 Kubernetes 控制平面的一个组件，它嵌入了云提供商特定的控制逻辑。cloud controller manager 让你能够将集群连接到云提供商的 API，并将与该云平台交互的组件与仅与集群交互的组件分离开来。
通过解耦 Kubernetes 与底层云基础设施之间的互操作逻辑，cloud-controller-manager 组件使得云提供商能够以与主 Kubernetes 项目不同的速度发布特性。
背景
作为云提供商提取工作的一部分，所有特定于云的控制器必须从 kube-controller-manager 中移出。所有在 kube-controller-manager 中运行云控制器的现有集群必须迁移到在云提供商特定的 cloud-controller-manager 中运行控制器。
Leader Migration 提供了一种机制，高可用（HA）集群可以在升级复制的控制平面时，通过两个组件之间的共享资源锁，在 kube-controller-manager 和 cloud-controller-manager 之间安全地迁移“特定于云的”控制器。对于单节点控制平面，或者如果在升级期间可以容忍控制器管理器不可用，则不需要 Leader Migration，可以忽略本指南。
可以通过在 kube-controller-manager 或 cloud-controller-manager 上设置 --enable-leader-migration 来启用 Leader Migration。Leader Migration 仅在升级期间适用，升级完成后可以安全地禁用或保持启用状态。
本指南将引导你完成手动过程，将控制平面从使用内置云提供商的 kube-controller-manager 升级到同时运行 kube-controller-manager 和 cloud-controller-manager。如果你使用工具部署和管理集群，请参考该工具和云提供商的文档以获取具体的迁移说明。
开始之前
假定控制平面正在运行 Kubernetes N 版本，并将升级到 N + 1 版本。虽然可以在同一版本内进行迁移，但理想情况下，迁移应作为升级的一部分进行，以便配置的更改可以与每个版本对齐。N 和 N + 1 的具体版本取决于每个云提供商。例如，如果一个云提供商构建了一个与 Kubernetes 1.24 一起工作的 cloud-controller-manager，那么 N 可以是 1.23，N + 1 可以是 1.24。
控制平面节点应运行启用了 Leader Election 的 kube-controller-manager，这是默认设置。截至 N 版本，必须使用 --cloud-provider 标志设置一个 in-tree 云提供商，并且 cloud-controller-manager 不应尚未部署。
out-of-tree 云提供商必须构建一个实现了 Leader Migration 的 cloud-controller-manager。如果云提供商导入了 v0.21.0 或更高版本的 k8s.io/cloud-provider 和 k8s.io/controller-manager，则 Leader Migration 将可用。但是，对于 v0.22.0 之前的版本，Leader Migration 是 alpha 阶段，需要在 cloud-controller-manager 中启用特性门控 ControllerManagerLeaderMigration。
本指南假设每个控制平面节点的 kubelet 通过其清单定义的静态 Pod 启动 kube-controller-manager 和 cloud-controller-manager。如果组件在不同设置中运行，请相应调整步骤。
对于授权，本指南假设集群使用 RBAC。如果使用其他授权模式为 kube-controller-manager 和 cloud-controller-manager 组件授予权限，请以与该模式匹配的方式授予所需的访问权限。
授予对迁移租约的访问权限
控制器管理器的默认权限仅允许访问其主租约。为了使迁移工作，需要访问另一个租约。
你可以通过修改 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`
初步 Leader Migration 配置
Leader Migration 可以选择接受一个表示控制器到管理器分配状态的配置文件。此时，对于 in-tree 云提供商，kube-controller-manager 运行 route、service 和 cloud-node-lifecycle。以下示例配置显示了此分配。
可以在没有配置的情况下启用 Leader Migration。详见默认配置。
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--leader-migration-config=/etc/leadermigration.conf设置配置文件
重启每个节点上的 kube-controller-manager。此时，kube-controller-manager 已启用 leader migration，并准备好进行迁移。
部署 Cloud 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。应更新 cloud-controller-manager 的清单，以与 N 版本 kube-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 不应启用 Leader Migration，因为使用外部云提供商时，它不再运行已迁移的控制器，因此不参与迁移。
有关如何部署 cloud-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 版本，将 N 版本的、为 kube-controller-manager 启用了 Leader Migration 的节点重新添加到控制平面，每次替换一个 N + 1 版本的节点，直到只剩下 N 版本的节点。
（可选）禁用 Leader Migration
现在控制平面已升级到同时运行 N + 1 版本的 kube-controller-manager 和 cloud-controller-manager，Leader Migration 已完成其任务，可以安全地禁用以节省一个 Lease 资源。将来为了回滚而重新启用 Leader Migration 是安全的。
以滚动方式，更新 cloud-controller-manager 的清单，取消设置 --enable-leader-migration 和 --leader-migration-config= 标志，同时移除 /etc/leadermigration.conf 的挂载，最后移除 /etc/leadermigration.conf 文件。要重新启用 Leader Migration，请重新创建配置文件，并将其挂载和启用 Leader Migration 的标志重新添加到 cloud-controller-manager。
默认配置
从 Kubernetes 1.22 开始，Leader Migration 提供了一个适用于默认控制器到管理器分配的默认配置。可以通过设置 --enable-leader-migration 但不带 --leader-migration-config= 来启用默认配置。
对于 kube-controller-manager 和 cloud-controller-manager，如果没有启用任何 in-tree 云提供商或更改控制器所有权的标志，则可以使用默认配置来避免手动创建配置文件。
特殊情况：迁移 Node IPAM 控制器
如果你的云提供商提供了 Node IPAM 控制器的实现，你应该切换到 cloud-controller-manager 中的实现。通过在其标志中添加 --controllers=*,-nodeipam 来禁用 N + 1 版本 kube-controller-manager 中的 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: *