-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[zh] translate administer-cluster/controller-manager-leader-migration.md
- Loading branch information
1 parent
1869573
commit b7b0cf6
Showing
1 changed file
with
278 additions
and
0 deletions.
There are no files selected for viewing
278 changes: 278 additions & 0 deletions
278
content/zh/docs/tasks/administer-cluster/controller-manager-leader-migration.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,278 @@ | ||
--- | ||
title: "使用云管理控制器将复制的控制平面迁移" | ||
linkTitle: "将复制的控制平面迁移以使用云管理控制器" | ||
content_type: task | ||
--- | ||
|
||
<!-- | ||
--- | ||
reviewers: | ||
- jpbetz | ||
- cheftako | ||
title: "Migrate Replicated Control Plane To Use Cloud Controller Manager" | ||
linkTitle: "Migrate Replicated Control Plane To Use Cloud Controller Manager" | ||
content_type: task | ||
--- | ||
--> | ||
|
||
<!-- overview --> | ||
|
||
{{< feature-state state="alpha" for_k8s_version="v1.21" >}} | ||
|
||
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="云管理控制器是">}} | ||
|
||
<!-- | ||
## Background | ||
As part of the [cloud provider extraction effort](https://kubernetes.io/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/), | ||
all cloud specific controllers must be moved out of the `kube-controller-manager`. | ||
All existing clusters that run cloud controllers in the `kube-controller-manager` must migrate to instead run the controllers in a cloud provider specific `cloud-controller-manager`. | ||
Leader Migration provides a mechanism in which HA clusters can safely migrate "cloud specific" controllers between | ||
the `kube-controller-manager` and the `cloud-controller-manager` via a shared resource lock between the two components while upgrading the replicated control plane. | ||
For a single-node control plane, or if unavailability of controller managers can be tolerated during the upgrade, Leader Migration is not needed and this guide can be ignored. | ||
Leader Migration is an alpha feature that is disabled by default and it requires `--enable-leader-migration` to be set on controller managers. | ||
It can be enabled by setting the feature gate `ControllerManagerLeaderMigration` plus `--enable-leader-migration` on `kube-controller-manager` or `cloud-controller-manager`. | ||
Leader Migration only applies during the upgrade and can be safely disabled or left enabled after the upgrade is complete. | ||
This guide walks you through the manual process of upgrading the control plane from `kube-controller-manager` with | ||
built-in cloud provider to running both `kube-controller-manager` and `cloud-controller-manager`. | ||
If you use a tool to administrator the cluster, please refer to the documentation of the tool and the cloud provider for more details. | ||
--> | ||
## 背景 | ||
作为 [云提供商提取工作](https://kubernetes.io/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/)的一部分, | ||
所有特定于云的控制器都必须移出 `kube-controller-manager`。 | ||
所有在 `kube-controller-manager` 中运行云控制器的现有集群必须迁移到特定于云提供商的 `kube-controller-manager` 中运行控制器。 | ||
|
||
领导者迁移提供了一种机制,其中 HA 集群可以通过两个组件之间的共享资源锁定, | ||
在 `kube-controller-manager` 和 `cloud-controller-manager` 之间安全地迁移 “特定于云” 的控制器,同时升级复制的控制平面。 | ||
对于单节点控制平面,或者在升级过程中可以容忍控制器管理器不可用的情况,则不需要领导者迁移,并且可以忽略本指南。 | ||
|
||
领导者迁移是一项 Alpha 阶段功能,默认情况下处于禁用状态,它需要在控制管理器上设置 `--enable-leader-migration`。 | ||
可以通过在 `kube-controller-manager` 或 `cloud-controller-manager` 上设置功能门 | ||
`ControllerManagerLeaderMigration` 和 `--enable-leader-migration` 来启用。 | ||
领导者迁移仅在升级期间适用,并且可以安全地禁用,也可以在升级完成后保持启用状态。 | ||
|
||
本指南将引导你手动将控制平面从内置云提供程序的 `kube-controller-manager` 升级到同时运行 `kube-controller-manager` 和 `cloud-controller-manager`。 | ||
如果使用工具来管理群集,请参阅该工具和云提供商的文档以获取更多详细信息。 | ||
|
||
## {{% heading "prerequisites" %}} | ||
|
||
<!-- | ||
It is assumed that the control plane is running Kubernetes version N and to be upgraded to version N + 1. | ||
Although it is possible to migrate within the same version, ideally the migration should be performed as part of a upgrade so that changes of configuration can be aligned to releases. | ||
The exact versions of N and N + 1 depend on each cloud provider. For example, if a cloud provider builds a `cloud-controller-manager` to work with Kubernetes 1.22, then N can be 1.21 and N + 1 can be 1.22. | ||
The control plane nodes should run `kube-controller-manager` with Leader Election enabled through `--leader-elect=true`. | ||
As of version N, an in-tree cloud privider must be set with `--cloud-provider` flag and `cloud-controller-manager` should not yet be deployed. | ||
The out-of-tree cloud provider must have built a `cloud-controller-manager` with Leader Migration implementation. | ||
If the cloud provider imports `k8s.io/cloud-provider` and `k8s.io/controller-manager` of version v0.21.0 or later, Leader Migration will be avaliable. | ||
This guide assumes that kubelet of each control plane node starts `kube-controller-manager` | ||
and `cloud-controller-manager` as static pods defined by their manifests. | ||
If the components run in a different setting, please adjust the steps accordingly. | ||
For authorization, this guide assumes that the cluser uses RBAC. | ||
If another authorization mode grants permissions to `kube-controller-manager` and `cloud-controller-manager` components, | ||
please grant the needed access in a way that matches the mode. | ||
--> | ||
假定控制平面正在运行 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 开始,In-Tree 云提供商必须设置 `--cloud-provider` 标志,而且 `cloud-controller-manager` 还尚未部署。 | ||
|
||
Out-Of-Tree 云提供商必须已经使用领导者迁移实施构建了一个 `cloud-controller-manager`。 | ||
如果云提供商导入了 v0.21.0 或更高版本的 `k8s.io/cloud-provider` 和 `k8s.io/controller-manager` ,则可以进行领导者迁移。 | ||
|
||
本指南假定每个控制平面节点的 kubelet 以清单形式定义的静态 pod 的形式启动 `kube-controller-manager` 和 `cloud-controller-manager`。 | ||
如果组件以其他设置运行,请相应地调整步骤。 | ||
|
||
为了获得授权,本指南假定集群使用 RBAC。如果另一种授权模式授予 `kube-controller-manager` 和 `cloud-controller-manager` 组件权限, | ||
请以与该模式匹配的方式授予所需的访问权限。 | ||
|
||
<!-- steps --> | ||
|
||
<!-- | ||
### Grant access to Migration Lease | ||
The default permissions of the controller manager allow only accesses to their main Lease. | ||
In order for the migration to work, accesses to another Lease are required. | ||
You can grant `kube-controller-manager` full access to the leases API by modifying | ||
the `system::leader-locking-kube-controller-manager` role. | ||
This task guide assumes that the name of the migration lease is `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` | ||
Do the same to the `system::leader-locking-cloud-controller-manager` role. | ||
`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` | ||
--> | ||
### 授予访问迁移租赁的权限 | ||
|
||
控制器管理器的默认权限仅允许访问其主租约。为了使迁移正常进行,需要访问另一个租约。 | ||
|
||
您可以通过修改 `system::leader-locking-kube-controller-manager` 角色来授予 `kube-controller-manager` 完全访问租约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` | ||
|
||
<!-- | ||
### Initial Leader Migration configuration | ||
Leader Migration requires a configuration file representing the state of controller-to-manager assignment. | ||
At this moment, with in-tree cloud provider, `kube-controller-manager` runs `route`, `service`, and `cloud-node-lifecycle`. | ||
The following example configuration shows the assignment. | ||
--> | ||
### 初始领导者迁移配置 | ||
|
||
领导者迁移需要一个表示控制器到管理器分配状态的配置文件。 | ||
目前,对于 in-tree 云提供商, `kube-controller-manager` 运行 `route`、 `service` 和 `cloud-node-lifecycle`。 | ||
以下示例配置显示了分配。 | ||
|
||
```yaml | ||
kind: LeaderMigrationConfiguration | ||
apiVersion: controllermanager.config.k8s.io/v1alpha1 | ||
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 | ||
``` | ||
<!-- | ||
On each control plane node, save the content to `/etc/leadermigration.conf`, | ||
and update the manifest of `kube-controller-manager` so that the file is mounted inside the container at the same location. | ||
Also, update the same manifest to add the following arguments: | ||
|
||
- `--feature-gates=ControllerManagerLeaderMigration=true` to enable Leader Migration which is an alpha feature | ||
- `--enable-leader-migration` to enable Leader Migration on the controller manager | ||
- `--leader-migration-config=/etc/leadermigration.conf` to set configuration file | ||
|
||
Restart `kube-controller-manager` on each node. At this moment, `kube-controller-manager` has leader migration enabled and is ready for the migration. | ||
--> | ||
在每个控制平面节点上,将内容保存到 `/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` 已启用领导者迁移,并准备进行迁移。 | ||
|
||
<!-- | ||
### Deploy Cloud Controller Manager | ||
|
||
In version N + 1, the desired state of controller-to-manager assignment can be represented by a new configuration file, shown as follows. | ||
Please note `component` field of each `controllerLeaders` changing from `kube-controller-manager` to `cloud-controller-manager`. | ||
--> | ||
### 部署云控制器管理器 | ||
|
||
在 N + 1 版本中,控制器到管理器分配的期望状态可以由新的配置文件表示,如下所示。 | ||
请注意,每个 `controllerLeaders` 的 `component` 字段从 `kube-controller-manager` 更改为 `cloud-controller-manager`。 | ||
|
||
```yaml | ||
kind: LeaderMigrationConfiguration | ||
apiVersion: controllermanager.config.k8s.io/v1alpha1 | ||
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 | ||
``` | ||
|
||
<!-- | ||
When creating control plane nodes of version N + 1, the content should be deploy to `/etc/leadermigration.conf`. | ||
The manifest of `cloud-controller-manager` should be updated to mount the configuration file in | ||
the same manner as `kube-controller-manager` of version N. Similarly, add `--feature-gates=ControllerManagerLeaderMigration=true`, | ||
`--enable-leader-migration`, and `--leader-migration-config=/etc/leadermigration.conf` to the arguments of `cloud-controller-manager`. | ||
|
||
Create a new control plane node of version N + 1 with the updated `cloud-controller-manager` manifest, | ||
and with the `--cloud-provider` flag unset for `kube-controller-manager`. | ||
`kube-controller-manager` of version N + 1 MUST NOT have Leader Migration enabled because, | ||
with an external cloud provider, it does not run the migrated controllers anymore and thus it is not involved in the migration. | ||
|
||
Please refer to [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) | ||
for more detail on how to deploy `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.conf` 到 `cloud-controller-manager`。 | ||
|
||
使用更新的 `cloud-controller-manager` 清单创建一个新的 N + 1 版本的控制平面节点。 | ||
并且 `kube-controller-manager` 的 `--cloud-provider` 标志没有设置。 | ||
N + 1 版本的 `kube-controller-manager` 不能启用领导者迁移, | ||
因为在对于外部云提供商,它不再运行已迁移的控制器,因此不参与迁移。 | ||
|
||
请参阅 [云控制器管理器管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/) | ||
了解有关如何部署 `cloud-controller-manager` 的更多详细信息。 | ||
|
||
<!-- | ||
### Upgrade Control Plane | ||
|
||
The control plane now contains nodes of both version N and N + 1. | ||
The nodes of version N run `kube-controller-manager` only, | ||
and these of version N + 1 run both `kube-controller-manager` and `cloud-controller-manager`. | ||
The migrated controllers, as specified in the configuration, are running under either `kube-controller-manager` of | ||
version N or `cloud-controller-manager` of version N + 1 depending on which controller manager holds the migration lease. | ||
No controller will ever be running under both controller managers at any time. | ||
|
||
In a rolling manner, create a new control plane node of version N + 1 and bring down one of version N + 1 until the control plane contains only nodes of version N + 1. | ||
If a rollback from version N + 1 to N is required, add nodes of version N with Leader Migration enabled for `kube-controller-manager` back to the control plane, replacing one of version N + 1 each time until there are only nodes of version N. | ||
--> | ||
### 升级控制平面 | ||
|
||
现在,控制平面包含 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 + 1 版本中的一个关闭,直到控制平面仅包含版本为 N + 1 的节点。 | ||
如果需要从版本 N + 1 到 N 的回滚,则将启用了针对 `kube-controller-manager` 的领导者迁移的版本N的节点添加回控制平面,每次替换版本 N + 1 的一个,直到只有节点为止版本N。 | ||
|
||
<!-- | ||
### (Optional) Disable Leader Migration {#disable-leader-migration} | ||
|
||
Now that the control plane has been upgraded to run both `kube-controller-manager` and `cloud-controller-manager` of version N + 1, | ||
Leader Migration has finished its job and can be safely disabled to save one Lease resource. | ||
It is safe to re-enable Leader Migration for the rollback in the future. | ||
|
||
In a rolling manager, update manifest of `cloud-controller-manager` to unset both | ||
`--enable-leader-migration` and `--leader-migration-config=` flag, | ||
also remove the mount of `/etc/leadermigration.conf`, and finally remove `/etc/leadermigration.conf`. | ||
To re-enable Leader Migration, recreate the configuration file and add its mount and the flags that enable Leader Migration back to `cloud-controller-manager`. | ||
--> | ||
### (可选)禁用领导者迁移 {#disable-leader-migration} | ||
|
||
现在,控制平面已经升级,可以同时运行 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`。 | ||
|
||
## {{% heading "whatsnext" %}} | ||
<!-- | ||
- Read the [Controller Manager Leader Migration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cloud-provider/2436-controller-manager-leader-migration) enhancement proposal | ||
--> | ||
-阅读 [领导者迁移控制器管理器](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cloud-provider/2436-controller-manager-leader-migration) 改进建议 |