在受限网络环境中安装 MTC | 容器迁移工具包 | OpenShift Container Platform 4.17

兼容性指南
在 OpenShift Container Platform 4.17 上安装容器迁移工具包操作符
在 OpenShift Container Platform 4.2 到 4.5 上安装旧版容器迁移工具包操作符
代理配置
以 root 或非 root 用户身份运行 Rsync
- 为所有迁移配置 MigrationController CR 为 root 或非 root 用户身份
- 为每个迁移配置 MigMigration CR 为 root 或非 root 用户身份
配置复制存储库
卸载 MTC 并删除资源

您可以在受限网络环境中通过执行以下步骤在 OpenShift Container Platform 4 上安装容器迁移工具包 (MTC)：

创建一个镜像操作符目录。

此过程会创建一个mapping.txt文件，其中包含registry.redhat.io镜像和镜像注册表镜像之间的映射。mapping.txt文件是在 OpenShift Container Platform 4.2 到 4.5 源集群上安装*旧版*容器迁移工具包操作符所必需的。
使用 Operator Lifecycle Manager 在 OpenShift Container Platform 4.17 目标集群上安装容器迁移工具包操作符。

默认情况下，MTC Web 控制台和Migration Controller Pod 在目标集群上运行。您可以配置Migration Controller自定义资源清单，以便在远程集群上运行 MTC Web 控制台和Migration Controller Pod。
在源集群上安装容器迁移工具包操作符
- OpenShift Container Platform 4.6 或更高版本：使用 Operator Lifecycle Manager 安装容器迁移工具包操作符。
- OpenShift Container Platform 4.2 到 4.5：从命令行界面安装旧版容器迁移工具包操作符。
配置用作复制存储库的对象存储。

要安装在 OpenShift Container Platform 3 上安装 MTC，请参阅在 OpenShift Container Platform 3 上安装旧版容器迁移工具包操作符。

要卸载 MTC，请参阅卸载 MTC 并删除资源。

兼容性指南

您必须安装与您的 OpenShift Container Platform 版本兼容的容器迁移工具包 (MTC) 操作符。

定义

旧平台: OpenShift Container Platform 4.5 和更早版本。
现代平台: OpenShift Container Platform 4.6 和更高版本。
旧版操作符: 为旧平台设计的 MTC 操作符。
现代操作符: 为现代平台设计的 MTC 操作符。
控制集群: 运行 MTC 控制器和 GUI 的集群。
远程集群: 运行 Velero 的迁移的源集群或目标集群。控制集群通过 Velero API 与远程集群通信以驱动迁移。

您必须使用兼容的 MTC 版本来迁移您的 OpenShift Container Platform 集群。为了使迁移成功，您的源集群和目标集群必须使用相同版本的 MTC。

MTC 1.7 支持从 OpenShift Container Platform 3.11 到 4.9 的迁移。

MTC 1.8 仅支持从 OpenShift Container Platform 4.10 和更高版本的迁移。

表 1. MTC 兼容性：从旧平台或现代平台迁移
详情	OpenShift Container Platform 3.11	OpenShift Container Platform 4.0 到 4.5	OpenShift Container Platform 4.6 到 4.9	OpenShift Container Platform 4.10 或更高版本
稳定版 MTC 版本	MTC v.1.7.z	MTC v.1.7.z	MTC v.1.7.z	MTC v.1.8.z
安装		旧版 MTC v.1.7.z 操作符：使用`operator.yml`文件手动安装。 [重要] 此集群不能是控制集群。	使用 OLM 安装，发行渠道`release-v1.7`	使用 OLM 安装，发行渠道`release-v1.8`

存在一些极端情况，其中网络限制会阻止现代集群连接到参与迁移的其他集群。例如，当从本地部署的 OpenShift Container Platform 3.11 集群迁移到云中的现代 OpenShift Container Platform 集群时，现代集群无法连接到 OpenShift Container Platform 3.11 集群。

对于 MTC v.1.7.z，如果由于网络限制导致某个远程集群无法与控制集群通信，请使用crane tunnel-api 命令。

在稳定的 MTC 版本中，虽然应始终将最新的集群指定为控制集群，但在这种特定情况下，可以将旧版集群指定为控制集群并将工作负载推送到远程集群。

在 OpenShift Container Platform 4.17 上安装容器迁移工具操作符

您可以使用 Operator Lifecycle Manager 在 OpenShift Container Platform 4.17 上安装容器迁移工具操作符。

先决条件

您必须以所有集群上具有cluster-admin权限的用户身份登录。
您必须从本地注册表中的镜像创建操作符目录。

步骤

在 OpenShift Container Platform Web 控制台中，单击**操作符** → **OperatorHub**。
使用**按关键字筛选**字段查找**容器迁移工具操作符**。
选择**容器迁移工具操作符**并单击**安装**。
单击**安装**。

在**已安装的操作符**页面上，**容器迁移工具操作符**将显示在openshift-migration项目中，状态为**成功**。
单击**容器迁移工具操作符**。
在**提供的 API**下，找到**迁移控制器**磁贴，然后单击**创建实例**。
单击**创建**。
单击**工作负载** → **Pod**以验证 MTC Pod 是否正在运行。

在 OpenShift Container Platform 4.2 到 4.5 上安装旧版容器迁移工具操作符

您可以在 OpenShift Container Platform 4.2 到 4.5 版本上手动安装旧版容器迁移工具操作符。

先决条件

您必须以所有集群上具有cluster-admin权限的用户身份登录。
您必须能够访问registry.redhat.io。
您必须安装podman。
您必须拥有能够从registry.redhat.io下载文件的网络访问权限的 Linux 工作站。
您必须创建一个操作符目录的镜像。
您必须从 OpenShift Container Platform 4.17 上的镜像操作符目录安装容器迁移工具操作符。

步骤

使用您的 Red Hat 客户门户凭据登录registry.redhat.io
```
$ podman login registry.redhat.io
```

通过输入以下命令下载operator.yml文件

podman cp $(podman create registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.7):/operator.yml ./

通过输入以下命令下载controller.yml文件

podman cp $(podman create registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.7):/controller.yml ./

通过运行以下命令获取操作符镜像映射

$ grep openshift-migration-legacy-rhel8-operator ./mapping.txt | grep rhmtc

mapping.txt文件是在镜像操作符目录时创建的。输出显示registry.redhat.io镜像和您的镜像注册表镜像之间的映射。

示例输出

registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a=<registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator

更新operator.yml文件中的ansible和operator容器的image值以及REGISTRY值

containers:
  - name: ansible
    image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> (1)
...
  - name: operator
    image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> (1)
...
    env:
    - name: REGISTRY
      value: <registry.apps.example.com> (2)

1	指定您的镜像注册表和操作符镜像的`sha256`值。
2	指定您的镜像注册表。

登录到您的 OpenShift Container Platform 源集群。

创建容器迁移工具操作符对象

$ oc create -f operator.yml

示例输出

namespace/openshift-migration created
rolebinding.rbac.authorization.k8s.io/system:deployers created
serviceaccount/migration-operator created
customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
role.rbac.authorization.k8s.io/migration-operator created
rolebinding.rbac.authorization.k8s.io/migration-operator created
clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
deployment.apps/migration-operator created
Error from server (AlreadyExists): error when creating "./operator.yml":
rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists (1)
Error from server (AlreadyExists): error when creating "./operator.yml":
rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

1	您可以忽略`Error from server (AlreadyExists)`消息。这些消息是由容器迁移工具操作符为早期版本的 OpenShift Container Platform 4 创建但在后期版本中提供的资源引起的。

创建MigrationController对象
```
$ oc create -f controller.yml
```
验证 MTC Pod 是否正在运行
```
$ oc get pods -n openshift-migration
```

代理配置

对于 OpenShift Container Platform 4.1 和更早版本，您必须在安装容器迁移工具操作符后在MigrationController自定义资源 (CR) 清单中配置代理，因为这些版本不支持集群范围的proxy对象。

对于 OpenShift Container Platform 4.2 到 4.17，MTC 继承集群范围的代理设置。如果要覆盖集群范围的代理设置，可以更改代理参数。

直接卷迁移

直接卷迁移 (DVM) 在 MTC 1.4.2 中引入。DVM 只支持一个代理。如果目标集群也位于代理之后，则源集群无法访问目标集群的路由。

如果要从位于代理后面的源集群执行 DVM，则必须配置一个在传输层工作的 TCP 代理，并透明地转发 SSL 连接，而无需使用其自身的 SSL 证书对其进行解密和重新加密。Stunnel 代理就是这样一种代理的示例。

DVM 的 TCP 代理设置

您可以通过 TCP 代理设置源集群和目标集群之间的直接连接，并在MigrationController CR 中配置stunnel_tcp_proxy变量以使用该代理

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  stunnel_tcp_proxy: http://username:password@ip:port

直接卷迁移 (DVM) 只支持代理的基本身份验证。此外，DVM 只能在能够透明地隧道 TCP 连接的代理后面工作。中间人模式下的 HTTP/HTTPS 代理不起作用。现有的集群范围代理可能不支持此行为。因此，DVM 的代理设置与 MTC 中通常的代理配置有意保持不同。

为什么使用 TCP 代理而不是 HTTP/HTTPS 代理？

您可以通过在 OpenShift 路由上运行源集群和目标集群之间的 Rsync 来启用 DVM。流量使用 Stunnel（一个 TCP 代理）进行加密。在源集群上运行的 Stunnel 与目标 Stunnel 建立 TLS 连接，并通过加密通道传输数据。

OpenShift 中的集群范围 HTTP/HTTPS 代理通常在中间人模式下配置，在该模式下它们与外部服务器协商自己的 TLS 会话。但是，这与 Stunnel 不兼容。Stunnel 要求其 TLS 会话不被代理触及，实际上使代理成为一个透明的隧道，它只是按原样转发 TCP 连接。因此，您必须使用 TCP 代理。

已知问题

迁移失败并出现错误Upgrade request required

迁移控制器使用 SPDY 协议在远程 Pod 中执行命令。如果远程集群位于不支持 SPDY 协议的代理或防火墙后面，则迁移控制器将无法执行远程命令。迁移将失败并显示错误消息Upgrade request required。解决方法：使用支持 SPDY 协议的代理。

除了支持 SPDY 协议外，代理或防火墙还必须将Upgrade HTTP 标头传递到 API 服务器。客户端使用此标头与 API 服务器打开 websocket 连接。如果Upgrade标头被代理或防火墙阻止，则迁移将失败并显示错误消息Upgrade request required。解决方法：确保代理转发Upgrade标头。

调整迁移的网络策略

OpenShift 支持使用基于集群使用的网络插件的NetworkPolicy或EgressFirewalls来限制进出 Pod 的流量。如果参与迁移的任何源命名空间使用此类机制来限制对 Pod 的网络流量，则这些限制可能会无意中阻止迁移期间对 Rsync Pod 的流量。

在源集群和目标集群上运行的 Rsync Pod 必须通过 OpenShift 路由相互连接。可以配置现有的NetworkPolicy或EgressNetworkPolicy对象以自动将 Rsync Pod 从这些流量限制中豁免。

NetworkPolicy 配置

Rsync Pod 的出站流量

如果源或目标命名空间中的NetworkPolicy配置阻止此类流量，您可以使用 Rsync Pod 的唯一标签来允许其出站流量通过。以下策略允许命名空间中所有 Rsync Pod 的**所有**出站流量。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress-from-rsync-pods
spec:
  podSelector:
    matchLabels:
      owner: directvolumemigration
      app: directvolumemigration-rsync-transfer
  egress:
  - {}
  policyTypes:
  - Egress

Rsync Pod 的入站流量

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress-from-rsync-pods
spec:
  podSelector:
    matchLabels:
      owner: directvolumemigration
      app: directvolumemigration-rsync-transfer
  ingress:
  - {}
  policyTypes:
  - Ingress

EgressNetworkPolicy 配置

EgressNetworkPolicy对象或 *出站防火墙* 是 OpenShift 中设计的用于阻止离开集群的出站流量的构造。

与NetworkPolicy对象不同，出站防火墙在项目级别工作，因为它适用于命名空间中的所有 Pod。因此，Rsync Pod 的唯一标签不会仅使 Rsync Pod 免受限制。但是，您可以将源集群或目标集群的 CIDR 范围添加到策略的 *允许* 规则中，以便在两个集群之间建立直接连接。

根据哪个集群存在出站防火墙，您可以添加另一个集群的 CIDR 范围以允许两个集群之间的出站流量。

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: test-egress-policy
  namespace: <namespace>
spec:
  egress:
  - to:
      cidrSelector: <cidr_of_source_or_target_cluster>
    type: Deny

选择数据传输的替代端点

默认情况下，DVM 使用 OpenShift Container Platform 路由作为端点将 PV 数据传输到目标集群。如果集群拓扑允许，您可以选择另一种类型的受支持端点。

对于每个集群，您可以在您的 MigrationController CR 中设置相应**目标**集群上的rsync_endpoint_type变量来配置端点。

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  rsync_endpoint_type: [NodePort|ClusterIP|Route]

为 Rsync Pod 配置补充组

当您的 PVC 使用共享存储时，您可以通过向 Rsync Pod 定义中添加补充组来配置对该存储的访问，以便 Pod 允许访问。

表 2. Rsync Pod 的补充组
变量	类型	默认值	描述
`src_supplemental_groups`	字符串	未设置	源 Rsync Pod 的补充组的逗号分隔列表
`target_supplemental_groups`	字符串	未设置	目标 Rsync Pod 的补充组的逗号分隔列表

示例用法

可以更新MigrationController CR 以设置这些补充组的值。

spec:
  src_supplemental_groups: "1000,2000"
  target_supplemental_groups: "2000,3000"

配置代理

先决条件

您必须以所有集群上具有cluster-admin权限的用户身份登录。

步骤

获取MigrationController CR 清单。

$ oc get migrationcontroller <migration_controller> -n openshift-migration

更新代理参数。
```
apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: <migration_controller>
  namespace: openshift-migration
...
spec:
  stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> (1)
  noProxy: example.com (2)
```
1 用于直接卷迁移的 Stunnel 代理 URL。

2 要排除代理的目的地域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。

以.为前缀的域仅匹配子域。例如，.y.com匹配x.y.com，但不匹配y.com。使用*绕过所有目的地的代理。如果您扩展安装配置中未包含在networking.machineNetwork[].cidr字段定义的网络中的工作节点，则必须将其添加到此列表中以防止连接问题。

如果未设置httpProxy或httpsProxy字段，则忽略此字段。
将清单保存为migration-controller.yaml。

应用更新的清单。

$ oc replace -f migration-controller.yaml -n openshift-migration

更多信息，请参见配置集群范围的代理。

以 root 或非 root 用户身份运行 Rsync

此部分仅适用于您使用 OpenShift API 而不是 Web 控制台时。

OpenShift 环境默认情况下启用PodSecurityAdmission控制器。此控制器要求集群管理员通过命名空间标签强制执行 Pod 安全标准。集群中的所有工作负载都应运行以下 Pod 安全标准级别之一：Privileged、Baseline或Restricted。每个集群都有其自己的默认策略设置。

为了保证在所有环境中都能成功进行数据传输，MTC 1.7.5 对 Rsync Pod 进行了更改，包括默认情况下以非 root 用户身份运行 Rsync Pod。这确保即使对于不需要更高权限的工作负载，数据传输也是可能的。进行此更改是因为最好以尽可能低的权限级别运行工作负载。

手动覆盖数据传输的默认非 root 操作

虽然以非 root 用户身份运行 Rsync Pod 在大多数情况下都能工作，但在源端以 root 用户身份运行工作负载时，数据传输可能会失败。MTC 提供两种方法来手动覆盖数据传输的默认非 root 操作。

将所有迁移配置为在目标集群上以 root 用户身份运行 Rsync Pod。
每个迁移在目标集群上以 root 用户身份运行 Rsync Pod。

在这两种情况下，您必须在迁移之前在运行具有更高权限的工作负载的任何命名空间的源端设置以下标签：enforce、audit和warn。

要了解有关 Pod 安全准入和设置标签值的更多信息，请参见控制 Pod 安全准入同步。

将 MigrationController CR 配置为所有迁移的 root 或非 root

默认情况下，Rsync 以非 root 身份运行。

在目标集群上，您可以将MigrationController CR 配置为以 root 身份运行 Rsync。

步骤

按如下方式配置MigrationController CR。

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  migration_rsync_privileged: true

此配置将应用于所有未来的迁移。

每个迁移将 MigMigration CR 配置为 root 或非 root

在目标集群上，您可以使用以下非 root 选项将MigMigration CR 配置为以 root 或非 root 身份运行 Rsync。

作为特定用户 ID (UID)
作为特定组 ID (GID)

步骤

要以 root 身份运行 Rsync，请根据此示例配置MigMigration CR。

apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  runAsRoot: true

要以特定用户 ID (UID) 或特定组 ID (GID) 身份运行 Rsync，请根据此示例配置MigMigration CR。

apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  runAsUser: 10010001
  runAsGroup: 3

配置复制存储库

对于受限网络环境，多云对象网关是唯一支持的选项。

MTC 支持文件系统和快照数据复制方法来将数据从源集群迁移到目标集群。您可以选择适合您环境并受您的存储提供商支持的方法。

先决条件

所有集群都必须具有到复制存储库的不间断网络访问。
如果您使用具有内部托管复制存储库的代理服务器，则必须确保代理允许访问复制存储库。

检索多云对象网关凭据

虽然 MCG 运算符已弃用，但 MCG 插件仍可用于 OpenShift Data Foundation。要下载插件，请浏览至下载 Red Hat OpenShift Data Foundation 并下载适合您操作系统的 MCG 插件。

先决条件

您必须使用相应的Red Hat OpenShift Data Foundation 部署指南部署 OpenShift Data Foundation。

其他资源

步骤

Red Hat OpenShift Data Foundation 文档中的断开连接的环境。
MTC 工作流程
关于数据复制方法
向 MTC Web 控制台添加复制仓库

卸载 MTC 并删除资源

您可以卸载容器迁移工具包 (MTC) 并删除其资源以清理集群。

删除velero CRD 会从集群中删除 Velero。

先决条件

您必须以具有cluster-admin权限的用户身份登录。

步骤

删除所有集群上的MigrationController自定义资源 (CR)
```
$ oc delete migrationcontroller <migration_controller>
```
使用 Operator Lifecycle Manager 在 OpenShift Container Platform 4 上卸载容器迁移工具包操作符。

通过运行以下命令删除所有集群上的集群范围资源

migration 自定义资源定义 (CRD)

$ oc delete $(oc get crds -o name | grep 'migration.openshift.io')

velero CRD

$ oc delete $(oc get crds -o name | grep 'velero')

migration 集群角色

$ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')

migration-operator 集群角色

$ oc delete clusterrole migration-operator

velero 集群角色

$ oc delete $(oc get clusterroles -o name | grep 'velero')

migration 集群角色绑定

$ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')

migration-operator 集群角色绑定

$ oc delete clusterrolebindings migration-operator

velero 集群角色绑定

$ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

1	用于直接卷迁移的 Stunnel 代理 URL。
2	要排除代理的目的地域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。

在受限网络环境中安装容器迁移工具包

兼容性指南

在 OpenShift Container Platform 4.17 上安装容器迁移工具操作符

在 OpenShift Container Platform 4.2 到 4.5 上安装旧版容器迁移工具操作符

代理配置

直接卷迁移

DVM 的 TCP 代理设置

为什么使用 TCP 代理而不是 HTTP/HTTPS 代理？

已知问题

调整迁移的网络策略

NetworkPolicy 配置

Rsync Pod 的出站流量

Rsync Pod 的入站流量

EgressNetworkPolicy 配置

选择数据传输的替代端点

为 Rsync Pod 配置补充组

配置代理

以 root 或非 root 用户身份运行 Rsync

手动覆盖数据传输的默认非 root 操作

将 MigrationController CR 配置为所有迁移的 root 或非 root

每个迁移将 MigMigration CR 配置为 root 或非 root

配置复制存储库

先决条件

检索多云对象网关凭据

其他资源

卸载 MTC 并删除资源