将重复的控制平面迁至云控制器管理器

FEATURE STATE: Kubernetes v1.21 [alpha]

云管理控制器是 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上, 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑, 云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的 步调发布新特征。

背景

作为云驱动提取工作 的一部分,所有特定于云的控制器都必须移出 kube-controller-manager。 所有在 kube-controller-manager 中运行云控制器的现有集群必须迁移到云驱动特定的 cloud-controller-manager 中运行控制器。

领导者迁移提供了一种机制,使得 HA 集群可以通过两个组件之间的共享资源锁定, 安全地将“特定于云”的控制器从 kube-controller-manager 和迁移到cloud-controller-manager, 同时升级复制的控制平面。 对于单节点控制平面,或者在升级过程中可以容忍控制器管理器不可用的情况,则不需要领导者迁移,并且可以忽略本指南。

领导者迁移是一项 Alpha 阶段功能,默认情况下处于禁用状态,它需要设置控制器管理器的 --enable-leader-migration 参数。 可以通过在 kube-controller-managercloud-controller-manager 上设置特性门控 ControllerManagerLeaderMigration--enable-leader-migration 来启用。 领导者迁移仅在升级期间适用,并且可以安全地禁用,也可以在升级完成后保持启用状态。

本指南将引导你手动将控制平面从内置的云驱动的 kube-controller-manager 升级为 同时运行 kube-controller-managercloud-controller-manager。 如果使用工具来管理群集,请参阅对应工具和云驱动的文档以获取更多详细信息。

准备开始

假定控制平面正在运行 Kubernetes N 版本,并且要升级到 N+1 版本。 尽管可以在同一版本中进行迁移,但理想情况下,迁移应作为升级的一部分执行,以便可以更改配置与发布保持一致。 N 和 N+1的确切版本取决于各个云驱动。例如,如果云驱动构建了一个可与 Kubernetes 1.22 配合使用的 cloud-controller-manager, 则 N 可以为 1.21,N+1 可以为 1.22。

控制平面节点应运行 kube-controller-manager,并通过 --leader-elect=true 启用领导者选举。 从版本 N 开始,树内云驱动必须设置 --cloud-provider 标志,而且 cloud-controller-manager 尚未部署。

树外云驱动必须已经构建了一个实现领导者迁移的 cloud-controller-manager。 如果云驱动导入了 v0.21.0 或更高版本的 k8s.io/cloud-providerk8s.io/controller-manager, 则可以进行领导者迁移。

本指南假定每个控制平面节点的 kubelet 以静态 pod 的形式启动 kube-controller-managercloud-controller-manager,静态 pod 的定义在清单文件中。 如果组件以其他设置运行,请相应地调整步骤。

为了获得授权,本指南假定集群使用 RBAC。 如果其他授权模式授予 kube-controller-managercloud-controller-manager 组件权限, 请以与该模式匹配的方式授予所需的访问权限。

授予访问迁移 Lease 的权限

控制器管理器的默认权限仅允许访问其主 Lease 对象。为了使迁移正常进行,需要访问其他 Lease 对象。

你可以通过修改 system::leader-locking-kube-controller-manager 角色来授予 kube-controller-manager 对 Lease API 的完全访问权限。 本任务指南假定迁移 Lease 的名称为 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 运行 routeservicecloud-node-lifecycle。 以下示例配置显示了分配。

  1. kind: LeaderMigrationConfiguration
  2. apiVersion: controllermanager.config.k8s.io/v1alpha1
  3. leaderName: cloud-provider-extraction-migration
  4. resourceLock: leases
  5. controllerLeaders:
  6. - name: route
  7. component: kube-controller-manager
  8. - name: service
  9. component: kube-controller-manager
  10. - name: cloud-node-lifecycle
  11. component: kube-controller-manager

在每个控制平面节点上,将内容保存到 /etc/leadermigration.conf 中, 并更新 kube-controller-manager 清单,以便将文件安装在容器内的同一位置。 另外,更新相同的清单,添加以下参数:

  • --feature-gates=ControllerManagerLeaderMigration=true 启用领导者迁移(这是 Alpha 版功能)
  • --enable-leader-migration 在控制器管理器上启用领导者迁移
  • --leader-migration-config=/etc/leadermigration.conf 设置配置文件

在每个节点上重新启动 kube-controller-manager。这时,kube-controller-manager 已启用领导者迁移,并准备进行迁移。

部署云控制器管理器

在 N+1 版本中,控制器到管理器分配的期望状态可以由新的配置文件表示,如下所示。 请注意,每个 controllerLeaderscomponent 字段从 kube-controller-manager 更改为 cloud-controller-manager

  1. kind: LeaderMigrationConfiguration
  2. apiVersion: controllermanager.config.k8s.io/v1alpha1
  3. leaderName: cloud-provider-extraction-migration
  4. resourceLock: leases
  5. controllerLeaders:
  6. - name: route
  7. component: cloud-controller-manager
  8. - name: service
  9. component: cloud-controller-manager
  10. - name: cloud-node-lifecycle
  11. component: cloud-controller-manager

当创建 N+1 版本的控制平面节点时,应将内容部署到 /etc/leadermigration.conf。 应该更新 cloud-controller-manager 清单,以与 N 版本的 kube-controller-manager 相同的方式挂载配置文件。 类似地,添加 --feature-gates=ControllerManagerLeaderMigration=true--enable-leader-migration--leader-migration-config=/etc/leadermigration.confcloud-controller-manager 的参数中。

使用已更新的 cloud-controller-manager 清单创建一个新的 N+1 版本的控制平面节点。 并且没有设置 kube-controller-manager--cloud-provider 标志。 N+1 版本的 kube-controller-manager 不能启用领导者迁移, 因为在使用外部云驱动的情况下,它不再运行已迁移的控制器,因此不参与迁移。

请参阅云控制器管理器管理 了解有关如何部署 cloud-controller-manager 的更多细节。

升级控制平面

现在,控制平面包含 N 和 N+1 版本的节点。 N 版本的节点仅运行 kube-controller-manager,而 N+1 版本的节点同时运行 kube-controller-managercloud-controller-manager。 根据配置所指定,已迁移的控制器在 N 版本的 kube-controller-manager 或 N+1 版本的 cloud-controller-manager 下运行, 具体取决于哪个控制器管理器拥有迁移 Lease 对象。任何时候都不存在一个控制器在两个控制器管理器下运行。

以滚动的方式创建一个新的版本为 N+1 的控制平面节点,并将 N+1 版本中的一个关闭, 直到控制平面仅包含版本为 N+1 的节点。 如果需要从 N+1 版本回滚到 N 版本,则将启用了领导者迁移的 kube-controller-manager 且版本为 N 的节点添加回控制平面,每次替换 N+1 版本的一个,直到只有 N 版本的节点为止。

(可选)禁用领导者迁移

现在,控制平面已经升级,可以同时运行 N+1 版本的 kube-controller-managercloud-controller-manager 了。 领导者迁移已经完成工作,可以安全地禁用以节省一个 Lease 资源。 在将来可以安全地重新启用领导者迁移以完成回滚。

在滚动管理器中,更新 cloud-controller-manager 的清单以同时取消设置 --enable-leader-migration--leader-migration-config= 标志,并删除 /etc/leadermigration.conf 的挂载。 最后删除 /etc/leadermigration.conf。 要重新启用领导者迁移,请重新创建配置文件,并将其挂载和启用领导者迁移的标志添加回到 cloud-controller-manager

接下来

最后修改 April 26, 2021 at 10:15 AM PST : [zh] translate administer-cluster/controller-manager-leader-migration.md (d82bfa763)