容器迁移工具套件(MTC)

OpenShift Container Platform 4.5

迁移到 OpenShift Container Platform 4

Red Hat OpenShift Documentation Team

摘要

本文档提供了有关将 OpenShift Container Platform 集群从版本 3 迁移到版本 4 的信息,以及将较早的 OpenShift Container Platform 4 版本迁移到最新版本的信息。

第 1 章 从 OpenShift Container Platform 3 进行迁移

1.1. 关于将 OpenShift Container Platform 3 迁移到 4

OpenShift Container Platform 4 包含新的技术和功能,这些技术和功能可使集群具有自我管理、灵活性和自动化的特性。OpenShift Container Platform 4 集群部署和管理的方式与 OpenShift Container Platform 3 有很大不同。

要成功从 OpenShift Container Platform 3 转换到 OpenShift Container Platform 4,您必须检查以下信息:

规划系统迁移
了解 OpenShift Container Platform 版本 3 和 4 之间的不同。在迁移前,请确定您已对存储、网络、日志记录、安全及监控等方面进行了规划。
执行迁移
了解并使用 MTC 来迁移应用程序工作负载。

1.2. 规划迁移

在把系统迁移到 OpenShift Container Platform 4.5 前,需要花时间来正确地规划整个转换过程。OpenShift Container Platform 4 引入了与架构相关的更改和增强,因此您用来管理 OpenShift Container Platform 3 集群的操作可能不适用于 OpenShift Container Platform 4。

注意

本计划文档假定您要从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.5。

本文档提供了有关 OpenShift Container Platform 3 和 OpenShift Container Platform 4 之间重要的区别,以及在迁移时需要注意的重要迁移注意事项。有关配置 OpenShift Container Platform 4 集群的详细信息,请查阅 OpenShift Container Platform 文档的适当章节。如需了解有关新功能和其他显著技术更改的详细信息,请参阅 OpenShift Container Platform 4.5 发行注记

无法将现有 OpenShift Container Platform 3 集群升级到 OpenShift Container Platform 4。您必须开始新的 OpenShift Container Platform 4 安装。然后使用提供的工具来帮助迁移 control plane 设置和应用程序工作负载。

1.2.1. OpenShift Container Platform 3 和 OpenShift Container Platform 4 的比较

在 OpenShift Container Platform 3 中,管理员单独部署 Red Hat Enterprise Linux (RHEL) 主机,然后在这些主机之上安装 OpenShift Container Platform 来组成集群。管理员负责正确配置这些主机并执行更新。

在 OpenShift Container Platform 4 中,OpenShift Container Platform 集群的部署和管理方式有了显著变化。OpenShift Container Platform 4 包括新的技术和功能,如 Operators 、机器集和 Red Hat Enterprise Linux CoreOS (RHCOS) ,它们是集群操作的核心。这个技术转换使集群能够自我管理以前需要由管理员执行的一些功能。这也确保平台的稳定性和一致性,并简化了安装和扩展。

如需更多信息,请参阅 OpenShift Container Platform 架构

1.2.1.1. 架构的不同

不可变基础架构

OpenShift Container Platform 4 使用 Red Hat Enterprise Linux CoreOS (RHCOS) ,它旨在运行容器化应用程序,并提供有效的安装、基于 Operator 的管理以及简化的升级。RHCOS 是不可变容器主机,而不是类似 RHEL 的可定制操作系统。RHCOS 使 OpenShift Container Platform 4 能够管理和自动化底层容器主机的部署。RHCOS 是 OpenShift Container Platform 的一部分,这意味着所有版本都在容器中运行,并且都使用 OpenShift Container Platform 部署。

在 OpenShift Container Platform 4 中,control plane 节点必须运行 RHCOS,以确保为 control plane 维护全堆栈的自动化。这使得更新和升级的过程比在 OpenShift Container Platform 3 中要容易。

如需更多信息,请参阅 Red Hat Enterprise Linux CoreOS(RHCOS)

Operator

Operator 是一种打包、部署和管理 Kubernetes 应用程序的方法。Operator 可简化运行另一部分软件的操作复杂性。它们会关检测您的环境,并使用当前状态实时做出决定。高级 Operator 旨在自动升级并对失败做出适当的响应。

如需更多信息,请参阅了解 Operators

1.2.1.2. 安装和更新的不同

安装过程

对于安装 OpenShift Container Platform 3.11,需要准备 Red Hat Enterprise Linux (RHEL) 主机,设置集群所需的所有配置值,然后运行 Ansible playbook 来安装和设置集群。

对于 OpenShift Container Platform 4.5,需要使用 OpenShift 安装程序创建集群所需的最小资源集合。集群运行后,您可以使用 Operator 来进一步配置集群并安装新服务。首次启动后,RHCOS 系统由 OpenShift Container Platform 集群中运行的 Machine Config Operator (MCO) 进行管理。

如需更多信息,请参阅安装过程

如果要将 Red Hat Enterprise Linux(RHEL)worker 机器添加到 OpenShift Container Platform 4.5 集群,您可以使用 Ansible playbook 在集群运行后加入 RHEL worker 机器。如需更多信息,请参阅在 OpenShift Container Platform 集群中添加 RHEL 计算机器

基础架构选项

对于 OpenShift Container Platform 3.11,需要在自己准备好的且被自己维护的基础架构上安装集群。对于 OpenShift Container Platform 4,除了可以在您自己提供的基础架构上安装集群外, 还提供了一个在 OpenShift Container Platform 安装程序置备和集群维护的基础架构上部署集群的选项。

如需更多信息,请参阅 OpenShift Container Platform 安装概述

升级集群

在 OpenShift Container Platform 3.11 中,您可以运行 Ansible playbook 来升级集群。在 OpenShift Container Platform 4.5 中,集群管理自己的更新,包括集群节点上的 Red Hat Enterprise Linux CoreOS (RHCOS) 的更新。您可以使用 Web 控制台或使用 OpenShift CLI 的 oc adm upgrade 命令轻松升级集群,Operator 会自动升级其自身。如果您的 OpenShift Container Platform 4.5 集群有 RHEL worker 机器,那么您仍需要运行 Ansible playbook 来升级这些 worker 机器。

如需更多信息,请参阅更新集群

1.2.2. 迁移考虑

查看可能会影响 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4 的更改和其他注意事项。

1.2.2.1. 存储注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.5 时,请考虑以下与存储相关的变化。

本地卷持久性存储

只有在 OpenShift Container Platform 4.5 中使用 Local Storage Operator 才支持本地存储。不支持使用 OpenShift Container Platform 3.11 的 local provisioner 方法。

如需更多信息,请参阅使用本地卷的持久性存储

FlexVolume 持久性存储

FlexVolume 插件位置已与 OpenShift Container Platform 3.11 中的不同。它在 OpenShift Container Platform 4.5 中的新位置为 /etc/kubernetes/kubelet-plugins/volume/exec。不再支持可附加的 FlexVolume 插件。

如需更多信息,请参阅使用 FlexVolume 的持久性存储

使用容器存储接口 (CSI) 的持久性存储

使用 Container Storage Interface (CSI) 的持久性存储在 OpenShift Container Platform 3.11 中是一个技术预览功能 。OpenShift Container Platform 4.5 完全支持 CSI 版本 1.1.0,但不附带任何 CSI 驱动程序。您必须安装自己的驱动程序。

如需更多信息,请参阅使用容器存储接口 (CSI) 的持久性存储

OpenShift Container Storage

Red Hat OpenShift Container Storage 3 可以与 OpenShift Container Platform 3.11 一起使用,使用 Red Hat Gluster Storage 作为后端存储。

Red Hat OpenShift Container Storage 4 可以与 OpenShift Container Platform 4 一起使用,使用 Red Hat Ceph Storage 作为后备存储。

如需更多信息,请参阅使用 Red Hat OpenShift Container Storage 做为持久性存储系统互操作性文档 。

可用的持久性存储选项

OpenShift Container Platform 4.5 中更改了对 OpenShift Container Platform 3.11 的以下持久性存储选项的支持:

  • GlusterFS 不再被支持。
  • CephFS 作为独立产品不再被支持。
  • Ceph RBD 作为独立产品不再被支持。

如果您在 OpenShift Container Platform 3.11 中使用了其中之一,则需要选择不同的持久性存储选项以便在 OpenShift Container Platform 4.5 中获得全面支持。

如需更多信息,请参阅了解持久性存储

1.2.2.2. 网络注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.5 时,请考虑以下与网络相关的变化。

网络隔离模式

虽然用户经常切换为使用 ovn-multitenant,但是 OpenShift Container Platform 3.11 的默认网络隔离模式是 ovs-subnet。OpenShift Container Platform 4.5 的默认网络隔离模式由网络策略控制。

如果您的 OpenShift Container Platform 3.11 集群使用了 ovs-subnetovs-multitenant 模式,则建议在 OpenShift Container Platform 4.5 集群中使用网络策略。网络策略由上游社区支持,它更灵活并提供 ovs-multitenant 的功能。如果您要在 OpenShift Container Platform 4.5 中使用网络策略时仍然希望维持 ovs-multitenant 的行为,请按照以下步骤使用网络策略配置多租户隔离

如需更多信息,请参阅关于网络策略

加密主机间的网络数据

在 OpenShift Container Platform 3.11 中,您可以使用 IPsec 来加密主机间的网络流量。OpenShift Container Platform 4.5 不支持 IPsec。建议使用 Red Hat OpenShift Service Mesh 在服务间启用 mutual TLS。

如需更多信息,请参阅 了解 Red Hat OpenShift Service Mesh

1.2.2.3. 日志记录注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.5 时,请考虑以下与日志相关的变化。

部署集群日志记录

OpenShift Container Platform 4 通过使用集群日志记录自定义资源,为集群日志记录提供了一个简单的部署机制。

如需更多信息,请参阅安装集群日志记录

聚合日志数据

您无法将 OpenShift Container Platform 3.11 的聚合日志记录数据转换到新的 OpenShift Container Platform 4 集群中。

如需更多信息,请参阅关于集群日志记录

不支持的日志配置

OpenShift Container Platform 4.5 不再支持 OpenShift Container Platform 3.11 中的一些日志记录配置。

有关明确不支持的日志问题单的更多信息,请参阅 维护及支持

1.2.2.4. 安全考虑

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.5 时,请考虑以下与安全相关的变化。

对发现端点的未验证访问

在 OpenShift Container Platform 3.11 中,未经身份验证的用户可以访问发现端点(例如: /api/*/apis/*)。为了安全起见,OpenShift Container Platform 4.5 不再允许对发现端点进行未经身份验证的访问。如果确实需要允许未经身份验证的访问,可根据需要配置 RBAC 设置,但请务必考虑安全性影响,因为这可能会使内部集群组件暴露给外部网络。

用户身份供应商

为 OpenShift Container Platform 4 配置身份供应商包括以下显著的更改:

  • OpenShift Container Platform 4.5 中的请求标头身份供应商需要 mutual TLS,而这在 OpenShift Container Platform 3.11 中不需要。
  • OpenShift Container Platform 4.5 中简化了 OpenID Connect 身份供应商的配置。现在,它从供应商的 /.well-known/OpenID-configuration 端点获取数据。而之前需要在 OpenShift Container Platform 3.11 中指定。

如需更多信息,请参阅了解身份供应商配置

1.2.2.5. 监控注意事项

在从 OpenShift Container Platform 3.11 转换到 OpenShift Container Platform 4.5 时,请考虑以下与监控相关的变化。

监控基础架构可用性的警报

OpenShift Container Platform 3.11 中,触发的确保监控结构可用的默认警报称为 DeadMansSwitch 。在 OpenShift Container Platform 4 中,它被重新命名为 Watchdog 。如果您在 OpenShift Container Platform 3.11 中使用带有此警报设置的 PagerDuty 集成,则需要在 OpenShift Container Platform 4 中使用带有 Watchdog 警报设置的 PagerDuty 集成。

如需更多信息,请参阅应用自定义 Alertmanager 配置

1.3. 迁移工具和先决条件

您可以使用 MTC 将应用程序工作负载从 OpenShift Container Platform 3.7、3.9、3.10 和 3.11 迁移到 OpenShift Container Platform 4.5。MTC 可让您控制迁移的过程,并最小化应用程序停机时间。

MTC web 控制台和 API 基于 Kubernetes 自定义资源,您可以按照命名空间迁移有状态应用程序工作负载。

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

您可以在迁移期间的特定点使用迁移 hook 运行 Ansible playbook。您在创建迁移计划时可以添加 hook。

注意

OpenShift Container Platform 4 中已弃用服务目录。您可以将服务目录置备的工作负载资源从 OpenShift Container Platform 3 迁移到 4,但无法在迁移后在这些工作负载上执行服务目录操作,如 provisiondeprovisionupdate

如果无法迁移服务目录资源,MTC web 控制台会显示一条消息。

重要

在开始迁移前,请 查看规划迁移的信息。

1.3.1. 容器迁移工具(Migration Toolkit for Containers)工作流

您可以使用 MTC(Migration Toolkit for Containers) web 控制台或 Kubernetes API 将 OpenShift Container Platform 源集群中的 Kubernetes 资源、持久性卷数据和内部容器镜像迁移到 OpenShift Container Platform 4.5 目标集群。

(MTC)迁移以下资源:

  • 在迁移计划中指定的命名空间。
  • 命名空间范围的资源:当 MTC 迁移命名空间时,它会迁移与该命名空间关联的所有对象和资源,如服务或 Pod。另外,如果一个资源在命名空间中存在但不在集群级别,这个资源依赖于集群级别存在的另外一个资源,MTC 会迁移这两个资源。

    例如,安全性上下文约束(SCC)是一个存在于集群级别的资源,服务帐户(SA)是存在于命名空间级别的资源。如果 MTC 迁移的命名空间中存在 SA,MTC 会自动找到链接到 SA 的所有 SCC,并迁移这些 SCC。同样,MTC 会迁移链接到命名空间持久性卷的持久性卷声明。

  • 自定义资源(CR)和自定义资源定义(CRD): MTC 会自动迁移任何在命名空间级别存在的 CR,以及链接到这些 CR 的 CRD。

使用 MTC Web 控制台迁移应用程序涉及以下步骤:

  1. 在所有集群中安装 MTC Operator。

    您可以在有限的或没有互联网访问的受限环境中为 Containers Operator 安装 Migration Toolkit。源和目标集群必须可以在相互间进行访问,而需要可以访问 registry 的镜像(mirror).

  2. 配置复制存储库,这是 MTC 用来迁移数据的中间对象存储。

    源和目标集群必须有对复制仓库的不受限制的网络访问权限。在受限环境中,您可以使用内部托管的 S3 存储存储库。如果使用代理服务器,您必须将其配置为允许复制仓库和集群间的网络流量。

  3. 在 MTC web 控制台中添加源集群。
  4. 在 MTC web 控制台中添加复制存储库。
  5. 创建迁移计划,包含以下数据迁移选项之一:

    • Copy:MTC 将数据从源集群复制到复制存储库,再从复制存储库把数据复制到目标集群。

      注意

      如果您使用直接镜像迁移或直接卷迁移,则镜像或卷会直接从源集群复制到目标集群。

      迁移 PV 复制
    • Move:MTC 从源集群中卸载一个远程卷(例如 NFS),在目标集群上创建一个指向这个远程卷的 PV 资源,然后在目标集群中挂载远程卷。在目标集群中运行的应用程序使用源集群使用的同一远程卷。远程卷必须可以被源集群和目标集群访问。

      注意

      虽然复制仓库没有出现在此图表中,但迁移需要它。

      迁移 PV 移动
  6. 运行迁移计划,使用以下选项之一:

    • Stage (可选)在不停止应用程序的情况下将数据复制到目标集群。

      Stage 可以多次运行,以便在迁移前将大多数数据复制到目标。这可最小化迁移和应用程序停机时间。

    • Migrate 在源集群中停止应用程序,并在目标集群中重新创建其资源。您可以选择在不停止应用程序的情况下迁移工作负载。
OCP 3 到 4 的应用程序迁移

1.3.2. 容器自定义资源迁移工具

MTC 会创建以下自定义资源(CR):

migration architecture diagram

20 MigCluster (配置, MTC 集群): 集群定义

20 MigStorage (配置, MTC 集群): Storage 定义

20 MigPlan (配置, MTC 集群):迁移计划

MigPlan CR 描述了要迁移的源和目标集群、复制仓库和命名空间。它与 0 个、1 个或多个 MigMigration CR 关联。

注意

删除 MigPlan CR 会删除关联的 MigMigration CR。

20 BackupStorageLocation (配置, MTC 集群): Velero 备份对象的位置

20 VolumeSnapshotLocation (配置, MTC 集群): Velero 卷快照的位置

20 MigMigration (操作,MTC 集群)::迁移,在每次进行 stage 或迁移数据时创建。每个 MigMigration CR 都与 MigPlan CR 关联。

20 Backup(操作,源集群):当运行迁移计划时,MigMigration CR 在每个源集群上创建两个 Velero 备份 CR:

  • 备份 CR #1 用于Kubernetes 对象
  • 备份 CR #2 用于 PV 数据

20 Restore (操作,目标集群):在运行迁移计划时,MigMigration CR 在目标集群上创建两个 Velero 恢复 CR:

  • 恢复 CR #1(使用备份 CR #2)用于 PV 数据
  • 恢复 CR #2(使用备份 CR #1)用于 Kubernetes 对象

1.3.3. 关于数据复制方法

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

1.3.3.1. 文件系统复制方法

MTC 工具将数据文件从源集群复制到复制存储库,并从那里复制到目标集群。

表 1.1. 文件系统复制方法概述

优点限制:
  • 集群可以有不同的存储类
  • 所有 S3 存储供应商均支持
  • 使用 checksum 验证数据(可选)
  • 比快照复制方法慢
  • 可选的数据校验可能会显著降低性能

1.3.3.2. 快照复制方法

MTC 将源集群数据的快照复制到云供应商的复制仓库。数据在目标集群上恢复。

AWS、Google Cloud Provider 和 Microsoft Azure 支持快照复制方法。

表 1.2. 快照复制方法概述

优点限制:
  • 比文件系统复制方法快
  • 云供应商必须支持快照。
  • 集群必须位于相同的云供应商。
  • 集群必须位于同一位置或区域。
  • 集群必须具有相同的存储类。
  • 存储类必须与快照兼容。

1.3.4. 关于迁移 hook

在使用 MTC 进行迁移的特定时间点上,可以使用迁移 hook 运行自定义代码。您可以在单个迁移计划中添加最多四个迁移 hook,每个 hook 在迁移过程的不同阶段运行。

迁移 hook 执行的任务包括自定义应用程序默认、手动迁移不受支持的数据类型以及在迁移后更新应用程序。

迁移 hook 会在以下迁移步骤之一中,在源或目标集群上运行:

  • PreBackup:在源集群中备份资源前
  • PostBackup:在源集群中备份资源后
  • PreRestore:在目标集群上恢复资源前
  • PostRestore:在目标集群中恢复资源后

您可以使用 Ansible playbook 或自定义 hook 容器创建 hook。

Ansible playbook

Ansible playbook 作为一个配置映射挂载到 hook 容器上。hook 容器使用 MigPlan 自定义资源(CR)中指定的集群、服务帐户和命名空间以作业的形式运行。作业会继续运行,直到达到默认限制的 6 次重试或成功完成为止。即使初始 pod 被驱除或终止,也会继续。

默认 Ansible 运行时镜像为 registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.4。此镜像基于 Ansible Runner 镜像,并包含 Ansible Kubernetes 资源的 python-openshift,以及更新的 oc 二进制文件。

可选: 您可以使用包含其他 Ansible 模块或工具的自定义 Ansible 运行时镜像,而不是默认镜像。

自定义 hook 容器

您可以创建包含 Ansible playbook 或自定义代码的自定义 hook 容器。

1.4. 安装并升级 MTC

您可以在 OpenShift Container Platform 4.5 目标集群和 OpenShift Container Platform 3 源集群中安装 MTC。

Migration Controller pod 默认在目标集群上运行。您可以将 Migration Controller pod 配置为在源集群或远程集群中运行。

1.4.1. 在连接的环境中安装 MTC

您可以在连接的环境中安装 MTC。

重要

您必须在所有集群中安装相同的 MTC 版本。

1.4.1.1. 在 OpenShift Container Platform 4.5 目标集群上安装 MTC

您可以在 OpenShift Container Platform 4.5 目标集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 点击 Create
  8. WorkloadsPods 来验证 MTC pod 正在运行 。

1.4.1.2. 在 OpenShift Container Platform 3 源集群中安装 MTC

您可以在 OpenShift Container Platform 3 源集群中手动安装 MTC。

重要

您必须在 OpenShift Container Platform 3 和 4 集群上安装相同的 MTC 版本。

要确保 OpenShift Container Platform 3 集群上有最新的版本,请在准备好创建并运行迁移计划时下载 operator.ymlcontroller-3.yml 文件。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须有权访问 registry.redhat.io
  • 必须安装 podman
  • 源集群必须是 OpenShift Container Platform 3.7 、3.9 、3.10 或 3.11。
  • 必须将源集群配置为从 registry.redhat.io 中拉取镜像。

    要拉取镜像,您必须创建一个镜像流 secret,并将其复制到集群中的每个节点。

流程

  1. 使用您的红帽客户门户网站账户登陆到 registry.redhat.io

    $ sudo podman login registry.redhat.io
  2. 下载 operator.yml 文件:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./
  3. 下载 controller-3.yml 文件:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./
  4. 登录您的 OpenShift Container Platform 3 集群。
  5. 验证集群可以在 registry.redhat.io 中进行身份验证:

    $ oc run test --image registry.redhat.io/ubi8 --command sleep infinity
  6. 创建 MTC Operator 对象的 Migration Toolkit:

    $ 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) 信息。它们是由 MTC Operator 为早期版本的 OpenShift Container Platform 3 创建资源造成的,这些资源在以后的版本中已提供。
  7. 创建 MigrationController 对象:

    $ oc create -f controller-3.yml
  8. 验证 VeleroRestic pod 是否正在运行:

    $ oc get pods -n openshift-migration

1.4.2. 在受限环境中安装 MTC

您可以在受限环境中安装 MTC。

重要

您必须在所有集群中安装相同的 MTC 版本。

您可以为 OpenShift Container Platform 4 构建自定义 Operator 目录镜像,将其推送到本地镜像 registry,并将 Operator Lifecycle Manager(OLM)配置为从本地 registry 安装 Containers Operator 的 Migration Toolkit for Containers Operator。

1.4.2.1. 构建 Operator 目录镜像

集群管理员可以根据 Operator Lifecycle Manager(OLM)使用的 Package Manifest Format 来构建自定义 Operator 目录镜像。目录镜像可推送到支持 Docker v2-2 的容器镜像 registry。对于受限网络中的集群,此 registry 可以是集群有网络访问权限的 registry,如在受限网络集群安装过程中创建的镜像 registry。

重要

OpenShift Container Platform 集群的内部 registry 不能用作目标 registry,因为它不支持没有标签的推送(在镜像过程中需要这个功能)。

在这一示例中,流程假定在使用镜像 registry 时可访问您的网络以及互联网。

注意

只有 oc 客户端的 Linux 版本可用于此流程,因为 Windows 和 macOS 版本不提供 oc adm catalog build 命令。

先决条件

  • 没有网络访问限制的工作站
  • oc 版本 4.3.5+ Linux 客户端
  • podman 1.4.4+ 版
  • 访问支持 Docker v2-2 的镜像(mirror)registry
  • 如果您正在使用私有 registry,请将 REG_CREDS 环境变量设置为到 registry 凭证的文件路径。例如,对于 podman CLI:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • 如果您正在使用 quay.io 帐户可访问的私有命名空间,您必须设置 Quay 身份验证令牌。使用您的 quay.io 凭证对登录 API 发出请求,从而设置用于 --auth-token 标志的 AUTH_TOKEN 环境变量:

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

流程

  1. 在没有网络访问限制的工作站中,与目标镜像(mirror) registry 进行身份验证:

    $ podman login <registry_host_name>

    还可使用 registry.redhat.io 验证,以便在构建期间拉取基础镜像:

    $ podman login registry.redhat.io
  2. 根据 Quay.io 中的 redhat-operators 目录构建目录镜像,进行标记并将其推送到您的镜像 registry:

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    从 App Registry 实例中拉取的机构(命名空间)。
    2
    使用与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签,将 --from 设置为 ose-operator-registry 基础镜像。
    3
    --filter-by-os 设置为用于基本镜像的操作系统和架构,该镜像必须与目标 OpenShift Container Platform 集群匹配。有效值是 linux/amd64linux/ppc64lelinux/s390x
    4
    为您的目录镜像命名并包含标签,例如: v1
    5
    可选:如果需要,指定 registry 凭证文件的位置。
    6
    可选:如果您不想为目标 registry 配置信任,请添加 --insecure 标志。
    7
    可选:如果使用其他不公开的应用程序 registry 目录,则需要指定 Quay 身份验证令牌。

    输出示例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

    有时红帽提供的无效清单是意外引入的目录 ; 当发生这种情况时,您可能会看到一些错误:

    出错的输出示例

    ...
    INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
    W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
    Uploading ... 244.9kB/s

    这些错误通常不是致命的,如果所提及 Operator 软件包不包含您计划安装的 Operator 或其依赖项,则可以忽略它们。

1.4.2.2. 针对受限网络配置 OperatorHub

集群管理员可以使用自定义 Operator 目录镜像将 OLM 和 OperatorHub 配置为在受限网络环境中使用本地内容。本例中的流程使用之前构建并推送到受支持的 registry 的自定义 redhat-operators 目录镜像。

先决条件

  • 没有网络访问限制的工作站
  • 推送到受支持的 registry 的自定义 Operator 目录镜像
  • oc 版本 4.3.5+
  • podman 1.4.4+ 版
  • 访问支持 Docker v2-2 的镜像(mirror)registry
  • 如果您正在使用私有 registry,请将 REG_CREDS 环境变量设置为到 registry 凭证的文件路径。例如,对于 podman CLI:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

流程

  1. oc adm catalog mirror 命令提取自定义 Operator catalog 镜像的内容,以生成镜像(mirror)所需的清单:您可以选择:

    • 允许该命令的默认行为在生成清单后自动将所有镜像内容镜像到您的镜像 registry 中,或者
    • 添加 --manifests-only 标志来只生成镜像所需的清单,但并不实际将镜像内容镜像到 registry。这对检查哪些要镜像(mirror)非常有用。如果您只需要部分内容的话,可以对映射列表做出任何修改。然后,您可以使用该文件与 oc image mirror 命令一起,在以后的步骤中镜像修改的镜像列表。

    在没有网络访问限制的工作站中,运行以下命令:

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v1 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' \4
        [--manifests-only] 5
    1
    指定 Operator 目录镜像。
    2
    可选:如果需要,指定 registry 凭证文件的位置。
    3
    可选:如果您不想为目标 registry 配置信任,请添加 --insecure 标志。
    4
    由于对多个构架支持的已知问题,当前需要此标志。
    5
    可选:只生成镜像所需的清单,但并不实际将镜像内容镜像到 registry。
    警告

    如果未设置 --filter-by-os 标志或设置为 .* 以外的任何值,该命令会过滤不同的架构,用来更改清单列表摘要,也称为 多架构镜像。不正确的摘要会导致在断开连接的集群中部署这些镜像和 Operator 失败。如需更多信息,请参阅 BZ#1890951

    输出示例

    using database path mapping: /:/tmp/190214037
    wrote database to /tmp/190214037
    using database at: /tmp/190214037/bundles.db 1
    ...

    1
    命令生成的临时数据库。

    在运行命令后,会在当前目录中生成 <image_name>-manifests/ 目录以及以下文件:

    • 用来定义 ImageContentSourcePolicy 对象的 imageContentSourcePolicy.yaml,它可以将节点配置为在 Operator 清单中存储的镜像(image)引用和镜像 (mirror) 的 registry 间进行转换。
    • mapping.txt 文件,在其中包含所有源镜像,并将它们映射到目标 registry。此文件与 oc image mirror 命令兼容,可用于进一步自定义镜像(mirror)配置。
  2. 如果您在上一步中使用 --manifests-only 标志,并只想镜像部分内容:

    1. mapping.txt 文件中的镜像列表改为您的规格。如果您不确定要镜像的镜像子集的名称和版本,请使用以下步骤查找:

      1. oc adm catalog mirror 命令生成的临时数据库运行 sqlite3 工具,以检索与一般搜索查询匹配的镜像列表。输出以后如何编辑 mapping.txt 文件的帮助信息。

        例如,要检索与字符串 clusterlogging.4.3 类似的镜像列表:

        $ echo "select * from related_image \
            where operatorbundle_name like 'clusterlogging.4.3%';" \
            | sqlite3 -line /tmp/190214037/bundles.db 1
        1
        请参阅 oc adm catalog mirror 命令的输出结果来查找数据库文件的路径。

        输出示例

        image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        
        image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        ...

      2. 使用上一步的结果来编辑 mapping.txt 文件,使其只包含您要镜像的镜像子集。

        例如,您可以使用前面示例输出中的 image 值来找出您的 mapping.txt 文件中存在以下匹配行:

        mapping.txt 中的匹配镜像映射

        registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

        在这个示例中,如果您只想镜像这些 image,可以在 mapping.txt 文件中删除所有其他条目,仅保留上述两行。

    2. 在您的没有网络访问限制的工作站中,使用您修改的 mapping.txt 文件,使用 oc image mirror 命令将镜像镜像到 registry:

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt
      警告

      如果未设置 --filter-by-os 标志或设置为 .* 以外的任何值,该命令会过滤不同的架构,用来更改清单列表摘要,也称为 多架构镜像。不正确的摘要会导致在断开连接的集群中部署这些镜像和 Operator 失败。

  3. 应用 ImageContentSourcePolicy 对象:

    $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml
  4. 创建一个 CatalogSource 对象来引用您的目录镜像。

    1. 按照您的规格修改以下内容,并将它保存为 catalogsource.yaml 文件:

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc
      1
      指定您的自定义 Operator 目录镜像。
    2. 使用该文件创建 CatalogSource 对象:

      $ oc create -f catalogsource.yaml
  5. 确定成功创建以下资源。

    1. 检查 pod:

      $ oc get pods -n openshift-marketplace

      输出示例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 检查目录源:

      $ oc get catalogsource -n openshift-marketplace

      输出示例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 检查软件包清单:

      $ oc get packagemanifest -n openshift-marketplace

      输出示例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

现在,您可在受限网络 OpenShift Container Platform 集群的 web 控制台中,通过 OperatorHub 安装 Operator。

1.4.2.3. 在一个受限的环境中的 OpenShift Container Platform 4.5 目标集群上安装 MTC

您可以在 OpenShift Container Platform 4.5 目标集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须创建自定义 Operator 目录并将其推送到镜像 registry。
  • 您必须将 Operator Lifecycle Manager 配置为从镜像 registry 安装 MTC Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 点击 Create
  8. WorkloadsPods 来验证 MTC pod 正在运行 。

1.4.2.4. 在一个受限的环境中的 OpenShift Container Platform 3 源集群上安装 MTC

您可以基于 Migration Toolkit for Containers(MTC)Operator 镜像创建清单文件,并编辑清单以指向本地镜像 registry。然后,您可以使用本地镜像在 OpenShift Container Platform 3 源集群中为 Containers Operator 创建 Migration Toolkit for Containers Operator。

重要

您必须在 OpenShift Container Platform 3 和 4 集群上安装相同的 MTC 版本。

要确保 OpenShift Container Platform 3 集群上有最新的版本,请在准备好创建并运行迁移计划时下载 operator.ymlcontroller-3.yml 文件。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须有权访问 registry.redhat.io
  • 必须安装 podman
  • 源集群必须是 OpenShift Container Platform 3.7 、3.9 、3.10 或 3.11。
  • 您必须有一个具有无限网络访问权限的 Linux 工作站。
  • 您必须有权访问支持 Docker v2-2 的镜像 registry

流程

  1. 通过一个没有网络访问限制的工作站,使用您的红帽客户门户网站凭证登录 registry.redhat.io:

    $ sudo podman login registry.redhat.io
  2. 下载 operator.yml 文件:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./
  3. 下载 controller-3.yml 文件:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./
  4. 从在 OpenShift Container Platform 4 集群中运行 oc adm catalog mirror 时创建的 mapping.txt 文件获取 Operator 镜像值:

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

    输出显示了 registry.redhat.io 镜像和您的镜像 registry 镜像之间的映射。

    输出示例

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

  5. 更新 Operator 配置文件中的 imageREGISTRY 值:

    containers:
      - name: ansible
        image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
    ...
      - name: operator
        image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
    ...
        env:
        - name: REGISTRY
          value: <registry.apps.example.com> 3
    1
    mapping.txt 文件中指定您的镜像 registry 和 Operator 镜像的 sha256 值。
    2
    mapping.txt 文件中指定您的镜像 registry 和 Operator 镜像的 sha256 值。
    3
    指定您的镜像 registry。
  6. 登录您的 OpenShift Container Platform 3 集群。
  7. 创建 MTC Operator 对象的 Migration Toolkit:

    $ 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) 信息。它们是由 MTC Operator 为早期版本的 OpenShift Container Platform 3 创建资源造成的,这些资源在以后的版本中已提供。
  8. 创建 MigrationController 对象:

    $ oc create -f controller-3.yml
  9. 验证 VeleroRestic pod 是否正在运行:

    $ oc get pods -n openshift-migration

1.4.3. 升级 MTC

您可以使用 OpenShift Container Platform Web 控制台升级 MTC。

重要

您必须确保在所有集群中安装相同的 MTC 版本。

如果要升级 MTC 1.3,您必须执行额外步骤来更新 MigPlan 自定义资源(CR)。

1.4.3.1. 在 OpenShift Container Platform 4 集群中升级 MTC

您可以使用 OpenShift Container Platform Web 控制台在 OpenShift Container Platform 4 集群上升级 MTC。

先决条件

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

流程

  1. 在 OpenShift Container Platform 控制台中导航至 OperatorsInstalled Operators

    处于待定升级的 operator 会显示 Upgrade available 状态。

  2. Migration Toolkit for Containers Operator
  3. Subscription 标签页。任何需要批准的升级都会在 Upgrade Status 旁边显示。例如:它可能会显示 1 requires approval
  4. 1 requires approval,然后点 Preview Install Plan
  5. 查看列出可用于升级的资源,并点 Approve
  6. 返回 Operators → Installed Operators 页面来监控升级的过程。完成后,状态会变为 SucceededUp to date
  7. WorkloadsPods 来验证 MTC pod 正在运行 。

1.4.3.2. 在 OpenShift Container Platform 3 集群中升级 MTC

您可以使用 podman 在 OpenShift Container Platform 3 集群上升级 MTC。

先决条件

  • 您必须以具有 cluster-admin 权限的用户身份登录。
  • 您必须有权访问 registry.redhat.io
  • 必须安装 podman

流程

  1. 使用您的红帽客户门户网站账户登陆到 registry.redhat.io

    $ sudo podman login registry.redhat.io
  2. 下载最新的 operator.yml 文件:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./ 1
    1
    如果需要,可以指定 z-stream 版本。
  3. 替换 MTC Operator:

    $ oc replace --force -f operator.yml
  4. 应用更改:

    • 对于 MTC 1.1.2 及更早的版本,删除 Restic pod:

      $ oc delete pod <restic_pod>
    • 对于 MTC 1.2 及更新的版本:

      1. migration-operator 部署扩展到 0 以停止部署:

        $ oc scale -n openshift-migration --replicas=0 deployment/migration-operator
      2. migration-operator 部署扩展到 1 以启动部署并应用更改:

        $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator
  5. 验证 migration-operator 是否已升级:

    $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'
  6. 下载最新的 controller-3.yml 文件:

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./
  7. 创建 migration-controller 对象:

    $ oc create -f controller-3.yml
  8. 如果您的 OpenShift Container Platform 版本是 3.10 或更早版本,请将 migration-controller 服务帐户的安全上下文约束设置为 anyuid,以启用直接镜像迁移和直接卷迁移:

    $ oc adm policy add-scc-to-user anyuid -z migration-controller -n openshift-migration
  9. 验证 MTC Pod 是否正在运行:

    $ oc get pods -n openshift-migration
  10. 如果您之前已将 OpenShift Container Platform 3 集群添加到 MTC web 控制台,必须在 web 控制台中更新服务帐户令牌,因为升级过程会删除并恢复 openshift-migration 命名空间:

    1. 获取服务帐户令牌:

      $ oc sa get-token migration-controller -n openshift-migration
    2. 在 MTC web 控制台中点 Clusters
    3. 点击集群 kebab 旁边的 Options 菜单并选择 Edit
    4. Service account token 字段中输入新服务帐户令牌
    5. 点击 Update cluster,然后点击 Close

1.4.3.3. 将 MTC 1.3 升级到 1.4

如果要将 MTC 版本 1.3.x 升级到 1.4,您必须更新运行 MigrationController Pod 的集群中的 MigPlan 自定义资源(CR)清单。

由于 MTC 1.3 中不存在 indirectImageMigrationindirectVolumeMigration 参数,它们在 1.4 版中的默认值会为 false,这意味着启用了直接镜像迁移和直接卷迁移。由于没有满足直接迁移要求,迁移计划无法变为 Ready 状态,除非将这些参数值改为 true

先决条件

  • 已安装了 MTC 1.3。
  • 您必须以具有 cluster-admin 权限的用户身份登录。

流程

  1. 登录到运行 MigrationController Pod 的集群。
  2. 获取 MigPlan CR 清单:

    $ oc get migplan <migplan> -o yaml -n openshift-migration
  3. 更新以下参数值,并将文件保存为 migplan.yaml

    ...
    spec:
      indirectImageMigration: true
      indirectVolumeMigration: true
  4. 替换 MigPlan CR 清单以应用更改:

    $ oc replace -f migplan.yaml -n openshift-migration
  5. 获取更新的 MigPlan CR 清单以验证更改:

    $ oc get migplan <migplan> -o yaml -n openshift-migration

1.5. 为复制存储库配置对象存储

您必须将对象存储配置为用作复制存储库。MTC 将数据从源集群复制到复制存储库,然后从复制存储库复制到目标集群。

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

支持以下存储供应商:

在受限环境中,您可以创建一个内部托管的复制存储库。

先决条件

  • 所有集群都必须具有对复制存储库的不间断网络访问权限。
  • 如果您将代理服务器与内部托管的复制存储库搭配使用,您必须确保代理允许访问复制存储库。

1.5.1. 配置 MCG 存储桶做为复制存储库

您可以安装 OpenShift Container Storage Operator,并将一个 Multi-Cloud Object Gateway(MCG)存储桶配置为 Migration Toolkit for Containers(MTC)的复制仓库。

1.5.1.1. 安装 OpenShift Container Storage Operator

您可以从 OperatorHub 安装 OpenShift Container Storage Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword (本例中为 OCS)来查找 OpenShift Container Storage Operator
  3. 选择 OpenShift Container Storage Operator 并点 Install
  4. 选择一个 Update ChannelInstallation ModeApproval Strategy
  5. 点击 Install

    Installed Operators 页面中,OpenShift Container Storage Operator 会出现在 openshift-storage 项目中,状态为 Succeeded

1.5.1.2. 创建 Multi-Cloud Object Gateway 存储桶

您可以创建 Multi-Cloud Object Gateway(MCG)存储桶的自定义资源(CR)。

流程

  1. 登录到 OpenShift Container Platform 集群:

    $ oc login
  2. 使用以下内容创建 NooBaa CR 配置文件,noobaa.yml

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    对于非常小的集群,您可以将 cpu 的值改为 0.1
  3. 创建 NooBaa 对象:

    $ oc create -f noobaa.yml
  4. 使用以下内容创建 BackingStore CR 配置文件,bs.yml

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: mcg-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    指定持久性卷池中的卷数量。
    2
    指定卷的大小。
    3
    指定存储类。
  5. 创建 BackingStore 对象:

    $ oc create -f bs.yml
  6. 使用以下内容创建 BucketClass CR 配置文件,bc.yml

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: mcg-pv-pool-bc
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - mcg-pv-pool-bs
          placement: Spread
  7. 创建 BucketClass 对象:

    $ oc create -f bc.yml
  8. 使用以下内容创建 ObjectBucketClaim CR 配置文件,obc.yml

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    1
    记录在 MTC web 控制台中添加复制存储库的存储桶名称。
  9. 创建 ObjectBucketClaim 对象:

    $ oc create -f obc.yml
  10. 监控资源创建过程以验证 ObjectBucketClaim 的状态变为 Bound

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    这个过程可能需要五到十分钟。

  11. 获取并记录以下值,当您将复制存储库添加到 MTC web 控制台时需要这些值:

    • S3 端点:

      $ oc get route -n openshift-storage s3
    • S3 provider access key:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 provider secret access key:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

1.5.2. 将 AWS S3 存储桶配置为复制存储库

您可以将 AWS S3 存储桶配置为 MTC 的 Migration Toolkit 的复制仓库。

先决条件

  • AWS S3 存储桶必须可以被源和目标集群访问。
  • 您必须安装了 AWS CLI
  • 如果您使用快照复制方法:

    • 您必须有权访问 EC2 Elastic Block Storage (EBS)。
    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 创建 AWS S3 存储桶:

    $ aws s3api create-bucket \
        --bucket <bucket_name> \ 1
        --region <bucket_region> 2
    1
    指定 S3 存储桶名称。
    2
    指定 S3 存储桶区域,例如 us-east-1
  2. 创建 IAM 用户 velero

    $ aws iam create-user --user-name velero
  3. 创建 EC2 EBS 快照策略:

    $ cat > velero-ec2-snapshot-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
  4. 为一个或所有 S3 存储桶创建 AWS S3 访问策略:

    $ cat > velero-s3-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 2
                ]
            }
        ]
    }
    EOF
    1 2
    要授予对单一 S3 存储桶的访问权限,请指定存储桶名称。要授予对所有 AWS S3 存储桶的访问权限,请指定 * 而不是存储桶名称,如下例所示:

    输出示例

    "Resource": [
        "arn:aws:s3:::*"

  5. 将 EC2 EBS 策略附加到 velero

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-ebs \
      --policy-document file://velero-ec2-snapshot-policy.json
  6. 将 AWS S3 策略附加到 velero

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-s3 \
      --policy-document file://velero-s3-policy.json
  7. velero 创建访问密钥:

    $ aws iam create-access-key --user-name velero
    {
      "AccessKey": {
            "UserName": "velero",
            "Status": "Active",
            "CreateDate": "2017-07-31T22:24:41.576Z",
            "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>, 1
            "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
        }
    }
    1 2
    记录 AWS_SECRET_ACCESS_KEYAWS_ACCESS_KEY_ID 以将 AWS 存储库添加到 MTC web 控制台。

1.5.3. 将 Google Cloud Provider 存储桶配置为复制存储库

您可以将 Google Cloud Provider(GCP)存储桶配置为 MTC 的 Migration Toolkit for Containers 复制仓库。

先决条件

  • AWS S3 存储桶必须可以被源和目标集群访问。
  • 您必须安装了 gsutil
  • 如果您使用快照复制方法:

    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 登录到 gsutil:

    $ gsutil init

    输出示例

    Welcome! This command will take you through the configuration of gcloud.
    
    Your current configuration has been set to: [default]
    
    To continue, you must login. Would you like to login (Y/n)?

  2. 设置 BUCKET 变量:

    $ BUCKET=<bucket_name> 1
    1
    指定存储桶名称。
  3. 创建存储桶:

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 变量设置为您的活跃项目:

    $ PROJECT_ID=`gcloud config get-value project`
  5. 创建 velero IAM 服务帐户:

    $ gcloud iam service-accounts create velero \
        --display-name "Velero Storage"
  6. 创建 SERVICE_ACCOUNT_EMAIL 变量:

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
      --filter="displayName:Velero Storage" \
      --format 'value(email)'`
  7. 创建 ROLE_PERMISSIONS 变量:

    $ ROLE_PERMISSIONS=(
        compute.disks.get
        compute.disks.create
        compute.disks.createSnapshot
        compute.snapshots.get
        compute.snapshots.create
        compute.snapshots.useReadOnly
        compute.snapshots.delete
        compute.zones.get
    )
  8. 创建 velero.server 自定义角色:

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  9. 为项目添加 IAM 策略绑定:

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  10. 更新 IAM 服务帐户:

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  11. 将 IAM 服务帐户的密钥保存到当前目录中的 credentials-velero 文件中:

    $ gcloud iam service-accounts keys create credentials-velero \
      --iam-account $SERVICE_ACCOUNT_EMAIL

1.5.4. 将 Microsoft Azure Blob 存储容器配置为复制存储库

您可以将 Microsoft Azure Blob 存储容器配置为 Migration Toolkit for Containers(MTC)的复制仓库。

先决条件

  • 您必须具有 Azure 存储帐户
  • 您必须安装了 Azure CLI
  • Azure Blob 存储容器必须可以被源和目标集群访问。
  • 如果您使用快照复制方法:

    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 设置 AZURE_RESOURCE_GROUP 变量:

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  2. 创建 Azure 资源组:

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    指定位置。
  3. 设置 AZURE_STORAGE_ACCOUNT_ID 变量:

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
  4. 创建 Azure 存储帐户:

    $ az storage account create \
      --name $AZURE_STORAGE_ACCOUNT_ID \
      --resource-group $AZURE_RESOURCE_GROUP \
      --sku Standard_GRS \
      --encryption-services blob \
      --https-only true \
      --kind BlobStorage \
      --access-tier Hot
  5. 设置 BLOB_CONTAINER 变量:

    $ BLOB_CONTAINER=velero
  6. 创建 Azure Blob 存储容器:

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  7. velero 创建服务主体和凭证:

    $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
      AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
      AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" --role "Contributor" --query 'password' -o tsv` \
      AZURE_CLIENT_ID=`az ad sp list --display-name "velero" --query '[0].appId' -o tsv`
  8. credentials-velero 文件中保存服务主体的凭证:

    $ cat << EOF  > ./credentials-velero
    AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
    AZURE_TENANT_ID=${AZURE_TENANT_ID}
    AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
    AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
    AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
    AZURE_CLOUD_NAME=AzurePublicCloud
    EOF

1.6. 迁移应用程序

您可以使用 Migration Toolkit for Containers(MTC)web 控制台或命令行来迁移应用程序。

1.6.1. 先决条件

MTC(Migration Toolkit for Containers)有以下先决条件:

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 在所有集群中,MTC 版本必须相同。
  • 如果应用程序使用 openshift 命名空间中的内部镜像,您必须确保目标集群中存在所需的镜像版本。

    您可以手动更新镜像流标签,以便在 OpenShift Container Platform 4.5 集群中使用已弃用的 OpenShift Container Platform 3 镜像。

  • Clusters:

    • 源集群必须升级到最新的 MTC z-stream 版本。
    • 运行 migration-controller pod 的集群必须具有对其他集群的不受限制的网络访问权限。
    • 集群必须具有相互无限的网络访问权限。
    • 集群必须具有对复制存储库的不受限制的网络访问权限。
    • 集群必须能够使用端口 443 上的 OpenShift 路由进行通信。
    • 集群不能有关键条件。
    • 集群必须处于 ready 状态。
  • 卷迁移:

    • 持久性卷(PV)必须有效。
    • PV 必须绑定到持久性卷声明。
    • 如果使用 move 方法复制 PV,集群必须具有对远程卷的不受限制的网络访问权限。
    • 如果使用快照复制方法复制 PV,则适用以下先决条件:

      • 云供应商必须支持快照。
      • 卷必须具有相同的云供应商。
      • 卷必须位于同一区域。
      • 卷必须具有相同的存储类。
  • 如果在代理环境中执行直接卷迁移,您必须配置 Stunnel TCP 代理。
  • 如果执行直接镜像迁移,您必须将源集群的内部 registry 公开给外部流量。

1.6.1.1. 使用 podman 更新已弃用的内部镜像

如果应用程序使用 openshift 命名空间中的镜像,则目标集群中必须有所需的镜像版本。

如果 OpenShift Container Platform 4.5 中已弃用 OpenShift Container Platform 3 镜像,您可以使用 podman 手动更新镜像流标签。

先决条件

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

流程

  1. 在源和目标集群上公开内部 registry。
  2. 如果您使用不安全的 registry,请将 registry 主机值添加到 /etc/container/registries.conf[registries.insecure] 部分,以确保 Podman 不会遇到 TLS 验证错误。
  3. 登录到源集群 registry:

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <source_cluster>
  4. 登录到目标集群 registry:

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <target_cluster>
  5. 拉取已弃用的镜像:

    $ podman pull <source_cluster>/openshift/<image>
  6. 为目标集群 registry 标记镜像:

    $ podman tag <source_cluster>/openshift/<image> <target_cluster>/openshift/<image>
  7. 将镜像推送到目标集群 4 registry:

    $ podman push <target_cluster>/openshift/<image>
  8. 验证镜像在目标集群中是否有有效的镜像流:

    $ oc get imagestream -n openshift | grep <image>

    输出示例

    <image>    <target_cluster>/openshift/<image>     <versions>
    more...      6 seconds ago

1.6.1.2. 创建 CA 证书捆绑包文件

如果您使用自签名证书来保护集群或 MTC 的 Migration Toolkit 的复制仓库的安全,则证书验证可能会失败,并显示以下错误消息: Certificate signed by unknown authority

您可以创建自定义 CA 证书捆绑包文件,并在添加集群或复制存储库时将其上传到 MTC web 控制台。

流程

从远程端点下载 CA 证书,并将其保存为 CA 捆绑包文件:

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
1
指定端点的主机 FQDN 和端口,如 api.my-cluster.example.com:6443
2
指定 CA 捆绑包文件的名称。

1.6.1.3. 为直接卷迁移配置代理

如果要从代理后面的源集群执行直接卷迁移,您必须在 MigrationController 自定义资源(CR)中配置 Stunnel 代理。stunnel 在源和目标集群之间为 TCP 连接创建透明的隧道,而不更改证书。

注意

直接卷迁移只支持一个代理。如果目标集群也位于代理后面,则源集群无法访问目标集群的路由。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 登录到运行 MigrationController Pod 的集群。
  2. 获取 MigrationController CR 清单:

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. 添加 stunnel_tcp_proxy 参数:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    指定 Stunnel 代理: http://<user_name>:<password>@<ip_address>:<port>
  4. 将清单保存为 migration-controller.yaml
  5. 应用更新的清单:

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

1.6.1.4. 为迁移 hook 编写 Ansible playbook

您可以编写 Ansible playbook 以用作迁移 hook。通过使用 MTC web 控制台或在 MigPlan 自定义资源(CR)清单中指定 spec.hooks 参数的值来在迁移计划中添加 hook。

Ansible playbook 作为一个配置映射挂载到 hook 容器上。hook 容器使用 MigPlan CR 中指定的集群、服务帐户和命名空间以作业的形式运行。hook 容器使用指定的服务帐户令牌,以便当任务在集群中运行前无需进行身份验证。

1.6.1.4.1. Ansible 模块

您可以使用 Ansible shell 模块来运行 oc 命令。

shell 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces

您可以使用 kubernetes.core 模块(如 k8s_info )与 Kubernetes 资源交互。

k8s_facts 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"

在非零退出状态通常不会生成的情况下,可以使用 fail 模块生成一个非零退出状态,以确保可以检测到 hook 的成功或失败。hook 以作业形式运行,hook 的成功或失败状态取决于作业容器的退出状态。

fail 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail

1.6.1.4.2. 环境变量

MigPlan CR 名称和迁移命名空间作为环境变量传递给 hook 容器。这些变量可使用 lookup 插件访问。

环境变量示例

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'migration_namespaces')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'migplan_name') }}"

1.6.1.5. 其他资源

1.6.2. 使用 MTC web 控制台迁移应用程序

您可以使用 MTC web 控制台配置集群和复制存储库。然后,您可以创建并运行迁移计划。

1.6.2.1. 启动 MTC web 控制台

您可以在浏览器中启动 MTC web 控制台。

先决条件

  • MTC web 控制台必须具有到 OpenShift Container Platform Web 控制台的网络访问权限。
  • MTC web 控制台必须具有到 OAuth 授权服务器的网络访问权限。

流程

  1. 登录到已安装 MTC 的 OpenShift Container Platform 集群。
  2. 输入以下命令来获取 MTC web 控制台 URL:

    $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

    输出类似于以下: https://migration-openshift-migration.apps.cluster.openshift.com

  3. 启动浏览器并进入 MTC web 控制台。

    注意

    如果在安装 MTC 工具套件 Operator 后尝试立即访问 MTC web 控制台,则该控制台可能无法加载,因为 Operator 仍然在配置集群。等待几分钟后重试。

  4. 如果您使用自签名的 CA 证书,则会提示您接受源集群 API 服务器的 CA 证书。网页会引导您接受剩余证书的过程。
  5. 使用 OpenShift Container Platform 的用户名密码进行登陆。

1.6.2.2. 在 MTC web 控制台中添加集群

您可以在 MTC web 控制台中添加一个集群到 Migration Toolkit for Containers(MTC)web 控制台。

先决条件

  • 如果要使用 Azure 快照复制数据:

    • 您必须为集群指定 Azure 资源组名称。
    • 集群必须位于同一 Azure 资源组中。
    • 集群必须位于同一地理位置。

流程

  1. 登录到集群。
  2. 获取 migration-controller 服务帐户令牌:

    $ oc sa get-token migration-controller -n openshift-migration
    eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ
  3. 在 MTC web 控制台中点 Clusters
  4. Add cluster
  5. 填写以下字段:

    • Cluster name:集群名称可包含小写字母(a-z)和数字(0-9)。它不能包含空格或国际字符。
    • URL:指定 API 服务器 URL,例如 https://<www.example.com>:8443
    • Service account token:粘贴 migration-controller 服务帐户令牌。
    • 公开的路由主机到镜像 registry:如果您使用直接镜像迁移,请指定源集群镜像 registry 的公开路由,例如 www.example.apps.cluster.com

      您可以指定一个端口。默认端口为 5000

    • Azure cluster:如果使用 Azure 快照复制数据,您必须选择此选项。
    • Azure resource group:如果选择了 Azure cluster,则会显示此字段。指定 Azure 资源组。
    • 需要 SSL 验证:可选:选择这个选项验证到集群的 SSL 连接。
    • CA bundle file:如果选择了 Require SSL 验证,则会显示此字段。如果您为自签名证书创建了自定义 CA 证书捆绑包文件,请点 Browse,选择 CA 捆绑包文件并上传它。
  6. Add cluster

    集群会出现在 Clusters 列表中。

1.6.2.3. 在 MTC web 控制台中添加复制存储库

您可以将对象存储桶作为复制仓库添加到 MTC 的 web 控制台的 Migration Toolkit for Containers(MTC)web 控制台。

先决条件

  • 您必须配置用于迁移数据的对象存储桶。

流程

  1. 在 MTC web 控制台中点 Replication repositories
  2. Add repository
  3. 选择 Storage provider type 并填写以下字段:

    • AWS 适用于 S3、MCSG 和通用 S3 供应商:

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • S3 bucket name:指定您创建的 S3 存储桶的名称。
      • S3 bucket region:指定 S3 存储桶区域。AWS S3 必填Optional 用于其他 S3 供应商。
      • S3 端点:指定 S3 服务的 URL,而不是存储桶,例如:https://<s3-storage.apps.cluster.com>。通用 S3 供应商必填。您必须使用 https:// 前缀。
      • S3 provider access key:为 AWS 指定 <AWS_SECRET_ACCESS_KEY> ,或者为 MCG 指定 S3 供应商访问密钥。
      • S3 provider secret access key:为 AWS 指定 <AWS_ACCESS_KEY_ID> ,或者为 MCG 指定 S3 供应商 secret 访问密钥。
      • Require SSL verification:如果您使用的是通用 S3 供应商,则清除此复选框。
      • 如果您使用自定义 CA 捆绑包,请点击 Browse 并浏览到所需的 Base64 编码的 CA 捆绑包文件。
    • GCP

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • GCP bucket name:指定 GCP 存储桶的名称。
      • GCP credential JSON blob:在 credentials-velero 文件中指定字符串。
    • Azure

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • Azure resource group:指定 Azure Blob 存储的资源组。
      • Azure storage account name:指定 Azure Blob 存储帐户名称
      • Azure credentials - INI file contents:在 credentials-velero 文件中指定字符串。
  4. Add repository 并等待连接验证。
  5. Close

    新仓库会出现在 Replication repositories 列表中。

1.6.2.4. 在 MTC web 控制台中创建迁移计划

您可以在 Migration Toolkit for Containers(MTC)web 控制台中创建一个迁移计划。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须确保在所有集群中安装相同的 MTC 版本。
  • 您必须在 MTC web 控制台中添加集群和复制存储库。
  • 如果要使用 move 数据复制方法迁移持久性卷(PV),则源和目标集群必须有对远程卷的不间断网络访问权限。
  • 如果要使用直接镜像迁移,源集群的 MigCluster 自定义资源清单必须指定内部镜像 registry 的公开路由。

流程

  1. 在 MTC web 控制台中点 Migration Plan
  2. Add migration plan
  3. 输入 Plan name 并点 Next

    迁移计划名称不能超过 253 个小写字母数字字符(a-z, 0-9),且不能包含空格或下划线(_)。

  4. 选一个 Source cluster
  5. 选一个 Target cluster
  6. 选一个 Replication repository
  7. 选择要迁移的项目并点 Next
  8. 选择 Source clusterTarget clusterRepository,然后点 Next
  9. Namespaces 页面中,选择要迁移的项目并点 Next
  10. Persistent volumes 页面中,点每个 PV 的 迁移类型

    • Copy 选项将源集群的 PV 中的数据复制到复制存储库中,然后在目标集群中恢复新创建的具有类似特征的 PV 上的数据。
    • Move 选项从源集群中卸载一个远程卷(例如 NFS),在目标集群上创建一个指向这个远程卷的 PV 资源,然后在目标集群中挂载远程卷。在目标集群中运行的应用程序使用源集群使用的同一远程卷。
  11. Next
  12. Copy options 页面中,为每个 PV 选择 Copy method:

    • 快照复制使用云供应商的快照功能备份和恢复数据。它比 Filesystem copy 要快得多。
    • Filesystem copy 备份源集群中的文件,并在目标集群中恢复它们。

      直接卷迁移需要使用文件系统复制方法。

  13. 您可以选择 Verify copy 来验证使用 Filesystem copy 迁移的数据。数据是通过为每个源文件生成 checksum 并在恢复后检查 checksum 来验证。数据校验可能会显著降低性能
  14. 选择 目标存储类

    如果选择了 Filesystem copy,您可以更改目标存储类。

  15. Next
  16. Migration options 页面上,如果您为源集群指定了公开的镜像 registry 路由,则会选择 Direct 镜像迁移 选项。如果使用 Filesystem copy 迁移数据,Direct PV migration 选项会被选择。

    直接迁移选项将镜像和文件直接从源集群复制到目标集群。这个选项比将源集群的镜像和文件复制到复制存储库,然后再从复制存储库复制到目标集群要快。

  17. Next
  18. 可选:在 Hooks 页中,点 Add Hook 为迁移计划添加 hook。

    hook 运行自定义代码。您可以在单个迁移计划中最多添加四个 hook。每个 hook 在不同的迁移步骤中运行。

    1. 在 web 控制台中输入要显示的 hook 名称。
    2. 如果 hook 是一个 Ansible playbook,请选择 Ansible playbook,然后点 Browse 上传 playbook,或在字段中粘贴 playbook 的内容。
    3. 可选: 如果不使用默认 hook 镜像,请指定 Ansible 运行时镜像。
    4. 如果 hook 不是 Ansible playbook,选择 Custom container image 并指定镜像名称和路径。

      自定义容器镜像可以包含 Ansible playbook。

    5. 选择 Source clusterTarget cluster
    6. 输入 Service account nameService account namespace
    7. 为 hook 选择迁移步骤:

      • preBackup:在应用程序工作负载在源集群中备份前
      • PostBackup:在应用程序工作负载在源集群中备份后
      • preRestore:在目标集群中恢复应用程序工作负载前
      • postRestore:在目标集群中恢复应用程序工作负载后
    8. Add
  19. Finish

    迁移计划显示在 Migration Plan 列表中。

1.6.2.5. 在 MTC web 控制台中运行迁移计划

您可以使用在 Migration Toolkit for Containers(MTC)web 控制台中创建的迁移计划来 stage 或迁移应用程序和数据。

注意

迁移过程中,在目标集群中,MTC 将迁移的持久性卷(PV)的重新声明策略设置为 Retain

Backup 自定义资源包含一个 PVOriginalReclaimPolicy 注解,用于指示原始重新声明策略。您可以手动恢复迁移 PV 的重新声明策略。

先决条件

MTC web 控制台必须包含以下内容:

  • 处于 Ready 状态的源集群
  • 处于 Ready 状态的目标集群
  • 复制软件仓库
  • 有效的迁移计划

流程

  1. 登录到源集群。
  2. 删除旧镜像:

    $ oc adm prune images
  3. 登录到 MTC web 控制台并点 迁移计划
  4. 点击迁移计划 kebab 旁边的 Options 菜单,然后选择 Stage 将数据从源集群复制到目标集群,而不停止应用程序。

    您可以多次运行 Stage 以减少实际迁移时间。

  5. 当您准备好迁移应用程序工作负载时,在迁移计划 kebab 边的 Options 菜单并选择 Migrate
  6. 另外,还可以在 Migrate 窗口中选择 Do not stop applications on the source cluster during migration
  7. Migrate
  8. 迁移完成后,在 OpenShift Container Platform web 控制台中确认已成功迁移了应用程序:

    1. HomeProjects
    2. 点迁移的项目查看其状态。
    3. Routes 部分,点击 Location 验证应用程序是否正常运行。
    4. WorkloadsPods 来验证 pod 是否在迁移的命名空间中运行。
    5. StoragePersistent volumes 确认正确置备了被迁移的持久性卷。

1.6.3. 从命令行迁移应用程序

您可以使用 MTC 自定义资源(CR)在命令行中迁移应用程序。

您可以将应用程序从本地集群迁移到远程集群,从远程集群迁移到本地集群,并在远程集群间进行迁移。

MTC 术语

以下与配置集群相关的术语:

  • host 集群:

    • migration-controller pod 在 host 集群中运行。
    • host 集群不需要有一个公开的安全 registry 路由来直接进行镜像迁移。
  • 本地集群:本地集群通常与 host 集群相同,但这不是必须的。
  • 远程集群:

    • 远程集群必须具有公开的安全 registry 路由才能直接迁移镜像。
    • 远程集群必须具有包含 migration-controller 服务帐户令牌的 Secret CR。

以下与迁移相关的术语:

  • Source cluster(源集群):从中迁移应用程序的集群。
  • 目标集群(Destination cluster):将应用程序迁移到的集群。

1.6.3.1. 使用 MTC API 迁移应用程序

您可以使用 MTC API 在命令行中迁移应用程序。

您可以将应用程序从本地集群迁移到远程集群,从远程集群迁移到本地集群,并在远程集群间进行迁移。

这个步骤描述了如何执行间接迁移和直接迁移:

  • 间接迁移:镜像、卷和 Kubernetes 对象从源集群复制到复制存储库,然后从复制存储库复制到目标集群。
  • 直接迁移: 镜像或卷直接从源集群复制到目标集群。直接镜像迁移和直接卷迁移可显著提高性能。

创建以下自定义资源(CR)来执行迁移:

  • MigCluster CR:定义一个 host、本地或远程集群

    migration-controller pod 在 host 集群中运行。

  • Secret CR:包含远程集群或存储的凭证
  • MigStorage CR:定义一个复制存储库

    不同的存储供应商需要在 MigStorage CR 清单中使用不同的参数。

  • MigPlan CR:定义一个迁移计划
  • MigMigration CR:执行在关联的 MigPlan 中定义的一个迁移

    您可以针对以下目的,为单个 MigPlan CR 创建多个 MigMigration CR:

  • 在运行迁移前,执行一个阶段(stage)迁移(在不停止应用程序的情况下复制大多数数据)。阶段迁移可以提高迁移的性能。
  • 取消正在进行中的迁移
  • 回滚一个已完成的迁移

先决条件

  • 需要在所有集群中都有 cluster-admin 权限。
  • 您必须安装 OpenShift Container Platform CLI(oc)。
  • 您必须在所有集群中安装 MTC Operator。
  • 在所有集群中,安装的 Migration Toolkit for Containers Operator 的版本必须相同。
  • 您必须将对象存储配置为复制存储库。
  • 如果使用直接镜像迁移,则必须在所有远程集群中公开安全 registry 路由。
  • 如果您使用直接卷迁移,源集群不能配置 HTTP 代理。

流程

  1. host 集群创建一个名为 host-cluster.yamlMigCluster CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host 集群创建一个 MigCluster CR:

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. 为每个远程集群创建一个名为 cluster-secret.yamlSecret CR 清单:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    指定远程集群的 base64 编码的 migration-controller 服务帐户(SA)令牌。

    您可以运行以下命令来获取 SA 令牌:

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. 为每个远程集群创建一个 Secret CR:

    $ oc create -f cluster-secret.yaml
  5. 为每个远程集群创建一个名为 remote-cluster.yamlMigCluster CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    可选:指定公开的 registry 路由,例如 docker-registry-default.apps.example.cm,如果使用直接镜像迁移。
    2
    如果 false 则启用 SSL 验证。如果为 true,则不需要 CA 证书或不检查 CA 证书。
    3
    指定远程集群的 Secret CR。
    4
    指定远程集群的 URL。
  6. 为每个远程集群创建一个 MigCluster CR:

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. 验证所有集群是否处于 Ready 状态:

    $ oc describe cluster <cluster_name>
  8. 为名为 storage-secret.yaml 的复制存储库创建 Secret CR 清单:

    apiVersion: v1
    kind: Secret
    metadata:
      namespace: openshift-config
      name: <migstorage_creds>
    type: Opaque
    data:
      aws-access-key-id: <key_id_base64> 1
      aws-secret-access-key: <secret_key_base64> 2
    1
    指定 base64 格式的密钥 ID。
    2
    指定 base64 格式的 secret 密钥。

    AWS 凭证默认为 base64 编码。如果使用另一个存储供应商,则必须使用每个密钥运行以下命令来对凭证进行编码:

    $ echo -n "<key>" | base64 -w 0 1
    1
    指定密钥 ID 或 secret 密钥。这两个密钥都必须都是 base64 编码。
  9. 为复制存储库创建 Secret CR:

    $ oc create -f storage-secret.yaml
  10. 为复制存储库创建一个名为 migstorage.yamlMigStorage CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    指定存储桶名称。
    2
    指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。
    3
    指定存储供应商。
    4
    可选: 如果要使用快照复制数据,请指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。
    5
    可选: 如果您使用快照复制数据,请指定存储供应商。
  11. 创建 MigStorage CR:

    $ oc create -f migstorage.yaml -n openshift-migration
  12. 验证 MigStorage CR 是否处于 Ready 状态:

    $ oc describe migstorage <migstorage_name>
  13. 创建名为 migplan.yamlMigPlan CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    如果为 false,则启用直接镜像迁移。
    2
    如果为 false,则启用直接卷迁移。
    3
    指定 MigStorage CR 实例的名称。
    4
    指定要迁移的一个或多个命名空间。
    5
    指定源集群 MigCluster 实例的名称。
  14. 创建 MigPlan CR:

    $ oc create -f migplan.yaml -n openshift-migration
  15. 查看 MigPlan 实例,以验证它是否处于 Ready 状态:

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. 创建名为 migmigration.yamlMigMigration CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    指定 MigPlan CR 名称。
    2
    如果为 true,则源集群上的 pod 会在迁移前停止。
    3
    如果为 true,则进行阶段(stage)迁移,即在不停止应用程序的情况下复制大多数数据。
    4
    如果为 true,则会回滚到一个已完成的迁移。
  17. 创建 MigMigration CR 以启动 MigPlan CR 中定义的迁移:

    $ oc create -f migmigration.yaml -n openshift-migration
  18. 通过观察 MigMigration CR 来验证迁移的进度:

    $ oc watch migmigration <migmigration_name> -n openshift-migration

    输出类似于以下:

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

1.6.3.2. MTC 自定义资源清单

MTC 使用以下自定义资源(CR)清单来创建用于迁移应用程序的 CR。

1.6.3.2.1. DirectImageMigration

DirectImageMigration CR 直接将镜像从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
指定源集群的 MigCluster CR 名称。
2
指定目标集群的 MigCluster CR 名称。
3
指定包含要迁移的镜像的一个或多个命名空间。
1.6.3.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR 直接将镜像流引用从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
指定源集群的 MigCluster CR 名称。
2
指定目标集群的 MigCluster CR 名称。
3
指定镜像流名称。
4
指定源集群上的镜像流命名空间。
5
指定目标集群上的镜像流命名空间。
1.6.3.2.3. DirectVolumeMigration

DirectVolumeMigration CR 直接将持久性卷(PV)从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <directvolumemigration_name>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: host 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc_name> 4
    namespace: <pvc_namespace> 5
  srcMigClusterRef:
    name: <source_cluster_ref> 6
    namespace: openshift-migration
1
如果为 true,在目标集群上为 PV 创建命名空间。
2
如果为 true,在迁移后会删除 DirectVolumeMigrationProgress CR。默认值为 false,这会保留 DirectVolumeMigrationProgress CR 以便进行故障排除。
3
如果目标集群不是主机集群,请更新集群名称。
4
指定使用直接卷迁移进行迁移的一个或多个 PVC。
5
指定每个 PVC 的命名空间。
6
指定源集群的 MigCluster CR 名称。
1.6.3.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR 显示 DirectVolumeMigration CR 的进度。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directvolumemigrationprogress_name
spec:
  clusterRef:
    name: source_cluster
    namespace: openshift-migration
  podRef:
    name: rsync_pod
    namespace: openshift-migration
1.6.3.2.5. MigAnalytic

MigAnalytic CR 从一个关联的 MigPlan CR 中收集镜像、Kubernetes 资源以及 PV 容量的数量。

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan_name> 1
  name: miganalytic_name
  namespace: openshift-migration
  labels:
    migplan: <migplan_name> 2
spec:
  analyzeImageCount: true 3
  analyzeK8SResources: true 4
  analyzePVCapacity: true 5
  listImages: false 6
  listImagesLimit: 50 7
  migPlanRef:
    name: migplan_name 8
    namespace: openshift-migration
1
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
2
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
3
可选:如果为 true,返回镜像数量。
4
可选:返回 Kubernetes 资源的数量、类型和 API 版本(如果为 true )。
5
可选:如果为 true 则返回 PV 容量。
6
如果为 true,则返回镜像名称列表。默认为 false,因此输出不会过长。
7
可选:指定如果 listImagestrue 时要返回的最大镜像名称数。
8
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
1.6.3.2.6. MigCluster

MigCluster CR 定义一个主机、本地或远程集群。

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  azureResourceGroup: <azure_resource_group> 3
  caBundle: <ca_bundle_base64> 4
  insecure: false 5
  refresh: false 6
# The 'restartRestic' parameter is relevant for a source cluster.
# restartRestic: true 7
# The following parameters are relevant for a remote cluster.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
可选:如果 migration-controller pod 没有在这个集群中运行,则更新集群名称。
2
如果为 true,则 migration-controller pod 在此集群中运行。
3
可选: 如果存储供应商是 Microsoft Azure,请指定资源组。
4
可选:如果您为自签名 CA 证书创建了一个证书捆绑包,且 insecure 参数值为 false,请指定 base64 编码的证书捆绑包。
5
如果 false 则启用 SSL 验证。
6
如果为 true,集群会被验证。
7
如果为 true,在创建 stage pod 后 restic pod 会在源集群中重启。
8
可选:如果您使用直接镜像迁移,请指定远程集群的公开 registry 路径。
9
指定远程集群的 URL。
10
指定远程集群的 Secret CR 名称。
1.6.3.2.7. MigHook

MigHook CR 定义一个 Ansible playbook ,或一个自定义镜像,它在迁移的指定阶段运行任务。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 3
  custom: false 4
  image: <hook_image> 5
  playbook: <ansible_playbook_base64> 6
  targetCluster: source 7
1
可选:此参数的值后附加一个唯一的哈希值,以便每个迁移 hook 都有一个唯一的名称。您不需要指定 name 参数的值。
2
指定迁移 hook 名称,除非指定了 generateName 参数的值。
3
可选:指定 hook 可运行的最大秒数。默认值为 1800
4
如果为 true,则 hook 是一个自定义镜像。自定义镜像可以包括 Ansible,也可以使用不同的编程语言编写。
5
指定自定义镜像,例如 quay.io/konveyor/hook-runner:latest。如果 customtrue,则需要此项。
6
指定整个 base64 编码的 Ansible playbook。如果 customfalse,则必需。
7
指定 hook 要在其上运行的 sourcedestination 集群。
1.6.3.2.8. MigMigration

MigMigration CR 运行一个关联的 MigPlan CR。

您可以针对以下场景,创建多个与同一 MigPlan CR 关联的 MigMigration CR:

  • 您可以运行多个阶段迁移,或增量迁移,以在没有在源集群中停止 pod 的情况下复制数据。运行阶段迁移可提高实际迁移的性能。
  • 您可以取消正在进行中的迁移。
  • 您可以回滚迁移。
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  namespace: openshift-migration
spec:
  canceled: false 1
  rollback: false 2
  stage: false 3
  quiescePods: true 4
  keepAnnotations: true 5
  verify: false 6
  migPlanRef:
    name: <migplan_ref> 7
    namespace: openshift-migration
1
如果为 true,则会取消正在进行中的迁移。
2
如果为 true,则会回滚到一个已完成的迁移。
3
如果为 true,数据会被递增复制,pod 不会在源集群中停止。
4
如果为 true,在迁移的备份阶段后,源集群中的 pod 会被缩减为 0
5
如果为 true,则迁移期间应用的标签和注解将被保留。
6
如果 true ,检查目标集群中迁移的 pod 的状态,并返回处于 Running 状态的 pod 名称。
7
migPlanRef.name:指定关联的 MigPlan CR 的名称。
1.6.3.2.9. MigPlan

MigPlan CR 定义迁移计划的参数。它包含一组使用相同参数迁移的虚拟机。

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migplan_name
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_migcluster_ref> 2
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_migcluster_ref> 3
    namespace: openshift-migration
  hooks: 4
    - executionNamespace: <namespace> 5
      phase: <migration_phase> 6
      reference:
        name: <mighook_name> 7
        namespace: <hook_namespace> 8
      serviceAccount: <service_account> 9
  indirectImageMigration: true 10
  indirectVolumeMigration: false 11
  migStorageRef:
    name: <migstorage_name> 12
    namespace: openshift-migration
  namespaces:
  - <namespace>  13
  refresh: false  14
1
如果为 true,则迁移已完成。您不能为此 MigPlan CR 创建另一个 MigMigration CR。
2
指定源集群 MigCluster CR 的名称。
3
指定目标集群 MigCluster CR 的名称。
4
可选:最多可指定四个迁移 hook。
5
可选:指定运行 hook 的命名空间。
6
可选:指定 hook 运行期间的迁移阶段。一个 hook 可以分配给一个阶段。预期的值包括 PreBackupPostBackupPreRestorePostRestore
7
可选:指定 MigHook CR 的名称。
8
可选:指定 MigHook CR 的命名空间。
9
可选:指定一个具有 cluster-admin 权限的服务帐户。
10
如果为 true,则禁用直接镜像迁移。镜像从源集群复制到复制存储库,并从复制存储库复制到目标集群。
11
如果为 true,则禁用直接卷迁移。PV 从源集群复制到复制存储库,再从复制存储库复制到目标集群。
12
指定 MigStorage CR 的名称。
13
指定一个或多个命名空间。
14
如果为 trueMigPlan CR 会被验证。
1.6.3.2.10. MigStorage

MigStorage CR 描述了复制存储库的对象存储。您可以配置 Amazon Web Services、Microsoft Azure、Google Cloud Storage 和通用 S3 兼容云存储,如 Minio 或 NooBaa。

不同的供应商需要不同的参数。

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migstorage_name
  namespace: openshift-migration
spec:
  backupStorageProvider: <storage_provider> 1
  volumeSnapshotProvider: 2
  backupStorageConfig:
    awsBucketName: 3
    awsRegion: 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: 6
    awsPublicUrl: 7
    awsSignatureVersion: 8
  volumeSnapshotConfig:
    awsRegion: 9
    credsSecretRef:
      namespace: openshift-config
      name: 10
  refresh: false 11
1
指定存储供应商。
2
可选: 如果您使用快照复制方法,请指定存储供应商。
3
如果使用 AWS,请指定存储桶名称。
4
如果使用 AWS,请指定存储桶区域,如 us-east-1
5
指定为 MigStorage CR 创建的 Secret CR 的名称。
6
可选:如果您使用 AWS Key Management Service,请指定该密钥的唯一标识符。
7
可选: 如果授予 AWS 存储桶的公共访问权限,请指定存储桶 URL。
8
可选:指定向存储桶验证请求的 AWS 签名版本,例如 4
9
可选:如果您使用快照复制方法,请指定集群的地理位置。
10
可选:如果您使用快照复制方法,请指定为 MigStorage CR 创建的 Secret CR 名称。
11
如果为 true,集群会被验证。

1.6.4. 其他资源

1.6.5. 配置迁移计划

您可以增加要迁移或排除迁移的资源的数量。

1.6.5.1. 为大型迁移增加限制

您可以使用 MTC 为大型迁移增加迁移对象和容器资源的限制。

重要

您必须在生产环境中执行迁移前测试这些更改。

流程

  1. 编辑 MigrationController 自定义资源(CR)清单:

    $ oc edit migrationcontroller -n openshift-migration
  2. 更新以下参数:

    ...
    mig_controller_limits_cpu: "1" 1
    mig_controller_limits_memory: "10Gi" 2
    ...
    mig_controller_requests_cpu: "100m" 3
    mig_controller_requests_memory: "350Mi" 4
    ...
    mig_pv_limit: 100 5
    mig_pod_limit: 100 6
    mig_namespace_limit: 10 7
    ...
    1
    指定 MigrationController CR 可用的 CPU 数量。
    2
    指定 MigrationController CR 可用的内存量。
    3
    指定可用于 MigrationController CR 请求的 CPU 单元数。100m 代表 0.1 CPU 单元(100 * 1e-3)。
    4
    指定可用于 MigrationController CR 请求的内存量。
    5
    指定可迁移的持久性卷数量。
    6
    指定可迁移的 pod 数量。
    7
    指定可迁移的命名空间数量。
  3. 创建使用更新的参数验证更改的迁移计划。

    如果您的迁移计划超过 MigrationController CR 限制,则 MTC 控制台在保存迁移计划时会显示警告信息。

1.6.5.2. 从迁移计划中排除资源

您可以从 MTC 迁移计划中排除资源,如镜像流、持久性卷(PV)或订阅,以便减少迁移的资源负载,或使用其他工具迁移镜像或 PV。

默认情况下,MTC 会排除服务目录资源和 Operator Lifecycle Manager(OLM)资源。这些资源是服务目录 API 组和 OLM API 组的一部分,目前还不支持迁移。

流程

  1. 编辑 MigrationController 自定义资源清单:

    $ oc edit migrationcontroller <migration_controller> -n openshift-migration
  2. 更新 spec 部分,方法是添加参数以排除特定资源,或者在 exclude_resources 参数中添加资源(如果它本身没有排除参数):

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      disable_image_migration: true 1
      disable_pv_migration: true 2
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
    1
    添加 disable_image_migration: true 以排除迁移中的镜像流。不要编辑 exclude_resources 参数。当 MigrationController pod 重启时,镜像流会添加到 excluded_resources
    2
    添加 disable_pv_migration: true 以将 PV 排除在迁移计划之外。不要编辑 exclude_resources 参数。当 MigrationController Pod 重启时,persistentvolumespersistentvolumeclaims 会被添加到 excluded_resources。禁用 PV 迁移会同时在创建迁移计划时禁用 PV 发现功能。
    3
    您可以将 OpenShift Container Platform 资源添加到 exclude_resources 列表中。不要删除默认排除的资源。对这些进行迁移可能会产生问题,因此必须被排除。
  3. 等待 2 分钟,使 MigrationController Pod 重启,以便应用更改。
  4. 验证资源是否排除:

    $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

    输出包含排除的资源:

    输出示例

        - name: EXCLUDED_RESOURCES
          value:
          imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

1.7. 故障排除

您可以查看 MTC 的 Migration Toolkit for Containers(MTC)自定义资源并下载日志来排除迁移失败的问题。

如果应用程序在迁移失败时停止,您必须手动回滚,以防止数据崩溃。

注意

如果应用程序在迁移过程中没有停止,则不需要手动回滚,因为原始应用程序仍然在源集群中运行。

1.7.1. 查看迁移自定义资源

MTC 会创建以下自定义资源(CR):

migration architecture diagram

20 MigCluster (配置, MTC 集群): 集群定义

20 MigStorage (配置, MTC 集群): Storage 定义

20 MigPlan (配置, MTC 集群):迁移计划

MigPlan CR 描述了要迁移的源和目标集群、复制仓库和命名空间。它与 0 个、1 个或多个 MigMigration CR 关联。

注意

删除 MigPlan CR 会删除关联的 MigMigration CR。

20 BackupStorageLocation (配置, MTC 集群): Velero 备份对象的位置

20 VolumeSnapshotLocation (配置, MTC 集群): Velero 卷快照的位置

20 MigMigration (操作,MTC 集群)::迁移,在每次进行 stage 或迁移数据时创建。每个 MigMigration CR 都与 MigPlan CR 关联。

20 Backup(操作,源集群):当运行迁移计划时,MigMigration CR 在每个源集群上创建两个 Velero 备份 CR:

  • 备份 CR #1 用于Kubernetes 对象
  • 备份 CR #2 用于 PV 数据

20 Restore (操作,目标集群):在运行迁移计划时,MigMigration CR 在目标集群上创建两个 Velero 恢复 CR:

  • 恢复 CR #1(使用备份 CR #2)用于 PV 数据
  • 恢复 CR #2(使用备份 CR #1)用于 Kubernetes 对象

流程

  1. 列出 openshift-migration 命名空间中的 MigMigration CR:

    $ oc get migmigration -n openshift-migration

    输出示例

    NAME                                   AGE
    88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

  2. 检查 MigMigration CR:

    $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

    输出结果类似以下示例。

MigMigration 示例输出

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

Velero 备份 CR #2 示例输出来描述 PV 数据

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Velero 恢复 CR #2 示例输出来描述 Kubernetes 资源

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

1.7.2. 使用迁移日志读取器

您可以使用迁移日志读取器显示所有迁移日志的过滤视图。

流程

  1. 获取 mig-log-reader pod:

    $ oc -n openshift-migration get pods | grep log
  2. 输入以下命令显示单个迁移日志:

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    -c plain 选项显示没有颜色的日志。

1.7.3. 下载迁移日志

您可以在 Migration Toolkit for Containers(MTC)web 控制台中下载 VeleroResticMigrationController pod 日志,以排除迁移失败的问题。

流程

  1. 在 MTC 控制台中,点 Migration plan 查看迁移计划列表。
  2. 点击特定迁移计划 kebabOptions 菜单并选择 Logs
  3. Download Logs 为所有集群下载 MigrationControllerVeleroRestic pod 的日志。

    您可以选择集群、日志源和 pod 源下载单个日志,然后点 Download Selected

    您可以使用 oc logs 命令从 CLI 访问 pod 日志:

    $ oc logs <pod-name> -f -n openshift-migration 1
    1
    指定 pod 名称。

1.7.4. 更新已弃用的 API

如果您的源集群使用已弃用的 API,在 MTC web 控制台中创建迁移计划时会显示以下警告信息:

Some namespaces contain GVKs incompatible with destination cluster

您可以点 See details 查看命名空间和不兼容的 API。这个警告信息并不会阻止迁移。

在使用 Migration Toolkit for Containers(MTC)进行迁移的过程中,已弃用的 API 保存在用于 Kubernetes 对象的 Velero Backup #1 中。您可以下载 Velero Backup,提取已弃用的 API yaml 文件,并使用 oc convert 命令更新它们。然后您可以在目标集群中创建更新的 API。

流程

  1. 运行迁移计划
  2. 查看 MigPlan 自定义资源(CR):

    $ oc describe migplan <migplan_name> -n openshift-migration 1
    1
    指定 MigPlan CR 的名称。

    输出结果类似以下:

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    记录 MigPlan CR UID。
    2
    记录 gvks 部分中列出的已弃用 API。
  3. 获取与 MigPlan UID 关联的 MigMigration 名称:

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    指定 MigPlan CR UID。
  4. 获取与 MigMigration 名称关联的 MigMigration UID:

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    指定 MigMigration 名称。
  5. 获取与 MigMigration UID 关联的 Velero 备份名称:

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    指定 MigMigration UID。
  6. 根据您所使用的存储供应商运行以下命令,将 Velero 备份的内容下载到您的本地机器中:

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      指定存储桶、备份名称和您的本地备份目录名称。
    • GCP:

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      指定存储桶、备份名称和您的本地备份目录名称。
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      指定备份名称和您的本地备份目录名称。
  7. 解压 Velero 备份归档文件:

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 对于每个弃用的 API,以离线模式运行 oc convert

    $ oc convert -f <backup_local_dir>/resources/<gvk>.json
  9. 在目标集群中创建转换的 API:

    $ oc create -f <gvk>.json

1.7.5. 错误信息和解决方案

本节论述了您可能会在 Migration Toolkit for Containers(MTC)中遇到的常见错误消息,以及如何解决其底层原因。

1.7.5.1. Restic 超时错误

如果在第一次尝试访问 MTC 控制台时显示 CA 证书错误信息,则可能的原因是在一个集群中使用自签名的 CA 证书。

要解决这个问题,进入出错信息中显示的 oauth-authorization-server URL 并接受证书。要永久解决这个问题,将证书添加到网页浏览器的信任存储中。

如果您接受证书后显示 Unauthorized 信息,进入 MTC 控制台并刷新网页。

1.7.5.2. MTC 控制台中的 OAuth 超时错误

如果在接受自签名证书后,MTC 控制台中显示 connection has timed out,其原因可能是:

您可以确定超时的原因。

流程

  1. 进入 MTC 控制台,使用浏览器的 web 检查功能进行检查。
  2. 检查 MigrationUI pod 日志:

    $ oc logs <MigrationUI_Pod> -n openshift-migration

1.7.5.3. Velero pod 日志中的 PodVolumeBackups 超时错误

如果因为 Restic 超时造成迁移失败,以下错误会在 Velero pod 日志中显示。

输出示例

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

restic_timeout 的默认值为一小时。您可以为大型迁移增加这个参数值,请注意,高的值可能会延迟返回出错信息。

流程

  1. 在 OpenShift Container Platform web 控制台中导航至 OperatorsInstalled Operators
  2. Migration Toolkit for Containers Operator
  3. MigrationController 标签页中点 migration-controller
  4. YAML 标签页中,更新以下参数值:

    spec:
      restic_timeout: 1h 1
    1
    有效单元是 h (小时)、m (分钟)和 s (秒),例如 3h30m15s
  5. Save

1.7.5.4. MigMigration 自定义资源中的 ResticVerifyErrors

如果迁移使用文件系统数据复制方法的持久性卷时数据验证失败,在 MigMigration CR 中会显示以下错误。

输出示例

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2

1
错误消息指定了 Restore CR 名称。
2
ResticVerifyErrors 是一个包括验证错误的一般错误警告类型。
注意

数据验证错误不会导致迁移过程失败。

您可以检查 Restore CR,以识别数据验证错误的来源。

流程

  1. 登录到目标集群。
  2. 查看 Restore CR:

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    输出会标识出带有 PodVolumeRestore 错误的持久性卷。

    输出示例

    status:
      phase: Completed
      podVolumeRestoreErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration
      podVolumeRestoreResticErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration

  3. 查看 PodVolumeRestore CR:

    $ oc describe <migration-example-rvwcm-98t49>

    输出中标识了记录错误的 Restic pod。

    输出示例

      completionTimestamp: 2020-05-01T20:49:12Z
      errors: 1
      resticErrors: 1
      ...
      resticPod: <restic-nr2v5>

  4. 查看 Restic pod 日志以查找错误:

    $ oc logs -f <restic-nr2v5>

1.7.6. 直接卷迁移未完成

如果直接卷迁移未完成,则目标集群可能没有与源集群相同的 node-selector 注解。

MTC 在迁移命名空间时会保留所有注解,以保持安全性上下文约束和调度要求。在直接卷迁移过程中,MTC 在从源集群迁移的命名空间中在目标集群上创建 Rsync 传输 pod。如果目标集群命名空间没有与源集群命名空间相同的注解,则无法调度 Rsync 传输 pod。Rsync pod 处于 Pending 状态。

您可以执行以下步骤识别并解决这个问题。

流程

  1. 检查 MigMigration CR 的状态:

    $ oc describe migmigration <pod_name> -n openshift-migration

    输出包括以下状态消息:

    输出示例

    ...
    Some or all transfer pods are not running for more than 10 mins on destination cluster
    ...

  2. 在源集群中,获取迁移的命名空间的详情:

    $ oc get namespace <namespace> -o yaml 1
    1
    指定迁移的命名空间。
  3. 在目标集群中,编辑迁移的命名空间:

    $ oc edit namespace <namespace>
  4. 在迁移的命名空间中添加缺少的 openshift.io/node-selector 注解,如下例所示:

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. 再次运行迁移计划。

1.7.7. 使用 Velero CLI 调试备份和恢复 CR

您可以使用 Velero 命令行界面(CLI)调试 BackupRestore 自定义资源(CR)和迁移部分失败的情况。Velero CLI 在 velero pod 中运行。

1.7.7.1. Velero 命令语法

Velero CLI 命令使用以下语法:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero <resource> <command> <resource_id>

您可以在 $(oc get pods -n openshift-migration -o name | grep velero) 中指定 velero-<pod> -n openshift-migration

1.7.7.2. help 命令

Velero help 命令列出所有 Velero CLI 命令:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help

1.7.7.3. describe 命令

Velero describe 命令提供了与 Velero 资源相关的警告和错误概述信息:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero  <resource> describe <resource_id>

示例

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

1.7.7.4. logs 命令

Velero logs 命令提供与 Velero 资源关联的日志:

velero <resource> logs <resource_id>

示例

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

1.7.7.5. 调试部分迁移失败

您可以使用 Velero CLI 检查 Restore 自定义资源(CR)日志来调试部分迁移失败警告消息。

当 Velero 遇到没有导致迁移失败的问题时,会导致迁移部分失败。例如,缺少自定义资源定义(CRD),或者源集群和目标集群的 CRD 版本之间存在冲突,则迁移会完成,但不会在目标集群上创建 CR。

Velero 将问题作为部分失败记录,然后处理 备份 CR 中的其他对象。

流程

  1. 检查 MigMigration CR 的状态:

    $ oc get migmigration <migmigration> -o yaml
    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings
  2. 使用 Velero describe 命令检查 Restore CR 的状态:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. 使用 Velero logs 命令检查 Restore CR 日志:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    Restore CR 会记录日志错误消息, the server could not find the requested resource,代表迁移部分失败的原因。

1.7.8. 使用 must-gather 收集数据

如果您要在 红帽客户门户网站 上创建 MTC 支持问题单,则需要运行 must-gather

MTC 的 openshift-migration-must-gather-rhel8 镜像收集特定于迁移的日志,以及默认 must-gather 镜像不收集的数据。

流程

  1. 进入要存储 must-gather 数据的目录。
  2. 运行 must-gather 命令:

    $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.4
  3. 删除验证密钥和其他敏感信息。
  4. 创建一个包含 must-gather 数据目录内容的归档文件:

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/
  5. 将压缩文件作为附件上传到您的客户支持问题单中。

1.7.9. 回滚一个迁移

您可以使用 MTC web 控制台或 CLI 回滚迁移。

1.7.9.1. 在 MTC web 控制台中回滚迁移

您可以使用 Migration Toolkit for Containers(MTC)web 控制台回滚迁移。

如果应用程序在迁移失败时停止,您必须回滚迁移,以防止持久性卷中的数据崩溃。

如果应用程序在迁移过程中没有停止,则不需要回滚,因为原始应用程序仍然在源集群中运行。

流程

  1. 在 MTC web 控制台中点 Migration Plan
  2. 点击迁移计划 kebab 旁边的 Options 菜单并选择 Rollback
  3. Rollback 并等待回滚完成。

    在迁移计划详情中会显示 Rollback succeeded

  4. 验证源集群的 OpenShift Container Platform Web 控制台中是否成功回滚:

    1. HomeProjects
    2. 点迁移的项目查看其状态。
    3. Routes 部分,点击 Location 验证应用程序是否正常运行。
    4. WorkloadsPods 来验证 pod 是否在迁移的命名空间中运行。
    5. StoragePersistent volumes 确认正确置备了被迁移的持久性卷。
1.7.9.1.1. 通过 CLI 回滚迁移

您可以通过 CLI 创建 MigMigration 自定义资源(CR)来回滚迁移。

如果应用程序在迁移失败时停止,您必须回滚迁移,以防止持久性卷中的数据崩溃。

如果应用程序在迁移过程中没有停止,则不需要回滚,因为原始应用程序仍然在源集群中运行。

流程

  1. 根据以下示例创建一个 MigMigration CR:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: migration-rollback
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
    EOF
    1
    指定关联的 MigPlan CR 的名称。
  2. 在 MTC web 控制台中,验证迁移的项目资源是否已从目标集群中移除。
  3. 验证迁移的项目资源是否存在于源集群中,并且应用程序是否正在运行。

1.7.10. 已知问题

这个版本有以下已知问题:

  • 在迁移过程中,MTC 会保留以下命名空间注解:

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups
    • openshift.io/sa.scc.uid-range

      这些注解会保留 UID 范围,确保容器在目标集群中保留其文件系统权限。这可能会存在一定的风险。因为迁移的 UID 可能已存在于目标集群的现有或将来的命名空间中。(BZ#1748440)

  • 大多数集群范围的资源还没有由 MTC 处理。如果应用程序需要集群范围的资源,则可能需要在目标集群上手动创建。
  • 如果迁移失败,则迁移计划不会为静默的 pod 保留自定义 PV 设置。您必须手动回滚,删除迁移计划,并使用 PV 设置创建新的迁移计划。(BZ#1784899)
  • 如果因为 Restic 超时造成大型迁移失败,您可以提高MigrationController CR 清单中的 restic_timeout 参数值(默认为 1h)。
  • 如果您选择了为使用文件系统复制方法迁移的 PV 数据进行验证的选项,则性能会非常慢。
  • 如果您要从 NFS 存储中迁移数据,并且启用了 root_squash,将 Restic 映射为 nfsnobody。迁移失败,Restic Pod 日志中显示权限错误。(BZ#1873641)

    您可以通过在 MigrationController CR 清单中添加用于 Restic 的额外组来解决这个问题:

    spec:
    ...
      restic_supplemental_groups:
      - 5555
      - 6666
  • 如果您使用位于不同可用区的节点执行直接卷迁移,则迁移可能会失败,因为迁移的 pod 无法访问 PVC。(BZ#1947487)

1.7.11. 其他资源

第 2 章 从 OpenShift Container Platform 4.1 进行迁移

2.1. 迁移工具和先决条件

您可以使用 MTC 将应用程序工作负载从 OpenShift Container Platform 4.1 迁移到 4.5。MTC 可让您控制迁移的过程,并最小化应用程序停机时间。

注意

只要正确配置了源和目标集群,就可以在相同版本的 OpenShift Container Platform 集群间进行迁移(如从 4.1 迁移到 4.1)。

MTC 工具的 web 控制台和 API,基于 Kubernetes 自定义资源,您可以按照命名空间迁移有状态及无状态的应用程序工作负载。

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

您可以在迁移期间的特定点使用迁移 hook 运行 Ansible playbook。您在创建迁移计划时可以添加 hook。

2.1.1. 容器迁移工具(Migration Toolkit for Containers)工作流

您可以使用 MTC(Migration Toolkit for Containers) web 控制台或 Kubernetes API 将 OpenShift Container Platform 源集群中的 Kubernetes 资源、持久性卷数据和内部容器镜像迁移到 OpenShift Container Platform 4.5 目标集群。

(MTC)迁移以下资源:

  • 在迁移计划中指定的命名空间。
  • 命名空间范围的资源:当 MTC 迁移命名空间时,它会迁移与该命名空间关联的所有对象和资源,如服务或 Pod。另外,如果一个资源在命名空间中存在但不在集群级别,这个资源依赖于集群级别存在的另外一个资源,MTC 会迁移这两个资源。

    例如,安全性上下文约束(SCC)是一个存在于集群级别的资源,服务帐户(SA)是存在于命名空间级别的资源。如果 MTC 迁移的命名空间中存在 SA,MTC 会自动找到链接到 SA 的所有 SCC,并迁移这些 SCC。同样,MTC 会迁移链接到命名空间持久性卷的持久性卷声明。

  • 自定义资源(CR)和自定义资源定义(CRD): MTC 会自动迁移任何在命名空间级别存在的 CR,以及链接到这些 CR 的 CRD。

使用 MTC Web 控制台迁移应用程序涉及以下步骤:

  1. 在所有集群中安装 MTC Operator。

    您可以在有限的或没有互联网访问的受限环境中为 Containers Operator 安装 Migration Toolkit。源和目标集群必须可以在相互间进行访问,而需要可以访问 registry 的镜像(mirror).

  2. 配置复制存储库,这是 MTC 用来迁移数据的中间对象存储。

    源和目标集群必须有对复制仓库的不受限制的网络访问权限。在受限环境中,您可以使用内部托管的 S3 存储存储库。如果使用代理服务器,您必须将其配置为允许复制仓库和集群间的网络流量。

  3. 在 MTC web 控制台中添加源集群。
  4. 在 MTC web 控制台中添加复制存储库。
  5. 创建迁移计划,包含以下数据迁移选项之一:

    • Copy:MTC 将数据从源集群复制到复制存储库,再从复制存储库把数据复制到目标集群。

      注意

      如果您使用直接镜像迁移或直接卷迁移,则镜像或卷会直接从源集群复制到目标集群。

      迁移 PV 复制
    • Move:MTC 从源集群中卸载一个远程卷(例如 NFS),在目标集群上创建一个指向这个远程卷的 PV 资源,然后在目标集群中挂载远程卷。在目标集群中运行的应用程序使用源集群使用的同一远程卷。远程卷必须可以被源集群和目标集群访问。

      注意

      虽然复制仓库没有出现在此图表中,但迁移需要它。

      迁移 PV 移动
  6. 运行迁移计划,使用以下选项之一:

    • Stage (可选)在不停止应用程序的情况下将数据复制到目标集群。

      Stage 可以多次运行,以便在迁移前将大多数数据复制到目标。这可最小化迁移和应用程序停机时间。

    • Migrate 在源集群中停止应用程序,并在目标集群中重新创建其资源。您可以选择在不停止应用程序的情况下迁移工作负载。
OCP 3 到 4 的应用程序迁移

2.1.2. 容器自定义资源迁移工具

MTC 会创建以下自定义资源(CR):

migration architecture diagram

20 MigCluster (配置, MTC 集群): 集群定义

20 MigStorage (配置, MTC 集群): Storage 定义

20 MigPlan (配置, MTC 集群):迁移计划

MigPlan CR 描述了要迁移的源和目标集群、复制仓库和命名空间。它与 0 个、1 个或多个 MigMigration CR 关联。

注意

删除 MigPlan CR 会删除关联的 MigMigration CR。

20 BackupStorageLocation (配置, MTC 集群): Velero 备份对象的位置

20 VolumeSnapshotLocation (配置, MTC 集群): Velero 卷快照的位置

20 MigMigration (操作,MTC 集群)::迁移,在每次进行 stage 或迁移数据时创建。每个 MigMigration CR 都与 MigPlan CR 关联。

20 Backup(操作,源集群):当运行迁移计划时,MigMigration CR 在每个源集群上创建两个 Velero 备份 CR:

  • 备份 CR #1 用于Kubernetes 对象
  • 备份 CR #2 用于 PV 数据

20 Restore (操作,目标集群):在运行迁移计划时,MigMigration CR 在目标集群上创建两个 Velero 恢复 CR:

  • 恢复 CR #1(使用备份 CR #2)用于 PV 数据
  • 恢复 CR #2(使用备份 CR #1)用于 Kubernetes 对象

2.1.3. 关于数据复制方法

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

2.1.3.1. 文件系统复制方法

MTC 工具将数据文件从源集群复制到复制存储库,并从那里复制到目标集群。

表 2.1. 文件系统复制方法概述

优点限制:
  • 集群可以有不同的存储类
  • 所有 S3 存储供应商均支持
  • 使用 checksum 验证数据(可选)
  • 比快照复制方法慢
  • 可选的数据校验可能会显著降低性能

2.1.3.2. 快照复制方法

MTC 将源集群数据的快照复制到云供应商的复制仓库。数据在目标集群上恢复。

AWS、Google Cloud Provider 和 Microsoft Azure 支持快照复制方法。

表 2.2. 快照复制方法概述

优点限制:
  • 比文件系统复制方法快
  • 云供应商必须支持快照。
  • 集群必须位于相同的云供应商。
  • 集群必须位于同一位置或区域。
  • 集群必须具有相同的存储类。
  • 存储类必须与快照兼容。

2.1.4. 关于迁移 hook

在使用 MTC 进行迁移的特定时间点上,可以使用迁移 hook 运行自定义代码。您可以在单个迁移计划中添加最多四个迁移 hook,每个 hook 在迁移过程的不同阶段运行。

迁移 hook 执行的任务包括自定义应用程序默认、手动迁移不受支持的数据类型以及在迁移后更新应用程序。

迁移 hook 会在以下迁移步骤之一中,在源或目标集群上运行:

  • PreBackup:在源集群中备份资源前
  • PostBackup:在源集群中备份资源后
  • PreRestore:在目标集群上恢复资源前
  • PostRestore:在目标集群中恢复资源后

您可以使用 Ansible playbook 或自定义 hook 容器创建 hook。

Ansible playbook

Ansible playbook 作为一个配置映射挂载到 hook 容器上。hook 容器使用 MigPlan 自定义资源(CR)中指定的集群、服务帐户和命名空间以作业的形式运行。作业会继续运行,直到达到默认限制的 6 次重试或成功完成为止。即使初始 pod 被驱除或终止,也会继续。

默认 Ansible 运行时镜像为 registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.4。此镜像基于 Ansible Runner 镜像,并包含 Ansible Kubernetes 资源的 python-openshift,以及更新的 oc 二进制文件。

可选: 您可以使用包含其他 Ansible 模块或工具的自定义 Ansible 运行时镜像,而不是默认镜像。

自定义 hook 容器

您可以创建包含 Ansible playbook 或自定义代码的自定义 hook 容器。

2.2. 安装并升级 MTC

您可以在 OpenShift Container Platform 4.5 目标集群和 4.1 源集群中安装 MTC。

MTC 默认安装在目标集群上。您可以在 OpenShift Container Platform 3 集群或远程集群中安装 MTC。

2.2.1. 在连接的环境中安装 MTC

您可以在连接的环境中安装 MTC。

重要

您必须在所有集群中安装相同的 MTC 版本。

2.2.1.1. 在 OpenShift Container Platform 4.5 目标集群上安装 MTC

您可以在 OpenShift Container Platform 4.5 目标集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 点击 Create
  8. WorkloadsPods 来验证 MTC pod 正在运行 。

2.2.1.2. 在 OpenShift Container Platform 4.1 源集群上安装 MTC

您可以在 OpenShift Container Platform 4 源集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 CatalogOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 更新 migration-controller 自定义资源清单中的以下参数:

    spec:
    ...
      migration_controller: false
      migration_ui: false
    ...
      deprecated_cors_configuration: true 1
    1
    添加 deprecated_cors_configuration 参数及其值。
  8. 点击 Create
  9. WorkloadsPods 来验证 MTC pod 正在运行 。

2.2.2. 在受限环境中安装 MTC

您可以在受限环境中安装 MTC。

重要

您必须在所有集群中安装相同的 MTC 版本。

您可以为 OpenShift Container Platform 4 构建自定义 Operator 目录镜像,将其推送到本地镜像 registry,并将 Operator Lifecycle Manager(OLM)配置为从本地 registry 安装 Containers Operator 的 Migration Toolkit for Containers Operator。

2.2.2.1. 构建 Operator 目录镜像

集群管理员可以根据 Operator Lifecycle Manager(OLM)使用的 Package Manifest Format 来构建自定义 Operator 目录镜像。目录镜像可推送到支持 Docker v2-2 的容器镜像 registry。对于受限网络中的集群,此 registry 可以是集群有网络访问权限的 registry,如在受限网络集群安装过程中创建的镜像 registry。

重要

OpenShift Container Platform 集群的内部 registry 不能用作目标 registry,因为它不支持没有标签的推送(在镜像过程中需要这个功能)。

在这一示例中,流程假定在使用镜像 registry 时可访问您的网络以及互联网。

注意

只有 oc 客户端的 Linux 版本可用于此流程,因为 Windows 和 macOS 版本不提供 oc adm catalog build 命令。

先决条件

  • 没有网络访问限制的工作站
  • oc 版本 4.3.5+ Linux 客户端
  • podman 1.4.4+ 版
  • 访问支持 Docker v2-2 的镜像(mirror)registry
  • 如果您正在使用私有 registry,请将 REG_CREDS 环境变量设置为到 registry 凭证的文件路径。例如,对于 podman CLI:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • 如果您正在使用 quay.io 帐户可访问的私有命名空间,您必须设置 Quay 身份验证令牌。使用您的 quay.io 凭证对登录 API 发出请求,从而设置用于 --auth-token 标志的 AUTH_TOKEN 环境变量:

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

流程

  1. 在没有网络访问限制的工作站中,与目标镜像(mirror) registry 进行身份验证:

    $ podman login <registry_host_name>

    还可使用 registry.redhat.io 验证,以便在构建期间拉取基础镜像:

    $ podman login registry.redhat.io
  2. 根据 Quay.io 中的 redhat-operators 目录构建目录镜像,进行标记并将其推送到您的镜像 registry:

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    从 App Registry 实例中拉取的机构(命名空间)。
    2
    使用与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签,将 --from 设置为 ose-operator-registry 基础镜像。
    3
    --filter-by-os 设置为用于基本镜像的操作系统和架构,该镜像必须与目标 OpenShift Container Platform 集群匹配。有效值是 linux/amd64linux/ppc64lelinux/s390x
    4
    为您的目录镜像命名并包含标签,例如: v1
    5
    可选:如果需要,指定 registry 凭证文件的位置。
    6
    可选:如果您不想为目标 registry 配置信任,请添加 --insecure 标志。
    7
    可选:如果使用其他不公开的应用程序 registry 目录,则需要指定 Quay 身份验证令牌。

    输出示例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

    有时红帽提供的无效清单是意外引入的目录 ; 当发生这种情况时,您可能会看到一些错误:

    出错的输出示例

    ...
    INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
    W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
    Uploading ... 244.9kB/s

    这些错误通常不是致命的,如果所提及 Operator 软件包不包含您计划安装的 Operator 或其依赖项,则可以忽略它们。

2.2.2.2. 针对受限网络配置 OperatorHub

集群管理员可以使用自定义 Operator 目录镜像将 OLM 和 OperatorHub 配置为在受限网络环境中使用本地内容。本例中的流程使用之前构建并推送到受支持的 registry 的自定义 redhat-operators 目录镜像。

先决条件

  • 没有网络访问限制的工作站
  • 推送到受支持的 registry 的自定义 Operator 目录镜像
  • oc 版本 4.3.5+
  • podman 1.4.4+ 版
  • 访问支持 Docker v2-2 的镜像(mirror)registry
  • 如果您正在使用私有 registry,请将 REG_CREDS 环境变量设置为到 registry 凭证的文件路径。例如,对于 podman CLI:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

流程

  1. oc adm catalog mirror 命令提取自定义 Operator catalog 镜像的内容,以生成镜像(mirror)所需的清单:您可以选择:

    • 允许该命令的默认行为在生成清单后自动将所有镜像内容镜像到您的镜像 registry 中,或者
    • 添加 --manifests-only 标志来只生成镜像所需的清单,但并不实际将镜像内容镜像到 registry。这对检查哪些要镜像(mirror)非常有用。如果您只需要部分内容的话,可以对映射列表做出任何修改。然后,您可以使用该文件与 oc image mirror 命令一起,在以后的步骤中镜像修改的镜像列表。

    在没有网络访问限制的工作站中,运行以下命令:

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v1 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' \4
        [--manifests-only] 5
    1
    指定 Operator 目录镜像。
    2
    可选:如果需要,指定 registry 凭证文件的位置。
    3
    可选:如果您不想为目标 registry 配置信任,请添加 --insecure 标志。
    4
    由于对多个构架支持的已知问题,当前需要此标志。
    5
    可选:只生成镜像所需的清单,但并不实际将镜像内容镜像到 registry。
    警告

    如果未设置 --filter-by-os 标志或设置为 .* 以外的任何值,该命令会过滤不同的架构,用来更改清单列表摘要,也称为 多架构镜像。不正确的摘要会导致在断开连接的集群中部署这些镜像和 Operator 失败。如需更多信息,请参阅 BZ#1890951

    输出示例

    using database path mapping: /:/tmp/190214037
    wrote database to /tmp/190214037
    using database at: /tmp/190214037/bundles.db 1
    ...

    1
    命令生成的临时数据库。

    在运行命令后,会在当前目录中生成 <image_name>-manifests/ 目录以及以下文件:

    • 用来定义 ImageContentSourcePolicy 对象的 imageContentSourcePolicy.yaml,它可以将节点配置为在 Operator 清单中存储的镜像(image)引用和镜像 (mirror) 的 registry 间进行转换。
    • mapping.txt 文件,在其中包含所有源镜像,并将它们映射到目标 registry。此文件与 oc image mirror 命令兼容,可用于进一步自定义镜像(mirror)配置。
  2. 如果您在上一步中使用 --manifests-only 标志,并只想镜像部分内容:

    1. mapping.txt 文件中的镜像列表改为您的规格。如果您不确定要镜像的镜像子集的名称和版本,请使用以下步骤查找:

      1. oc adm catalog mirror 命令生成的临时数据库运行 sqlite3 工具,以检索与一般搜索查询匹配的镜像列表。输出以后如何编辑 mapping.txt 文件的帮助信息。

        例如,要检索与字符串 clusterlogging.4.3 类似的镜像列表:

        $ echo "select * from related_image \
            where operatorbundle_name like 'clusterlogging.4.3%';" \
            | sqlite3 -line /tmp/190214037/bundles.db 1
        1
        请参阅 oc adm catalog mirror 命令的输出结果来查找数据库文件的路径。

        输出示例

        image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        
        image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        ...

      2. 使用上一步的结果来编辑 mapping.txt 文件,使其只包含您要镜像的镜像子集。

        例如,您可以使用前面示例输出中的 image 值来找出您的 mapping.txt 文件中存在以下匹配行:

        mapping.txt 中的匹配镜像映射

        registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

        在这个示例中,如果您只想镜像这些 image,可以在 mapping.txt 文件中删除所有其他条目,仅保留上述两行。

    2. 在您的没有网络访问限制的工作站中,使用您修改的 mapping.txt 文件,使用 oc image mirror 命令将镜像镜像到 registry:

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt
      警告

      如果未设置 --filter-by-os 标志或设置为 .* 以外的任何值,该命令会过滤不同的架构,用来更改清单列表摘要,也称为 多架构镜像。不正确的摘要会导致在断开连接的集群中部署这些镜像和 Operator 失败。

  3. 应用 ImageContentSourcePolicy 对象:

    $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml
  4. 创建一个 CatalogSource 对象来引用您的目录镜像。

    1. 按照您的规格修改以下内容,并将它保存为 catalogsource.yaml 文件:

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc
      1
      指定您的自定义 Operator 目录镜像。
    2. 使用该文件创建 CatalogSource 对象:

      $ oc create -f catalogsource.yaml
  5. 确定成功创建以下资源。

    1. 检查 pod:

      $ oc get pods -n openshift-marketplace

      输出示例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 检查目录源:

      $ oc get catalogsource -n openshift-marketplace

      输出示例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 检查软件包清单:

      $ oc get packagemanifest -n openshift-marketplace

      输出示例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

现在,您可在受限网络 OpenShift Container Platform 集群的 web 控制台中,通过 OperatorHub 安装 Operator。

2.2.2.3. 在一个受限的环境中的 OpenShift Container Platform 4.5 目标集群上安装 MTC

您可以在 OpenShift Container Platform 4.5 目标集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须创建自定义 Operator 目录并将其推送到镜像 registry。
  • 您必须将 Operator Lifecycle Manager 配置为从镜像 registry 安装 MTC Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 点击 Create
  8. WorkloadsPods 来验证 MTC pod 正在运行 。

2.2.2.4. 在一个受限的环境中的 OpenShift Container Platform 4.1 源集群上安装 MTC

您可以在 OpenShift Container Platform 4 源集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须创建自定义 Operator 目录并将其推送到镜像 registry。
  • 您必须将 Operator Lifecycle Manager 配置为从镜像 registry 安装 MTC Operator。

流程

  1. 使用 Filter by keyword 字段查找 MTCs Operator
  2. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  3. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  4. Migration Toolkit for Containers Operator
  5. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  6. 点击 Create
  7. WorkloadsPods 来验证 MTC pod 正在运行 。

2.2.3. 升级 MTC

您可以使用 OpenShift Container Platform Web 控制台升级 MTC。

重要

您必须确保在所有集群中安装相同的 MTC 版本。

如果要升级 MTC 1.3,您必须执行额外步骤来更新 MigPlan 自定义资源(CR)。

2.2.3.1. 在 OpenShift Container Platform 4 集群中升级 MTC

您可以使用 OpenShift Container Platform Web 控制台在 OpenShift Container Platform 4 集群上升级 MTC。

先决条件

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

流程

  1. 在 OpenShift Container Platform 控制台中导航至 OperatorsInstalled Operators

    处于待定升级的 operator 会显示 Upgrade available 状态。

  2. Migration Toolkit for Containers Operator
  3. Subscription 标签页。任何需要批准的升级都会在 Upgrade Status 旁边显示。例如:它可能会显示 1 requires approval
  4. 1 requires approval,然后点 Preview Install Plan
  5. 查看列出可用于升级的资源,并点 Approve
  6. 返回 Operators → Installed Operators 页面来监控升级的过程。完成后,状态会变为 SucceededUp to date
  7. Migration Toolkit for Containers Operator
  8. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  9. 如果要在集群中升级 MTC,更新 MigrationController 自定义资源(CR)清单中的以下参数:

    spec:
    ...
      migration_controller: false
      migration_ui: false
    ...
      deprecated_cors_configuration: true

    您不需要更新目标集群上的 MigrationController CR 清单。

  10. 点击 Create
  11. WorkloadsPods 来验证 MTC pod 正在运行 。

2.2.3.2. 将 MTC 1.3 升级到 1.4

如果要将 MTC 版本 1.3.x 升级到 1.4,您必须更新运行 MigrationController Pod 的集群中的 MigPlan 自定义资源(CR)清单。

由于 MTC 1.3 中不存在 indirectImageMigrationindirectVolumeMigration 参数,它们在 1.4 版中的默认值会为 false,这意味着启用了直接镜像迁移和直接卷迁移。由于没有满足直接迁移要求,迁移计划无法变为 Ready 状态,除非将这些参数值改为 true

先决条件

  • 已安装了 MTC 1.3。
  • 您必须以具有 cluster-admin 权限的用户身份登录。

流程

  1. 登录到运行 MigrationController Pod 的集群。
  2. 获取 MigPlan CR 清单:

    $ oc get migplan <migplan> -o yaml -n openshift-migration
  3. 更新以下参数值,并将文件保存为 migplan.yaml

    ...
    spec:
      indirectImageMigration: true
      indirectVolumeMigration: true
  4. 替换 MigPlan CR 清单以应用更改:

    $ oc replace -f migplan.yaml -n openshift-migration
  5. 获取更新的 MigPlan CR 清单以验证更改:

    $ oc get migplan <migplan> -o yaml -n openshift-migration

2.3. 为复制存储库配置对象存储

您必须将对象存储配置为用作复制存储库。MTC 将数据从源集群复制到复制存储库,然后从复制存储库复制到目标集群。

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

支持以下存储供应商:

在受限环境中,您可以创建一个内部托管的复制存储库。

先决条件

  • 所有集群都必须具有对复制存储库的不间断网络访问权限。
  • 如果您将代理服务器与内部托管的复制存储库搭配使用,您必须确保代理允许访问复制存储库。

2.3.1. 配置 MCG 存储桶做为复制存储库

您可以安装 OpenShift Container Storage Operator,并将一个 Multi-Cloud Object Gateway(MCG)存储桶配置为 Migration Toolkit for Containers(MTC)的复制仓库。

2.3.1.1. 安装 OpenShift Container Storage Operator

您可以从 OperatorHub 安装 OpenShift Container Storage Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword (本例中为 OCS)来查找 OpenShift Container Storage Operator
  3. 选择 OpenShift Container Storage Operator 并点 Install
  4. 选择一个 Update ChannelInstallation ModeApproval Strategy
  5. 点击 Install

    Installed Operators 页面中,OpenShift Container Storage Operator 会出现在 openshift-storage 项目中,状态为 Succeeded

2.3.1.2. 创建 Multi-Cloud Object Gateway 存储桶

您可以创建 Multi-Cloud Object Gateway(MCG)存储桶的自定义资源(CR)。

流程

  1. 登录到 OpenShift Container Platform 集群:

    $ oc login
  2. 使用以下内容创建 NooBaa CR 配置文件,noobaa.yml

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    对于非常小的集群,您可以将 cpu 的值改为 0.1
  3. 创建 NooBaa 对象:

    $ oc create -f noobaa.yml
  4. 使用以下内容创建 BackingStore CR 配置文件,bs.yml

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: mcg-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    指定持久性卷池中的卷数量。
    2
    指定卷的大小。
    3
    指定存储类。
  5. 创建 BackingStore 对象:

    $ oc create -f bs.yml
  6. 使用以下内容创建 BucketClass CR 配置文件,bc.yml

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: mcg-pv-pool-bc
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - mcg-pv-pool-bs
          placement: Spread
  7. 创建 BucketClass 对象:

    $ oc create -f bc.yml
  8. 使用以下内容创建 ObjectBucketClaim CR 配置文件,obc.yml

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    1
    记录在 MTC web 控制台中添加复制存储库的存储桶名称。
  9. 创建 ObjectBucketClaim 对象:

    $ oc create -f obc.yml
  10. 监控资源创建过程以验证 ObjectBucketClaim 的状态变为 Bound

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    这个过程可能需要五到十分钟。

  11. 获取并记录以下值,当您将复制存储库添加到 MTC web 控制台时需要这些值:

    • S3 端点:

      $ oc get route -n openshift-storage s3
    • S3 provider access key:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 provider secret access key:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

2.3.2. 将 AWS S3 存储桶配置为复制存储库

您可以将 AWS S3 存储桶配置为 MTC 的 Migration Toolkit 的复制仓库。

先决条件

  • AWS S3 存储桶必须可以被源和目标集群访问。
  • 您必须安装了 AWS CLI
  • 如果您使用快照复制方法:

    • 您必须有权访问 EC2 Elastic Block Storage (EBS)。
    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 创建 AWS S3 存储桶:

    $ aws s3api create-bucket \
        --bucket <bucket_name> \ 1
        --region <bucket_region> 2
    1
    指定 S3 存储桶名称。
    2
    指定 S3 存储桶区域,例如 us-east-1
  2. 创建 IAM 用户 velero

    $ aws iam create-user --user-name velero
  3. 创建 EC2 EBS 快照策略:

    $ cat > velero-ec2-snapshot-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
  4. 为一个或所有 S3 存储桶创建 AWS S3 访问策略:

    $ cat > velero-s3-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 2
                ]
            }
        ]
    }
    EOF
    1 2
    要授予对单一 S3 存储桶的访问权限,请指定存储桶名称。要授予对所有 AWS S3 存储桶的访问权限,请指定 * 而不是存储桶名称,如下例所示:

    输出示例

    "Resource": [
        "arn:aws:s3:::*"

  5. 将 EC2 EBS 策略附加到 velero

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-ebs \
      --policy-document file://velero-ec2-snapshot-policy.json
  6. 将 AWS S3 策略附加到 velero

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-s3 \
      --policy-document file://velero-s3-policy.json
  7. velero 创建访问密钥:

    $ aws iam create-access-key --user-name velero
    {
      "AccessKey": {
            "UserName": "velero",
            "Status": "Active",
            "CreateDate": "2017-07-31T22:24:41.576Z",
            "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>, 1
            "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
        }
    }
    1 2
    记录 AWS_SECRET_ACCESS_KEYAWS_ACCESS_KEY_ID 以将 AWS 存储库添加到 MTC web 控制台。

2.3.3. 将 Google Cloud Provider 存储桶配置为复制存储库

您可以将 Google Cloud Provider(GCP)存储桶配置为 MTC 的 Migration Toolkit for Containers 复制仓库。

先决条件

  • AWS S3 存储桶必须可以被源和目标集群访问。
  • 您必须安装了 gsutil
  • 如果您使用快照复制方法:

    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 登录到 gsutil:

    $ gsutil init

    输出示例

    Welcome! This command will take you through the configuration of gcloud.
    
    Your current configuration has been set to: [default]
    
    To continue, you must login. Would you like to login (Y/n)?

  2. 设置 BUCKET 变量:

    $ BUCKET=<bucket_name> 1
    1
    指定存储桶名称。
  3. 创建存储桶:

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 变量设置为您的活跃项目:

    $ PROJECT_ID=`gcloud config get-value project`
  5. 创建 velero IAM 服务帐户:

    $ gcloud iam service-accounts create velero \
        --display-name "Velero Storage"
  6. 创建 SERVICE_ACCOUNT_EMAIL 变量:

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
      --filter="displayName:Velero Storage" \
      --format 'value(email)'`
  7. 创建 ROLE_PERMISSIONS 变量:

    $ ROLE_PERMISSIONS=(
        compute.disks.get
        compute.disks.create
        compute.disks.createSnapshot
        compute.snapshots.get
        compute.snapshots.create
        compute.snapshots.useReadOnly
        compute.snapshots.delete
        compute.zones.get
    )
  8. 创建 velero.server 自定义角色:

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  9. 为项目添加 IAM 策略绑定:

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  10. 更新 IAM 服务帐户:

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  11. 将 IAM 服务帐户的密钥保存到当前目录中的 credentials-velero 文件中:

    $ gcloud iam service-accounts keys create credentials-velero \
      --iam-account $SERVICE_ACCOUNT_EMAIL

2.3.4. 将 Microsoft Azure Blob 存储容器配置为复制存储库

您可以将 Microsoft Azure Blob 存储容器配置为 Migration Toolkit for Containers(MTC)的复制仓库。

先决条件

  • 您必须具有 Azure 存储帐户
  • 您必须安装了 Azure CLI
  • Azure Blob 存储容器必须可以被源和目标集群访问。
  • 如果您使用快照复制方法:

    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 设置 AZURE_RESOURCE_GROUP 变量:

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  2. 创建 Azure 资源组:

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    指定位置。
  3. 设置 AZURE_STORAGE_ACCOUNT_ID 变量:

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
  4. 创建 Azure 存储帐户:

    $ az storage account create \
      --name $AZURE_STORAGE_ACCOUNT_ID \
      --resource-group $AZURE_RESOURCE_GROUP \
      --sku Standard_GRS \
      --encryption-services blob \
      --https-only true \
      --kind BlobStorage \
      --access-tier Hot
  5. 设置 BLOB_CONTAINER 变量:

    $ BLOB_CONTAINER=velero
  6. 创建 Azure Blob 存储容器:

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  7. velero 创建服务主体和凭证:

    $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
      AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
      AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" --role "Contributor" --query 'password' -o tsv` \
      AZURE_CLIENT_ID=`az ad sp list --display-name "velero" --query '[0].appId' -o tsv`
  8. credentials-velero 文件中保存服务主体的凭证:

    $ cat << EOF  > ./credentials-velero
    AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
    AZURE_TENANT_ID=${AZURE_TENANT_ID}
    AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
    AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
    AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
    AZURE_CLOUD_NAME=AzurePublicCloud
    EOF

2.4. 迁移应用程序

您可以使用 Migration Toolkit for Containers(MTC)web 控制台或命令行来迁移应用程序。

2.4.1. 先决条件

MTC(Migration Toolkit for Containers)有以下先决条件:

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 在所有集群中,MTC 版本必须相同。
  • Clusters:

    • 源集群必须升级到最新的 MTC z-stream 版本。
    • 运行 migration-controller pod 的集群必须具有对其他集群的不受限制的网络访问权限。
    • 集群必须具有相互无限的网络访问权限。
    • 集群必须具有对复制存储库的不受限制的网络访问权限。
    • 集群必须能够使用端口 443 上的 OpenShift 路由进行通信。
    • 集群不能有关键条件。
    • 集群必须处于 ready 状态。
  • 卷迁移:

    • 持久性卷(PV)必须有效。
    • PV 必须绑定到持久性卷声明。
    • 如果使用 move 方法复制 PV,集群必须具有对远程卷的不受限制的网络访问权限。
    • 如果使用快照复制方法复制 PV,则适用以下先决条件:

      • 云供应商必须支持快照。
      • 卷必须具有相同的云供应商。
      • 卷必须位于同一区域。
      • 卷必须具有相同的存储类。
  • 如果在代理环境中执行直接卷迁移,您必须配置 Stunnel TCP 代理。
  • 如果执行直接镜像迁移,您必须将源集群的内部 registry 公开给外部流量。

2.4.1.1. 创建 CA 证书捆绑包文件

如果您使用自签名证书来保护集群或 MTC 的 Migration Toolkit 的复制仓库的安全,则证书验证可能会失败,并显示以下错误消息: Certificate signed by unknown authority

您可以创建自定义 CA 证书捆绑包文件,并在添加集群或复制存储库时将其上传到 MTC web 控制台。

流程

从远程端点下载 CA 证书,并将其保存为 CA 捆绑包文件:

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
1
指定端点的主机 FQDN 和端口,如 api.my-cluster.example.com:6443
2
指定 CA 捆绑包文件的名称。

2.4.1.2. 为直接卷迁移配置代理

如果要从代理后面的源集群执行直接卷迁移,您必须在 MigrationController 自定义资源(CR)中配置 Stunnel 代理。stunnel 在源和目标集群之间为 TCP 连接创建透明的隧道,而不更改证书。

注意

直接卷迁移只支持一个代理。如果目标集群也位于代理后面,则源集群无法访问目标集群的路由。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 登录到运行 MigrationController Pod 的集群。
  2. 获取 MigrationController CR 清单:

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. 添加 stunnel_tcp_proxy 参数:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    指定 Stunnel 代理: http://<user_name>:<password>@<ip_address>:<port>
  4. 将清单保存为 migration-controller.yaml
  5. 应用更新的清单:

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

2.4.1.3. 为迁移 hook 编写 Ansible playbook

您可以编写 Ansible playbook 以用作迁移 hook。通过使用 MTC web 控制台或在 MigPlan 自定义资源(CR)清单中指定 spec.hooks 参数的值来在迁移计划中添加 hook。

Ansible playbook 作为一个配置映射挂载到 hook 容器上。hook 容器使用 MigPlan CR 中指定的集群、服务帐户和命名空间以作业的形式运行。hook 容器使用指定的服务帐户令牌,以便当任务在集群中运行前无需进行身份验证。

2.4.1.3.1. Ansible 模块

您可以使用 Ansible shell 模块来运行 oc 命令。

shell 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces

您可以使用 kubernetes.core 模块(如 k8s_info )与 Kubernetes 资源交互。

k8s_facts 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"

在非零退出状态通常不会生成的情况下,可以使用 fail 模块生成一个非零退出状态,以确保可以检测到 hook 的成功或失败。hook 以作业形式运行,hook 的成功或失败状态取决于作业容器的退出状态。

fail 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail

2.4.1.3.2. 环境变量

MigPlan CR 名称和迁移命名空间作为环境变量传递给 hook 容器。这些变量可使用 lookup 插件访问。

环境变量示例

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'migration_namespaces')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'migplan_name') }}"

2.4.1.4. 其他资源

2.4.2. 使用 MTC web 控制台迁移应用程序

您可以使用 MTC web 控制台配置集群和复制存储库。然后,您可以创建并运行迁移计划。

2.4.2.1. 启动 MTC web 控制台

您可以在浏览器中启动 MTC web 控制台。

先决条件

  • MTC web 控制台必须具有到 OpenShift Container Platform Web 控制台的网络访问权限。
  • MTC web 控制台必须具有到 OAuth 授权服务器的网络访问权限。

流程

  1. 登录到已安装 MTC 的 OpenShift Container Platform 集群。
  2. 输入以下命令来获取 MTC web 控制台 URL:

    $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

    输出类似于以下: https://migration-openshift-migration.apps.cluster.openshift.com

  3. 启动浏览器并进入 MTC web 控制台。

    注意

    如果在安装 MTC 工具套件 Operator 后尝试立即访问 MTC web 控制台,则该控制台可能无法加载,因为 Operator 仍然在配置集群。等待几分钟后重试。

  4. 如果您使用自签名的 CA 证书,则会提示您接受源集群 API 服务器的 CA 证书。网页会引导您接受剩余证书的过程。
  5. 使用 OpenShift Container Platform 的用户名密码进行登陆。

2.4.2.2. 在 MTC web 控制台中添加集群

您可以在 MTC web 控制台中添加一个集群到 Migration Toolkit for Containers(MTC)web 控制台。

先决条件

  • 如果要使用 Azure 快照复制数据:

    • 您必须为集群指定 Azure 资源组名称。
    • 集群必须位于同一 Azure 资源组中。
    • 集群必须位于同一地理位置。

流程

  1. 登录到集群。
  2. 获取 migration-controller 服务帐户令牌:

    $ oc sa get-token migration-controller -n openshift-migration
    eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ
  3. 在 MTC web 控制台中点 Clusters
  4. Add cluster
  5. 填写以下字段:

    • Cluster name:集群名称可包含小写字母(a-z)和数字(0-9)。它不能包含空格或国际字符。
    • URL:指定 API 服务器 URL,例如 https://<www.example.com>:8443
    • Service account token:粘贴 migration-controller 服务帐户令牌。
    • 公开的路由主机到镜像 registry:如果您使用直接镜像迁移,请指定源集群镜像 registry 的公开路由,例如 www.example.apps.cluster.com

      您可以指定一个端口。默认端口为 5000

    • Azure cluster:如果使用 Azure 快照复制数据,您必须选择此选项。
    • Azure resource group:如果选择了 Azure cluster,则会显示此字段。指定 Azure 资源组。
    • 需要 SSL 验证:可选:选择这个选项验证到集群的 SSL 连接。
    • CA bundle file:如果选择了 Require SSL 验证,则会显示此字段。如果您为自签名证书创建了自定义 CA 证书捆绑包文件,请点 Browse,选择 CA 捆绑包文件并上传它。
  6. Add cluster

    集群会出现在 Clusters 列表中。

2.4.2.3. 在 MTC web 控制台中添加复制存储库

您可以将对象存储桶作为复制仓库添加到 MTC 的 web 控制台的 Migration Toolkit for Containers(MTC)web 控制台。

先决条件

  • 您必须配置用于迁移数据的对象存储桶。

流程

  1. 在 MTC web 控制台中点 Replication repositories
  2. Add repository
  3. 选择 Storage provider type 并填写以下字段:

    • AWS 适用于 S3、MCSG 和通用 S3 供应商:

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • S3 bucket name:指定您创建的 S3 存储桶的名称。
      • S3 bucket region:指定 S3 存储桶区域。AWS S3 必填Optional 用于其他 S3 供应商。
      • S3 端点:指定 S3 服务的 URL,而不是存储桶,例如:https://<s3-storage.apps.cluster.com>。通用 S3 供应商必填。您必须使用 https:// 前缀。
      • S3 provider access key:为 AWS 指定 <AWS_SECRET_ACCESS_KEY> ,或者为 MCG 指定 S3 供应商访问密钥。
      • S3 provider secret access key:为 AWS 指定 <AWS_ACCESS_KEY_ID> ,或者为 MCG 指定 S3 供应商 secret 访问密钥。
      • Require SSL verification:如果您使用的是通用 S3 供应商,则清除此复选框。
      • 如果您使用自定义 CA 捆绑包,请点击 Browse 并浏览到所需的 Base64 编码的 CA 捆绑包文件。
    • GCP

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • GCP bucket name:指定 GCP 存储桶的名称。
      • GCP credential JSON blob:在 credentials-velero 文件中指定字符串。
    • Azure

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • Azure resource group:指定 Azure Blob 存储的资源组。
      • Azure storage account name:指定 Azure Blob 存储帐户名称
      • Azure credentials - INI file contents:在 credentials-velero 文件中指定字符串。
  4. Add repository 并等待连接验证。
  5. Close

    新仓库会出现在 Replication repositories 列表中。

2.4.2.4. 在 MTC web 控制台中创建迁移计划

您可以在 Migration Toolkit for Containers(MTC)web 控制台中创建一个迁移计划。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须确保在所有集群中安装相同的 MTC 版本。
  • 您必须在 MTC web 控制台中添加集群和复制存储库。
  • 如果要使用 move 数据复制方法迁移持久性卷(PV),则源和目标集群必须有对远程卷的不间断网络访问权限。
  • 如果要使用直接镜像迁移,源集群的 MigCluster 自定义资源清单必须指定内部镜像 registry 的公开路由。

流程

  1. 在 MTC web 控制台中点 Migration Plan
  2. Add migration plan
  3. 输入 Plan name 并点 Next

    迁移计划名称不能超过 253 个小写字母数字字符(a-z, 0-9),且不能包含空格或下划线(_)。

  4. 选一个 Source cluster
  5. 选一个 Target cluster
  6. 选一个 Replication repository
  7. 选择要迁移的项目并点 Next
  8. 选择 Source clusterTarget clusterRepository,然后点 Next
  9. Namespaces 页面中,选择要迁移的项目并点 Next
  10. Persistent volumes 页面中,点每个 PV 的 迁移类型

    • Copy 选项将源集群的 PV 中的数据复制到复制存储库中,然后在目标集群中恢复新创建的具有类似特征的 PV 上的数据。
    • Move 选项从源集群中卸载一个远程卷(例如 NFS),在目标集群上创建一个指向这个远程卷的 PV 资源,然后在目标集群中挂载远程卷。在目标集群中运行的应用程序使用源集群使用的同一远程卷。
  11. Next
  12. Copy options 页面中,为每个 PV 选择 Copy method:

    • 快照复制使用云供应商的快照功能备份和恢复数据。它比 Filesystem copy 要快得多。
    • Filesystem copy 备份源集群中的文件,并在目标集群中恢复它们。

      直接卷迁移需要使用文件系统复制方法。

  13. 您可以选择 Verify copy 来验证使用 Filesystem copy 迁移的数据。数据是通过为每个源文件生成 checksum 并在恢复后检查 checksum 来验证。数据校验可能会显著降低性能
  14. 选择 目标存储类

    如果选择了 Filesystem copy,您可以更改目标存储类。

  15. Next
  16. Migration options 页面上,如果您为源集群指定了公开的镜像 registry 路由,则会选择 Direct 镜像迁移 选项。如果使用 Filesystem copy 迁移数据,Direct PV migration 选项会被选择。

    直接迁移选项将镜像和文件直接从源集群复制到目标集群。这个选项比将源集群的镜像和文件复制到复制存储库,然后再从复制存储库复制到目标集群要快。

  17. Next
  18. 可选:在 Hooks 页中,点 Add Hook 为迁移计划添加 hook。

    hook 运行自定义代码。您可以在单个迁移计划中最多添加四个 hook。每个 hook 在不同的迁移步骤中运行。

    1. 在 web 控制台中输入要显示的 hook 名称。
    2. 如果 hook 是一个 Ansible playbook,请选择 Ansible playbook,然后点 Browse 上传 playbook,或在字段中粘贴 playbook 的内容。
    3. 可选: 如果不使用默认 hook 镜像,请指定 Ansible 运行时镜像。
    4. 如果 hook 不是 Ansible playbook,选择 Custom container image 并指定镜像名称和路径。

      自定义容器镜像可以包含 Ansible playbook。

    5. 选择 Source clusterTarget cluster
    6. 输入 Service account nameService account namespace
    7. 为 hook 选择迁移步骤:

      • preBackup:在应用程序工作负载在源集群中备份前
      • PostBackup:在应用程序工作负载在源集群中备份后
      • preRestore:在目标集群中恢复应用程序工作负载前
      • postRestore:在目标集群中恢复应用程序工作负载后
    8. Add
  19. Finish

    迁移计划显示在 Migration Plan 列表中。

2.4.2.5. 在 MTC web 控制台中运行迁移计划

您可以使用在 Migration Toolkit for Containers(MTC)web 控制台中创建的迁移计划来 stage 或迁移应用程序和数据。

注意

迁移过程中,在目标集群中,MTC 将迁移的持久性卷(PV)的重新声明策略设置为 Retain

Backup 自定义资源包含一个 PVOriginalReclaimPolicy 注解,用于指示原始重新声明策略。您可以手动恢复迁移 PV 的重新声明策略。

先决条件

MTC web 控制台必须包含以下内容:

  • 处于 Ready 状态的源集群
  • 处于 Ready 状态的目标集群
  • 复制软件仓库
  • 有效的迁移计划

流程

  1. 登录到源集群。
  2. 删除旧镜像:

    $ oc adm prune images
  3. 登录到 MTC web 控制台并点 迁移计划
  4. 点击迁移计划 kebab 旁边的 Options 菜单,然后选择 Stage 将数据从源集群复制到目标集群,而不停止应用程序。

    您可以多次运行 Stage 以减少实际迁移时间。

  5. 当您准备好迁移应用程序工作负载时,在迁移计划 kebab 边的 Options 菜单并选择 Migrate
  6. 另外,还可以在 Migrate 窗口中选择 Do not stop applications on the source cluster during migration
  7. Migrate
  8. 迁移完成后,在 OpenShift Container Platform web 控制台中确认已成功迁移了应用程序:

    1. HomeProjects
    2. 点迁移的项目查看其状态。
    3. Routes 部分,点击 Location 验证应用程序是否正常运行。
    4. WorkloadsPods 来验证 pod 是否在迁移的命名空间中运行。
    5. StoragePersistent volumes 确认正确置备了被迁移的持久性卷。

2.4.3. 从命令行迁移应用程序

您可以使用 MTC 自定义资源(CR)在命令行中迁移应用程序。

您可以将应用程序从本地集群迁移到远程集群,从远程集群迁移到本地集群,并在远程集群间进行迁移。

MTC 术语

以下与配置集群相关的术语:

  • host 集群:

    • migration-controller pod 在 host 集群中运行。
    • host 集群不需要有一个公开的安全 registry 路由来直接进行镜像迁移。
  • 本地集群:本地集群通常与 host 集群相同,但这不是必须的。
  • 远程集群:

    • 远程集群必须具有公开的安全 registry 路由才能直接迁移镜像。
    • 远程集群必须具有包含 migration-controller 服务帐户令牌的 Secret CR。

以下与迁移相关的术语:

  • Source cluster(源集群):从中迁移应用程序的集群。
  • 目标集群(Destination cluster):将应用程序迁移到的集群。

2.4.3.1. 使用 MTC API 迁移应用程序

您可以使用 MTC API 在命令行中迁移应用程序。

您可以将应用程序从本地集群迁移到远程集群,从远程集群迁移到本地集群,并在远程集群间进行迁移。

这个步骤描述了如何执行间接迁移和直接迁移:

  • 间接迁移:镜像、卷和 Kubernetes 对象从源集群复制到复制存储库,然后从复制存储库复制到目标集群。
  • 直接迁移: 镜像或卷直接从源集群复制到目标集群。直接镜像迁移和直接卷迁移可显著提高性能。

创建以下自定义资源(CR)来执行迁移:

  • MigCluster CR:定义一个 host、本地或远程集群

    migration-controller pod 在 host 集群中运行。

  • Secret CR:包含远程集群或存储的凭证
  • MigStorage CR:定义一个复制存储库

    不同的存储供应商需要在 MigStorage CR 清单中使用不同的参数。

  • MigPlan CR:定义一个迁移计划
  • MigMigration CR:执行在关联的 MigPlan 中定义的一个迁移

    您可以针对以下目的,为单个 MigPlan CR 创建多个 MigMigration CR:

  • 在运行迁移前,执行一个阶段(stage)迁移(在不停止应用程序的情况下复制大多数数据)。阶段迁移可以提高迁移的性能。
  • 取消正在进行中的迁移
  • 回滚一个已完成的迁移

先决条件

  • 需要在所有集群中都有 cluster-admin 权限。
  • 您必须安装 OpenShift Container Platform CLI(oc)。
  • 您必须在所有集群中安装 MTC Operator。
  • 在所有集群中,安装的 Migration Toolkit for Containers Operator 的版本必须相同。
  • 您必须将对象存储配置为复制存储库。
  • 如果使用直接镜像迁移,则必须在所有远程集群中公开安全 registry 路由。
  • 如果您使用直接卷迁移,源集群不能配置 HTTP 代理。

流程

  1. host 集群创建一个名为 host-cluster.yamlMigCluster CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host 集群创建一个 MigCluster CR:

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. 为每个远程集群创建一个名为 cluster-secret.yamlSecret CR 清单:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    指定远程集群的 base64 编码的 migration-controller 服务帐户(SA)令牌。

    您可以运行以下命令来获取 SA 令牌:

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. 为每个远程集群创建一个 Secret CR:

    $ oc create -f cluster-secret.yaml
  5. 为每个远程集群创建一个名为 remote-cluster.yamlMigCluster CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    可选:指定公开的 registry 路由,例如 docker-registry-default.apps.example.cm,如果使用直接镜像迁移。
    2
    如果 false 则启用 SSL 验证。如果为 true,则不需要 CA 证书或不检查 CA 证书。
    3
    指定远程集群的 Secret CR。
    4
    指定远程集群的 URL。
  6. 为每个远程集群创建一个 MigCluster CR:

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. 验证所有集群是否处于 Ready 状态:

    $ oc describe cluster <cluster_name>
  8. 为名为 storage-secret.yaml 的复制存储库创建 Secret CR 清单:

    apiVersion: v1
    kind: Secret
    metadata:
      namespace: openshift-config
      name: <migstorage_creds>
    type: Opaque
    data:
      aws-access-key-id: <key_id_base64> 1
      aws-secret-access-key: <secret_key_base64> 2
    1
    指定 base64 格式的密钥 ID。
    2
    指定 base64 格式的 secret 密钥。

    AWS 凭证默认为 base64 编码。如果使用另一个存储供应商,则必须使用每个密钥运行以下命令来对凭证进行编码:

    $ echo -n "<key>" | base64 -w 0 1
    1
    指定密钥 ID 或 secret 密钥。这两个密钥都必须都是 base64 编码。
  9. 为复制存储库创建 Secret CR:

    $ oc create -f storage-secret.yaml
  10. 为复制存储库创建一个名为 migstorage.yamlMigStorage CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    指定存储桶名称。
    2
    指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。
    3
    指定存储供应商。
    4
    可选: 如果要使用快照复制数据,请指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。
    5
    可选: 如果您使用快照复制数据,请指定存储供应商。
  11. 创建 MigStorage CR:

    $ oc create -f migstorage.yaml -n openshift-migration
  12. 验证 MigStorage CR 是否处于 Ready 状态:

    $ oc describe migstorage <migstorage_name>
  13. 创建名为 migplan.yamlMigPlan CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    如果为 false,则启用直接镜像迁移。
    2
    如果为 false,则启用直接卷迁移。
    3
    指定 MigStorage CR 实例的名称。
    4
    指定要迁移的一个或多个命名空间。
    5
    指定源集群 MigCluster 实例的名称。
  14. 创建 MigPlan CR:

    $ oc create -f migplan.yaml -n openshift-migration
  15. 查看 MigPlan 实例,以验证它是否处于 Ready 状态:

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. 创建名为 migmigration.yamlMigMigration CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    指定 MigPlan CR 名称。
    2
    如果为 true,则源集群上的 pod 会在迁移前停止。
    3
    如果为 true,则进行阶段(stage)迁移,即在不停止应用程序的情况下复制大多数数据。
    4
    如果为 true,则会回滚到一个已完成的迁移。
  17. 创建 MigMigration CR 以启动 MigPlan CR 中定义的迁移:

    $ oc create -f migmigration.yaml -n openshift-migration
  18. 通过观察 MigMigration CR 来验证迁移的进度:

    $ oc watch migmigration <migmigration_name> -n openshift-migration

    输出类似于以下:

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

2.4.3.2. MTC 自定义资源清单

MTC 使用以下自定义资源(CR)清单来创建用于迁移应用程序的 CR。

2.4.3.2.1. DirectImageMigration

DirectImageMigration CR 直接将镜像从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
指定源集群的 MigCluster CR 名称。
2
指定目标集群的 MigCluster CR 名称。
3
指定包含要迁移的镜像的一个或多个命名空间。
2.4.3.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR 直接将镜像流引用从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
指定源集群的 MigCluster CR 名称。
2
指定目标集群的 MigCluster CR 名称。
3
指定镜像流名称。
4
指定源集群上的镜像流命名空间。
5
指定目标集群上的镜像流命名空间。
2.4.3.2.3. DirectVolumeMigration

DirectVolumeMigration CR 直接将持久性卷(PV)从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <directvolumemigration_name>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: host 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc_name> 4
    namespace: <pvc_namespace> 5
  srcMigClusterRef:
    name: <source_cluster_ref> 6
    namespace: openshift-migration
1
如果为 true,在目标集群上为 PV 创建命名空间。
2
如果为 true,在迁移后会删除 DirectVolumeMigrationProgress CR。默认值为 false,这会保留 DirectVolumeMigrationProgress CR 以便进行故障排除。
3
如果目标集群不是主机集群,请更新集群名称。
4
指定使用直接卷迁移进行迁移的一个或多个 PVC。
5
指定每个 PVC 的命名空间。
6
指定源集群的 MigCluster CR 名称。
2.4.3.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR 显示 DirectVolumeMigration CR 的进度。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directvolumemigrationprogress_name
spec:
  clusterRef:
    name: source_cluster
    namespace: openshift-migration
  podRef:
    name: rsync_pod
    namespace: openshift-migration
2.4.3.2.5. MigAnalytic

MigAnalytic CR 从一个关联的 MigPlan CR 中收集镜像、Kubernetes 资源以及 PV 容量的数量。

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan_name> 1
  name: miganalytic_name
  namespace: openshift-migration
  labels:
    migplan: <migplan_name> 2
spec:
  analyzeImageCount: true 3
  analyzeK8SResources: true 4
  analyzePVCapacity: true 5
  listImages: false 6
  listImagesLimit: 50 7
  migPlanRef:
    name: migplan_name 8
    namespace: openshift-migration
1
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
2
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
3
可选:如果为 true,返回镜像数量。
4
可选:返回 Kubernetes 资源的数量、类型和 API 版本(如果为 true )。
5
可选:如果为 true 则返回 PV 容量。
6
如果为 true,则返回镜像名称列表。默认为 false,因此输出不会过长。
7
可选:指定如果 listImagestrue 时要返回的最大镜像名称数。
8
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
2.4.3.2.6. MigCluster

MigCluster CR 定义一个主机、本地或远程集群。

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  azureResourceGroup: <azure_resource_group> 3
  caBundle: <ca_bundle_base64> 4
  insecure: false 5
  refresh: false 6
# The 'restartRestic' parameter is relevant for a source cluster.
# restartRestic: true 7
# The following parameters are relevant for a remote cluster.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
可选:如果 migration-controller pod 没有在这个集群中运行,则更新集群名称。
2
如果为 true,则 migration-controller pod 在此集群中运行。
3
可选: 如果存储供应商是 Microsoft Azure,请指定资源组。
4
可选:如果您为自签名 CA 证书创建了一个证书捆绑包,且 insecure 参数值为 false,请指定 base64 编码的证书捆绑包。
5
如果 false 则启用 SSL 验证。
6
如果为 true,集群会被验证。
7
如果为 true,在创建 stage pod 后 restic pod 会在源集群中重启。
8
可选:如果您使用直接镜像迁移,请指定远程集群的公开 registry 路径。
9
指定远程集群的 URL。
10
指定远程集群的 Secret CR 名称。
2.4.3.2.7. MigHook

MigHook CR 定义一个 Ansible playbook ,或一个自定义镜像,它在迁移的指定阶段运行任务。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 3
  custom: false 4
  image: <hook_image> 5
  playbook: <ansible_playbook_base64> 6
  targetCluster: source 7
1
可选:此参数的值后附加一个唯一的哈希值,以便每个迁移 hook 都有一个唯一的名称。您不需要指定 name 参数的值。
2
指定迁移 hook 名称,除非指定了 generateName 参数的值。
3
可选:指定 hook 可运行的最大秒数。默认值为 1800
4
如果为 true,则 hook 是一个自定义镜像。自定义镜像可以包括 Ansible,也可以使用不同的编程语言编写。
5
指定自定义镜像,例如 quay.io/konveyor/hook-runner:latest。如果 customtrue,则需要此项。
6
指定整个 base64 编码的 Ansible playbook。如果 customfalse,则必需。
7
指定 hook 要在其上运行的 sourcedestination 集群。
2.4.3.2.8. MigMigration

MigMigration CR 运行一个关联的 MigPlan CR。

您可以针对以下场景,创建多个与同一 MigPlan CR 关联的 MigMigration CR:

  • 您可以运行多个阶段迁移,或增量迁移,以在没有在源集群中停止 pod 的情况下复制数据。运行阶段迁移可提高实际迁移的性能。
  • 您可以取消正在进行中的迁移。
  • 您可以回滚迁移。
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  namespace: openshift-migration
spec:
  canceled: false 1
  rollback: false 2
  stage: false 3
  quiescePods: true 4
  keepAnnotations: true 5
  verify: false 6
  migPlanRef:
    name: <migplan_ref> 7
    namespace: openshift-migration
1
如果为 true,则会取消正在进行中的迁移。
2
如果为 true,则会回滚到一个已完成的迁移。
3
如果为 true,数据会被递增复制,pod 不会在源集群中停止。
4
如果为 true,在迁移的备份阶段后,源集群中的 pod 会被缩减为 0
5
如果为 true,则迁移期间应用的标签和注解将被保留。
6
如果 true ,检查目标集群中迁移的 pod 的状态,并返回处于 Running 状态的 pod 名称。
7
migPlanRef.name:指定关联的 MigPlan CR 的名称。
2.4.3.2.9. MigPlan

MigPlan CR 定义迁移计划的参数。它包含一组使用相同参数迁移的虚拟机。

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migplan_name
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_migcluster_ref> 2
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_migcluster_ref> 3
    namespace: openshift-migration
  hooks: 4
    - executionNamespace: <namespace> 5
      phase: <migration_phase> 6
      reference:
        name: <mighook_name> 7
        namespace: <hook_namespace> 8
      serviceAccount: <service_account> 9
  indirectImageMigration: true 10
  indirectVolumeMigration: false 11
  migStorageRef:
    name: <migstorage_name> 12
    namespace: openshift-migration
  namespaces:
  - <namespace>  13
  refresh: false  14
1
如果为 true,则迁移已完成。您不能为此 MigPlan CR 创建另一个 MigMigration CR。
2
指定源集群 MigCluster CR 的名称。
3
指定目标集群 MigCluster CR 的名称。
4
可选:最多可指定四个迁移 hook。
5
可选:指定运行 hook 的命名空间。
6
可选:指定 hook 运行期间的迁移阶段。一个 hook 可以分配给一个阶段。预期的值包括 PreBackupPostBackupPreRestorePostRestore
7
可选:指定 MigHook CR 的名称。
8
可选:指定 MigHook CR 的命名空间。
9
可选:指定一个具有 cluster-admin 权限的服务帐户。
10
如果为 true,则禁用直接镜像迁移。镜像从源集群复制到复制存储库,并从复制存储库复制到目标集群。
11
如果为 true,则禁用直接卷迁移。PV 从源集群复制到复制存储库,再从复制存储库复制到目标集群。
12
指定 MigStorage CR 的名称。
13
指定一个或多个命名空间。
14
如果为 trueMigPlan CR 会被验证。
2.4.3.2.10. MigStorage

MigStorage CR 描述了复制存储库的对象存储。您可以配置 Amazon Web Services、Microsoft Azure、Google Cloud Storage 和通用 S3 兼容云存储,如 Minio 或 NooBaa。

不同的供应商需要不同的参数。

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migstorage_name
  namespace: openshift-migration
spec:
  backupStorageProvider: <storage_provider> 1
  volumeSnapshotProvider: 2
  backupStorageConfig:
    awsBucketName: 3
    awsRegion: 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: 6
    awsPublicUrl: 7
    awsSignatureVersion: 8
  volumeSnapshotConfig:
    awsRegion: 9
    credsSecretRef:
      namespace: openshift-config
      name: 10
  refresh: false 11
1
指定存储供应商。
2
可选: 如果您使用快照复制方法,请指定存储供应商。
3
如果使用 AWS,请指定存储桶名称。
4
如果使用 AWS,请指定存储桶区域,如 us-east-1
5
指定为 MigStorage CR 创建的 Secret CR 的名称。
6
可选:如果您使用 AWS Key Management Service,请指定该密钥的唯一标识符。
7
可选: 如果授予 AWS 存储桶的公共访问权限,请指定存储桶 URL。
8
可选:指定向存储桶验证请求的 AWS 签名版本,例如 4
9
可选:如果您使用快照复制方法,请指定集群的地理位置。
10
可选:如果您使用快照复制方法,请指定为 MigStorage CR 创建的 Secret CR 名称。
11
如果为 true,集群会被验证。

2.4.4. 其他资源

2.4.5. 配置迁移计划

您可以增加要迁移或排除迁移的资源的数量。

2.4.5.1. 为大型迁移增加限制

您可以使用 MTC 为大型迁移增加迁移对象和容器资源的限制。

重要

您必须在生产环境中执行迁移前测试这些更改。

流程

  1. 编辑 MigrationController 自定义资源(CR)清单:

    $ oc edit migrationcontroller -n openshift-migration
  2. 更新以下参数:

    ...
    mig_controller_limits_cpu: "1" 1
    mig_controller_limits_memory: "10Gi" 2
    ...
    mig_controller_requests_cpu: "100m" 3
    mig_controller_requests_memory: "350Mi" 4
    ...
    mig_pv_limit: 100 5
    mig_pod_limit: 100 6
    mig_namespace_limit: 10 7
    ...
    1
    指定 MigrationController CR 可用的 CPU 数量。
    2
    指定 MigrationController CR 可用的内存量。
    3
    指定可用于 MigrationController CR 请求的 CPU 单元数。100m 代表 0.1 CPU 单元(100 * 1e-3)。
    4
    指定可用于 MigrationController CR 请求的内存量。
    5
    指定可迁移的持久性卷数量。
    6
    指定可迁移的 pod 数量。
    7
    指定可迁移的命名空间数量。
  3. 创建使用更新的参数验证更改的迁移计划。

    如果您的迁移计划超过 MigrationController CR 限制,则 MTC 控制台在保存迁移计划时会显示警告信息。

2.4.5.2. 从迁移计划中排除资源

您可以从 MTC 迁移计划中排除资源,如镜像流、持久性卷(PV)或订阅,以便减少迁移的资源负载,或使用其他工具迁移镜像或 PV。

默认情况下,MTC 会排除服务目录资源和 Operator Lifecycle Manager(OLM)资源。这些资源是服务目录 API 组和 OLM API 组的一部分,目前还不支持迁移。

流程

  1. 编辑 MigrationController 自定义资源清单:

    $ oc edit migrationcontroller <migration_controller> -n openshift-migration
  2. 更新 spec 部分,方法是添加参数以排除特定资源,或者在 exclude_resources 参数中添加资源(如果它本身没有排除参数):

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      disable_image_migration: true 1
      disable_pv_migration: true 2
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
    1
    添加 disable_image_migration: true 以排除迁移中的镜像流。不要编辑 exclude_resources 参数。当 MigrationController pod 重启时,镜像流会添加到 excluded_resources
    2
    添加 disable_pv_migration: true 以将 PV 排除在迁移计划之外。不要编辑 exclude_resources 参数。当 MigrationController Pod 重启时,persistentvolumespersistentvolumeclaims 会被添加到 excluded_resources。禁用 PV 迁移会同时在创建迁移计划时禁用 PV 发现功能。
    3
    您可以将 OpenShift Container Platform 资源添加到 exclude_resources 列表中。不要删除默认排除的资源。对这些进行迁移可能会产生问题,因此必须被排除。
  3. 等待 2 分钟,使 MigrationController Pod 重启,以便应用更改。
  4. 验证资源是否排除:

    $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

    输出包含排除的资源:

    输出示例

        - name: EXCLUDED_RESOURCES
          value:
          imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

2.5. 故障排除

您可以查看 MTC 的 Migration Toolkit for Containers(MTC)自定义资源并下载日志来排除迁移失败的问题。

如果应用程序在迁移失败时停止,您必须回滚迁移以防止数据崩溃。

注意

如果应用程序在迁移过程中没有停止,则不需要手动回滚,因为原始应用程序仍然在源集群中运行。

2.5.1. 查看迁移自定义资源

MTC 会创建以下自定义资源(CR):

migration architecture diagram

20 MigCluster (配置, MTC 集群): 集群定义

20 MigStorage (配置, MTC 集群): Storage 定义

20 MigPlan (配置, MTC 集群):迁移计划

MigPlan CR 描述了要迁移的源和目标集群、复制仓库和命名空间。它与 0 个、1 个或多个 MigMigration CR 关联。

注意

删除 MigPlan CR 会删除关联的 MigMigration CR。

20 BackupStorageLocation (配置, MTC 集群): Velero 备份对象的位置

20 VolumeSnapshotLocation (配置, MTC 集群): Velero 卷快照的位置

20 MigMigration (操作,MTC 集群)::迁移,在每次进行 stage 或迁移数据时创建。每个 MigMigration CR 都与 MigPlan CR 关联。

20 Backup(操作,源集群):当运行迁移计划时,MigMigration CR 在每个源集群上创建两个 Velero 备份 CR:

  • 备份 CR #1 用于Kubernetes 对象
  • 备份 CR #2 用于 PV 数据

20 Restore (操作,目标集群):在运行迁移计划时,MigMigration CR 在目标集群上创建两个 Velero 恢复 CR:

  • 恢复 CR #1(使用备份 CR #2)用于 PV 数据
  • 恢复 CR #2(使用备份 CR #1)用于 Kubernetes 对象

流程

  1. 列出 openshift-migration 命名空间中的 MigMigration CR:

    $ oc get migmigration -n openshift-migration

    输出示例

    NAME                                   AGE
    88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

  2. 检查 MigMigration CR:

    $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

    输出结果类似以下示例。

MigMigration 示例输出

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

Velero 备份 CR #2 示例输出来描述 PV 数据

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Velero 恢复 CR #2 示例输出来描述 Kubernetes 资源

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

2.5.2. 使用迁移日志读取器

您可以使用迁移日志读取器显示所有迁移日志的过滤视图。

流程

  1. 获取 mig-log-reader pod:

    $ oc -n openshift-migration get pods | grep log
  2. 输入以下命令显示单个迁移日志:

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    -c plain 选项显示没有颜色的日志。

2.5.3. 下载迁移日志

您可以在 Migration Toolkit for Containers(MTC)web 控制台中下载 VeleroResticMigrationController pod 日志,以排除迁移失败的问题。

流程

  1. 在 MTC 控制台中,点 Migration plan 查看迁移计划列表。
  2. 点击特定迁移计划 kebabOptions 菜单并选择 Logs
  3. Download Logs 为所有集群下载 MigrationControllerVeleroRestic pod 的日志。

    您可以选择集群、日志源和 pod 源下载单个日志,然后点 Download Selected

    您可以使用 oc logs 命令从 CLI 访问 pod 日志:

    $ oc logs <pod-name> -f -n openshift-migration 1
    1
    指定 pod 名称。

2.5.4. 更新已弃用的 API

如果您的源集群使用已弃用的 API,在 MTC web 控制台中创建迁移计划时会显示以下警告信息:

Some namespaces contain GVKs incompatible with destination cluster

您可以点 See details 查看命名空间和不兼容的 API。这个警告信息并不会阻止迁移。

在使用 Migration Toolkit for Containers(MTC)进行迁移的过程中,已弃用的 API 保存在用于 Kubernetes 对象的 Velero Backup #1 中。您可以下载 Velero Backup,提取已弃用的 API yaml 文件,并使用 oc convert 命令更新它们。然后您可以在目标集群中创建更新的 API。

流程

  1. 运行迁移计划
  2. 查看 MigPlan 自定义资源(CR):

    $ oc describe migplan <migplan_name> -n openshift-migration 1
    1
    指定 MigPlan CR 的名称。

    输出结果类似以下:

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    记录 MigPlan CR UID。
    2
    记录 gvks 部分中列出的已弃用 API。
  3. 获取与 MigPlan UID 关联的 MigMigration 名称:

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    指定 MigPlan CR UID。
  4. 获取与 MigMigration 名称关联的 MigMigration UID:

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    指定 MigMigration 名称。
  5. 获取与 MigMigration UID 关联的 Velero 备份名称:

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    指定 MigMigration UID。
  6. 根据您所使用的存储供应商运行以下命令,将 Velero 备份的内容下载到您的本地机器中:

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      指定存储桶、备份名称和您的本地备份目录名称。
    • GCP:

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      指定存储桶、备份名称和您的本地备份目录名称。
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      指定备份名称和您的本地备份目录名称。
  7. 解压 Velero 备份归档文件:

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 对于每个弃用的 API,以离线模式运行 oc convert

    $ oc convert -f <backup_local_dir>/resources/<gvk>.json
  9. 在目标集群中创建转换的 API:

    $ oc create -f <gvk>.json

2.5.5. 错误信息和解决方案

本节论述了您可能会在 Migration Toolkit for Containers(MTC)中遇到的常见错误消息,以及如何解决其底层原因。

2.5.5.1. Restic 超时错误

如果在第一次尝试访问 MTC 控制台时显示 CA 证书错误信息,则可能的原因是在一个集群中使用自签名的 CA 证书。

要解决这个问题,进入出错信息中显示的 oauth-authorization-server URL 并接受证书。要永久解决这个问题,将证书添加到网页浏览器的信任存储中。

如果您接受证书后显示 Unauthorized 信息,进入 MTC 控制台并刷新网页。

2.5.5.2. MTC 控制台中的 OAuth 超时错误

如果在接受自签名证书后,MTC 控制台中显示 connection has timed out,其原因可能是:

您可以确定超时的原因。

流程

  1. 进入 MTC 控制台,使用浏览器的 web 检查功能进行检查。
  2. 检查 MigrationUI pod 日志:

    $ oc logs <MigrationUI_Pod> -n openshift-migration

2.5.5.3. Velero pod 日志中的 PodVolumeBackups 超时错误

如果因为 Restic 超时造成迁移失败,以下错误会在 Velero pod 日志中显示。

输出示例

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

restic_timeout 的默认值为一小时。您可以为大型迁移增加这个参数值,请注意,高的值可能会延迟返回出错信息。

流程

  1. 在 OpenShift Container Platform web 控制台中导航至 OperatorsInstalled Operators
  2. Migration Toolkit for Containers Operator
  3. MigrationController 标签页中点 migration-controller
  4. YAML 标签页中,更新以下参数值:

    spec:
      restic_timeout: 1h 1
    1
    有效单元是 h (小时)、m (分钟)和 s (秒),例如 3h30m15s
  5. Save

2.5.5.4. MigMigration 自定义资源中的 ResticVerifyErrors

如果迁移使用文件系统数据复制方法的持久性卷时数据验证失败,在 MigMigration CR 中会显示以下错误。

输出示例

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2

1
错误消息指定了 Restore CR 名称。
2
ResticVerifyErrors 是一个包括验证错误的一般错误警告类型。
注意

数据验证错误不会导致迁移过程失败。

您可以检查 Restore CR,以识别数据验证错误的来源。

流程

  1. 登录到目标集群。
  2. 查看 Restore CR:

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    输出会标识出带有 PodVolumeRestore 错误的持久性卷。

    输出示例

    status:
      phase: Completed
      podVolumeRestoreErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration
      podVolumeRestoreResticErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration

  3. 查看 PodVolumeRestore CR:

    $ oc describe <migration-example-rvwcm-98t49>

    输出中标识了记录错误的 Restic pod。

    输出示例

      completionTimestamp: 2020-05-01T20:49:12Z
      errors: 1
      resticErrors: 1
      ...
      resticPod: <restic-nr2v5>

  4. 查看 Restic pod 日志以查找错误:

    $ oc logs -f <restic-nr2v5>

2.5.6. 直接卷迁移未完成

如果直接卷迁移未完成,则目标集群可能没有与源集群相同的 node-selector 注解。

MTC 在迁移命名空间时会保留所有注解,以保持安全性上下文约束和调度要求。在直接卷迁移过程中,MTC 在从源集群迁移的命名空间中在目标集群上创建 Rsync 传输 pod。如果目标集群命名空间没有与源集群命名空间相同的注解,则无法调度 Rsync 传输 pod。Rsync pod 处于 Pending 状态。

您可以执行以下步骤识别并解决这个问题。

流程

  1. 检查 MigMigration CR 的状态:

    $ oc describe migmigration <pod_name> -n openshift-migration

    输出包括以下状态消息:

    输出示例

    ...
    Some or all transfer pods are not running for more than 10 mins on destination cluster
    ...

  2. 在源集群中,获取迁移的命名空间的详情:

    $ oc get namespace <namespace> -o yaml 1
    1
    指定迁移的命名空间。
  3. 在目标集群中,编辑迁移的命名空间:

    $ oc edit namespace <namespace>
  4. 在迁移的命名空间中添加缺少的 openshift.io/node-selector 注解,如下例所示:

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. 再次运行迁移计划。

2.5.7. 使用 Velero CLI 调试备份和恢复 CR

您可以使用 Velero 命令行界面(CLI)调试 BackupRestore 自定义资源(CR)和迁移部分失败的情况。Velero CLI 在 velero pod 中运行。

2.5.7.1. Velero 命令语法

Velero CLI 命令使用以下语法:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero <resource> <command> <resource_id>

您可以在 $(oc get pods -n openshift-migration -o name | grep velero) 中指定 velero-<pod> -n openshift-migration

2.5.7.2. help 命令

Velero help 命令列出所有 Velero CLI 命令:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help

2.5.7.3. describe 命令

Velero describe 命令提供了与 Velero 资源相关的警告和错误概述信息:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero  <resource> describe <resource_id>

示例

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

2.5.7.4. logs 命令

Velero logs 命令提供与 Velero 资源关联的日志:

velero <resource> logs <resource_id>

示例

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

2.5.7.5. 调试部分迁移失败

您可以使用 Velero CLI 检查 Restore 自定义资源(CR)日志来调试部分迁移失败警告消息。

当 Velero 遇到没有导致迁移失败的问题时,会导致迁移部分失败。例如,缺少自定义资源定义(CRD),或者源集群和目标集群的 CRD 版本之间存在冲突,则迁移会完成,但不会在目标集群上创建 CR。

Velero 将问题作为部分失败记录,然后处理 备份 CR 中的其他对象。

流程

  1. 检查 MigMigration CR 的状态:

    $ oc get migmigration <migmigration> -o yaml
    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings
  2. 使用 Velero describe 命令检查 Restore CR 的状态:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. 使用 Velero logs 命令检查 Restore CR 日志:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    Restore CR 会记录日志错误消息, the server could not find the requested resource,代表迁移部分失败的原因。

2.5.8. 使用 must-gather 收集数据

如果您要在 红帽客户门户网站 上创建 MTC 支持问题单,则需要运行 must-gather

MTC 的 openshift-migration-must-gather-rhel8 镜像收集特定于迁移的日志,以及默认 must-gather 镜像不收集的数据。

流程

  1. 进入要存储 must-gather 数据的目录。
  2. 运行 must-gather 命令:

    $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.4
  3. 删除验证密钥和其他敏感信息。
  4. 创建一个包含 must-gather 数据目录内容的归档文件:

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/
  5. 将压缩文件作为附件上传到您的客户支持问题单中。

2.5.9. 回滚一个迁移

您可以使用 MTC web 控制台或 CLI 回滚迁移。

2.5.9.1. 在 MTC web 控制台中回滚迁移

您可以使用 Migration Toolkit for Containers(MTC)web 控制台回滚迁移。

如果应用程序在迁移失败时停止,您必须回滚迁移,以防止持久性卷中的数据崩溃。

如果应用程序在迁移过程中没有停止,则不需要回滚,因为原始应用程序仍然在源集群中运行。

流程

  1. 在 MTC web 控制台中点 Migration Plan
  2. 点击迁移计划 kebab 旁边的 Options 菜单并选择 Rollback
  3. Rollback 并等待回滚完成。

    在迁移计划详情中会显示 Rollback succeeded

  4. 验证源集群的 OpenShift Container Platform Web 控制台中是否成功回滚:

    1. HomeProjects
    2. 点迁移的项目查看其状态。
    3. Routes 部分,点击 Location 验证应用程序是否正常运行。
    4. WorkloadsPods 来验证 pod 是否在迁移的命名空间中运行。
    5. StoragePersistent volumes 确认正确置备了被迁移的持久性卷。
2.5.9.1.1. 通过 CLI 回滚迁移

您可以通过 CLI 创建 MigMigration 自定义资源(CR)来回滚迁移。

如果应用程序在迁移失败时停止,您必须回滚迁移,以防止持久性卷中的数据崩溃。

如果应用程序在迁移过程中没有停止,则不需要回滚,因为原始应用程序仍然在源集群中运行。

流程

  1. 根据以下示例创建一个 MigMigration CR:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: migration-rollback
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
    EOF
    1
    指定关联的 MigPlan CR 的名称。
  2. 在 MTC web 控制台中,验证迁移的项目资源是否已从目标集群中移除。
  3. 验证迁移的项目资源是否存在于源集群中,并且应用程序是否正在运行。

2.5.10. 已知问题

这个版本有以下已知问题:

  • 在迁移过程中,MTC 会保留以下命名空间注解:

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups
    • openshift.io/sa.scc.uid-range

      这些注解会保留 UID 范围,确保容器在目标集群中保留其文件系统权限。这可能会存在一定的风险。因为迁移的 UID 可能已存在于目标集群的现有或将来的命名空间中。(BZ#1748440)

  • 大多数集群范围的资源还没有由 MTC 处理。如果应用程序需要集群范围的资源,则可能需要在目标集群上手动创建。
  • 如果迁移失败,则迁移计划不会为静默的 pod 保留自定义 PV 设置。您必须手动回滚,删除迁移计划,并使用 PV 设置创建新的迁移计划。(BZ#1784899)
  • 如果因为 Restic 超时造成大型迁移失败,您可以提高MigrationController CR 清单中的 restic_timeout 参数值(默认为 1h)。
  • 如果您选择了为使用文件系统复制方法迁移的 PV 数据进行验证的选项,则性能会非常慢。
  • 如果您要从 NFS 存储中迁移数据,并且启用了 root_squash,将 Restic 映射为 nfsnobody。迁移失败,Restic Pod 日志中显示权限错误。(BZ#1873641)

    您可以通过在 MigrationController CR 清单中添加用于 Restic 的额外组来解决这个问题:

    spec:
    ...
      restic_supplemental_groups:
      - 5555
      - 6666
  • 如果您使用位于不同可用区的节点执行直接卷迁移,则迁移可能会失败,因为迁移的 pod 无法访问 PVC。(BZ#1947487)

2.5.11. 其他资源

第 3 章 从 OpenShift Container Platform 4.2 和更新版本进行迁移

3.1. 迁移工具和先决条件

您可以使用 MTC 将应用程序工作负载从 OpenShift Container Platform 4.2 迁移到 4.5。MTC 可让您控制迁移的过程,并最小化应用程序停机时间。

注意

只要正确配置了源和目标集群,您可以在相同版本的 OpenShift Container Platform 集群间进行迁移(如从 4.2 迁移到 4.2,或从 4.3 迁移到 4.3)。

MTC 工具的 web 控制台和 API,基于 Kubernetes 自定义资源,您可以按照命名空间迁移有状态及无状态的应用程序工作负载。

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

您可以在迁移期间的特定点使用迁移 hook 运行 Ansible playbook。您在创建迁移计划时可以添加 hook。

3.1.1. 容器迁移工具(Migration Toolkit for Containers)工作流

您可以使用 MTC(Migration Toolkit for Containers) web 控制台或 Kubernetes API 将 OpenShift Container Platform 源集群中的 Kubernetes 资源、持久性卷数据和内部容器镜像迁移到 OpenShift Container Platform 4.5 目标集群。

(MTC)迁移以下资源:

  • 在迁移计划中指定的命名空间。
  • 命名空间范围的资源:当 MTC 迁移命名空间时,它会迁移与该命名空间关联的所有对象和资源,如服务或 Pod。另外,如果一个资源在命名空间中存在但不在集群级别,这个资源依赖于集群级别存在的另外一个资源,MTC 会迁移这两个资源。

    例如,安全性上下文约束(SCC)是一个存在于集群级别的资源,服务帐户(SA)是存在于命名空间级别的资源。如果 MTC 迁移的命名空间中存在 SA,MTC 会自动找到链接到 SA 的所有 SCC,并迁移这些 SCC。同样,MTC 会迁移链接到命名空间持久性卷的持久性卷声明。

  • 自定义资源(CR)和自定义资源定义(CRD): MTC 会自动迁移任何在命名空间级别存在的 CR,以及链接到这些 CR 的 CRD。

使用 MTC Web 控制台迁移应用程序涉及以下步骤:

  1. 在所有集群中安装 MTC Operator。

    您可以在有限的或没有互联网访问的受限环境中为 Containers Operator 安装 Migration Toolkit。源和目标集群必须可以在相互间进行访问,而需要可以访问 registry 的镜像(mirror).

  2. 配置复制存储库,这是 MTC 用来迁移数据的中间对象存储。

    源和目标集群必须有对复制仓库的不受限制的网络访问权限。在受限环境中,您可以使用内部托管的 S3 存储存储库。如果使用代理服务器,您必须将其配置为允许复制仓库和集群间的网络流量。

  3. 在 MTC web 控制台中添加源集群。
  4. 在 MTC web 控制台中添加复制存储库。
  5. 创建迁移计划,包含以下数据迁移选项之一:

    • Copy:MTC 将数据从源集群复制到复制存储库,再从复制存储库把数据复制到目标集群。

      注意

      如果您使用直接镜像迁移或直接卷迁移,则镜像或卷会直接从源集群复制到目标集群。

      迁移 PV 复制
    • Move:MTC 从源集群中卸载一个远程卷(例如 NFS),在目标集群上创建一个指向这个远程卷的 PV 资源,然后在目标集群中挂载远程卷。在目标集群中运行的应用程序使用源集群使用的同一远程卷。远程卷必须可以被源集群和目标集群访问。

      注意

      虽然复制仓库没有出现在此图表中,但迁移需要它。

      迁移 PV 移动
  6. 运行迁移计划,使用以下选项之一:

    • Stage (可选)在不停止应用程序的情况下将数据复制到目标集群。

      Stage 可以多次运行,以便在迁移前将大多数数据复制到目标。这可最小化迁移和应用程序停机时间。

    • Migrate 在源集群中停止应用程序,并在目标集群中重新创建其资源。您可以选择在不停止应用程序的情况下迁移工作负载。
OCP 3 到 4 的应用程序迁移

3.1.2. 容器自定义资源迁移工具

MTC 会创建以下自定义资源(CR):

migration architecture diagram

20 MigCluster (配置, MTC 集群): 集群定义

20 MigStorage (配置, MTC 集群): Storage 定义

20 MigPlan (配置, MTC 集群):迁移计划

MigPlan CR 描述了要迁移的源和目标集群、复制仓库和命名空间。它与 0 个、1 个或多个 MigMigration CR 关联。

注意

删除 MigPlan CR 会删除关联的 MigMigration CR。

20 BackupStorageLocation (配置, MTC 集群): Velero 备份对象的位置

20 VolumeSnapshotLocation (配置, MTC 集群): Velero 卷快照的位置

20 MigMigration (操作,MTC 集群)::迁移,在每次进行 stage 或迁移数据时创建。每个 MigMigration CR 都与 MigPlan CR 关联。

20 Backup(操作,源集群):当运行迁移计划时,MigMigration CR 在每个源集群上创建两个 Velero 备份 CR:

  • 备份 CR #1 用于Kubernetes 对象
  • 备份 CR #2 用于 PV 数据

20 Restore (操作,目标集群):在运行迁移计划时,MigMigration CR 在目标集群上创建两个 Velero 恢复 CR:

  • 恢复 CR #1(使用备份 CR #2)用于 PV 数据
  • 恢复 CR #2(使用备份 CR #1)用于 Kubernetes 对象

3.1.3. 关于数据复制方法

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

3.1.3.1. 文件系统复制方法

MTC 工具将数据文件从源集群复制到复制存储库,并从那里复制到目标集群。

表 3.1. 文件系统复制方法概述

优点限制:
  • 集群可以有不同的存储类
  • 所有 S3 存储供应商均支持
  • 使用 checksum 验证数据(可选)
  • 比快照复制方法慢
  • 可选的数据校验可能会显著降低性能

3.1.3.2. 快照复制方法

MTC 将源集群数据的快照复制到云供应商的复制仓库。数据在目标集群上恢复。

AWS、Google Cloud Provider 和 Microsoft Azure 支持快照复制方法。

表 3.2. 快照复制方法概述

优点限制:
  • 比文件系统复制方法快
  • 云供应商必须支持快照。
  • 集群必须位于相同的云供应商。
  • 集群必须位于同一位置或区域。
  • 集群必须具有相同的存储类。
  • 存储类必须与快照兼容。

3.1.4. 关于迁移 hook

在使用 MTC 进行迁移的特定时间点上,可以使用迁移 hook 运行自定义代码。您可以在单个迁移计划中添加最多四个迁移 hook,每个 hook 在迁移过程的不同阶段运行。

迁移 hook 执行的任务包括自定义应用程序默认、手动迁移不受支持的数据类型以及在迁移后更新应用程序。

迁移 hook 会在以下迁移步骤之一中,在源或目标集群上运行:

  • PreBackup:在源集群中备份资源前
  • PostBackup:在源集群中备份资源后
  • PreRestore:在目标集群上恢复资源前
  • PostRestore:在目标集群中恢复资源后

您可以使用 Ansible playbook 或自定义 hook 容器创建 hook。

Ansible playbook

Ansible playbook 作为一个配置映射挂载到 hook 容器上。hook 容器使用 MigPlan 自定义资源(CR)中指定的集群、服务帐户和命名空间以作业的形式运行。作业会继续运行,直到达到默认限制的 6 次重试或成功完成为止。即使初始 pod 被驱除或终止,也会继续。

默认 Ansible 运行时镜像为 registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.4。此镜像基于 Ansible Runner 镜像,并包含 Ansible Kubernetes 资源的 python-openshift,以及更新的 oc 二进制文件。

可选: 您可以使用包含其他 Ansible 模块或工具的自定义 Ansible 运行时镜像,而不是默认镜像。

自定义 hook 容器

您可以创建包含 Ansible playbook 或自定义代码的自定义 hook 容器。

3.2. 安装并升级 MTC

您可以在 OpenShift Container Platform 4.5 目标集群和 4.2 源集群中安装 MTC。

MTC 默认安装在目标集群上。您可以在 OpenShift Container Platform 3 集群或远程集群中安装 MTC。

重要

您必须在所有集群中安装相同的 MTC 版本。

3.2.1. 在连接的环境中安装 MTC

您可以在连接的环境中安装 MTC。

3.2.1.1. 在 OpenShift Container Platform 4.5 目标集群上安装 MTC

您可以在 OpenShift Container Platform 4.5 目标集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 点击 Create
  8. WorkloadsPods 来验证 MTC pod 正在运行 。

3.2.1.2. 在 OpenShift Container Platform 4.2 源集群上安装 MTC

您可以在 OpenShift Container Platform 4 源集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 更新 migration-controller 自定义资源清单中的以下参数:

    spec:
    ...
      migration_controller: false
      migration_ui: false
  8. 点击 Create
  9. WorkloadsPods 来验证 MTC pod 正在运行 。

3.2.2. 在受限环境中安装 MTC

您可以在受限环境中安装 MTC。

重要

您必须在所有集群中安装相同的 MTC 版本。

您可以为 OpenShift Container Platform 4 构建自定义 Operator 目录镜像,将其推送到本地镜像 registry,并将 Operator Lifecycle Manager(OLM)配置为从本地 registry 安装 Containers Operator 的 Migration Toolkit for Containers Operator。

3.2.2.1. 构建 Operator 目录镜像

集群管理员可以根据 Operator Lifecycle Manager(OLM)使用的 Package Manifest Format 来构建自定义 Operator 目录镜像。目录镜像可推送到支持 Docker v2-2 的容器镜像 registry。对于受限网络中的集群,此 registry 可以是集群有网络访问权限的 registry,如在受限网络集群安装过程中创建的镜像 registry。

重要

OpenShift Container Platform 集群的内部 registry 不能用作目标 registry,因为它不支持没有标签的推送(在镜像过程中需要这个功能)。

在这一示例中,流程假定在使用镜像 registry 时可访问您的网络以及互联网。

注意

只有 oc 客户端的 Linux 版本可用于此流程,因为 Windows 和 macOS 版本不提供 oc adm catalog build 命令。

先决条件

  • 没有网络访问限制的工作站
  • oc 版本 4.3.5+ Linux 客户端
  • podman 1.4.4+ 版
  • 访问支持 Docker v2-2 的镜像(mirror)registry
  • 如果您正在使用私有 registry,请将 REG_CREDS 环境变量设置为到 registry 凭证的文件路径。例如,对于 podman CLI:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • 如果您正在使用 quay.io 帐户可访问的私有命名空间,您必须设置 Quay 身份验证令牌。使用您的 quay.io 凭证对登录 API 发出请求,从而设置用于 --auth-token 标志的 AUTH_TOKEN 环境变量:

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

流程

  1. 在没有网络访问限制的工作站中,与目标镜像(mirror) registry 进行身份验证:

    $ podman login <registry_host_name>

    还可使用 registry.redhat.io 验证,以便在构建期间拉取基础镜像:

    $ podman login registry.redhat.io
  2. 根据 Quay.io 中的 redhat-operators 目录构建目录镜像,进行标记并将其推送到您的镜像 registry:

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    从 App Registry 实例中拉取的机构(命名空间)。
    2
    使用与目标 OpenShift Container Platform 集群主版本和次版本匹配的标签,将 --from 设置为 ose-operator-registry 基础镜像。
    3
    --filter-by-os 设置为用于基本镜像的操作系统和架构,该镜像必须与目标 OpenShift Container Platform 集群匹配。有效值是 linux/amd64linux/ppc64lelinux/s390x
    4
    为您的目录镜像命名并包含标签,例如: v1
    5
    可选:如果需要,指定 registry 凭证文件的位置。
    6
    可选:如果您不想为目标 registry 配置信任,请添加 --insecure 标志。
    7
    可选:如果使用其他不公开的应用程序 registry 目录,则需要指定 Quay 身份验证令牌。

    输出示例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

    有时红帽提供的无效清单是意外引入的目录 ; 当发生这种情况时,您可能会看到一些错误:

    出错的输出示例

    ...
    INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
    W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
    Uploading ... 244.9kB/s

    这些错误通常不是致命的,如果所提及 Operator 软件包不包含您计划安装的 Operator 或其依赖项,则可以忽略它们。

3.2.2.2. 针对受限网络配置 OperatorHub

集群管理员可以使用自定义 Operator 目录镜像将 OLM 和 OperatorHub 配置为在受限网络环境中使用本地内容。本例中的流程使用之前构建并推送到受支持的 registry 的自定义 redhat-operators 目录镜像。

先决条件

  • 没有网络访问限制的工作站
  • 推送到受支持的 registry 的自定义 Operator 目录镜像
  • oc 版本 4.3.5+
  • podman 1.4.4+ 版
  • 访问支持 Docker v2-2 的镜像(mirror)registry
  • 如果您正在使用私有 registry,请将 REG_CREDS 环境变量设置为到 registry 凭证的文件路径。例如,对于 podman CLI:

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

流程

  1. oc adm catalog mirror 命令提取自定义 Operator catalog 镜像的内容,以生成镜像(mirror)所需的清单:您可以选择:

    • 允许该命令的默认行为在生成清单后自动将所有镜像内容镜像到您的镜像 registry 中,或者
    • 添加 --manifests-only 标志来只生成镜像所需的清单,但并不实际将镜像内容镜像到 registry。这对检查哪些要镜像(mirror)非常有用。如果您只需要部分内容的话,可以对映射列表做出任何修改。然后,您可以使用该文件与 oc image mirror 命令一起,在以后的步骤中镜像修改的镜像列表。

    在没有网络访问限制的工作站中,运行以下命令:

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v1 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' \4
        [--manifests-only] 5
    1
    指定 Operator 目录镜像。
    2
    可选:如果需要,指定 registry 凭证文件的位置。
    3
    可选:如果您不想为目标 registry 配置信任,请添加 --insecure 标志。
    4
    由于对多个构架支持的已知问题,当前需要此标志。
    5
    可选:只生成镜像所需的清单,但并不实际将镜像内容镜像到 registry。
    警告

    如果未设置 --filter-by-os 标志或设置为 .* 以外的任何值,该命令会过滤不同的架构,用来更改清单列表摘要,也称为 多架构镜像。不正确的摘要会导致在断开连接的集群中部署这些镜像和 Operator 失败。如需更多信息,请参阅 BZ#1890951

    输出示例

    using database path mapping: /:/tmp/190214037
    wrote database to /tmp/190214037
    using database at: /tmp/190214037/bundles.db 1
    ...

    1
    命令生成的临时数据库。

    在运行命令后,会在当前目录中生成 <image_name>-manifests/ 目录以及以下文件:

    • 用来定义 ImageContentSourcePolicy 对象的 imageContentSourcePolicy.yaml,它可以将节点配置为在 Operator 清单中存储的镜像(image)引用和镜像 (mirror) 的 registry 间进行转换。
    • mapping.txt 文件,在其中包含所有源镜像,并将它们映射到目标 registry。此文件与 oc image mirror 命令兼容,可用于进一步自定义镜像(mirror)配置。
  2. 如果您在上一步中使用 --manifests-only 标志,并只想镜像部分内容:

    1. mapping.txt 文件中的镜像列表改为您的规格。如果您不确定要镜像的镜像子集的名称和版本,请使用以下步骤查找:

      1. oc adm catalog mirror 命令生成的临时数据库运行 sqlite3 工具,以检索与一般搜索查询匹配的镜像列表。输出以后如何编辑 mapping.txt 文件的帮助信息。

        例如,要检索与字符串 clusterlogging.4.3 类似的镜像列表:

        $ echo "select * from related_image \
            where operatorbundle_name like 'clusterlogging.4.3%';" \
            | sqlite3 -line /tmp/190214037/bundles.db 1
        1
        请参阅 oc adm catalog mirror 命令的输出结果来查找数据库文件的路径。

        输出示例

        image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        
        image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        ...

      2. 使用上一步的结果来编辑 mapping.txt 文件,使其只包含您要镜像的镜像子集。

        例如,您可以使用前面示例输出中的 image 值来找出您的 mapping.txt 文件中存在以下匹配行:

        mapping.txt 中的匹配镜像映射

        registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

        在这个示例中,如果您只想镜像这些 image,可以在 mapping.txt 文件中删除所有其他条目,仅保留上述两行。

    2. 在您的没有网络访问限制的工作站中,使用您修改的 mapping.txt 文件,使用 oc image mirror 命令将镜像镜像到 registry:

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt
      警告

      如果未设置 --filter-by-os 标志或设置为 .* 以外的任何值,该命令会过滤不同的架构,用来更改清单列表摘要,也称为 多架构镜像。不正确的摘要会导致在断开连接的集群中部署这些镜像和 Operator 失败。

  3. 应用 ImageContentSourcePolicy 对象:

    $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml
  4. 创建一个 CatalogSource 对象来引用您的目录镜像。

    1. 按照您的规格修改以下内容,并将它保存为 catalogsource.yaml 文件:

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc
      1
      指定您的自定义 Operator 目录镜像。
    2. 使用该文件创建 CatalogSource 对象:

      $ oc create -f catalogsource.yaml
  5. 确定成功创建以下资源。

    1. 检查 pod:

      $ oc get pods -n openshift-marketplace

      输出示例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 检查目录源:

      $ oc get catalogsource -n openshift-marketplace

      输出示例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 检查软件包清单:

      $ oc get packagemanifest -n openshift-marketplace

      输出示例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

现在,您可在受限网络 OpenShift Container Platform 集群的 web 控制台中,通过 OperatorHub 安装 Operator。

3.2.2.3. 在一个受限的环境中的 OpenShift Container Platform 4.5 目标集群上安装 MTC

您可以在 OpenShift Container Platform 4.5 目标集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须创建自定义 Operator 目录并将其推送到镜像 registry。
  • 您必须将 Operator Lifecycle Manager 配置为从镜像 registry 安装 MTC Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 点击 Create
  8. WorkloadsPods 来验证 MTC pod 正在运行 。

3.2.2.4. 在一个受限的环境中的 OpenShift Container Platform 4.2 源集群上安装 MTC

您可以在 OpenShift Container Platform 4 源集群上安装 MTC。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须创建自定义 Operator 目录并将其推送到镜像 registry。
  • 您必须将 Operator Lifecycle Manager 配置为从镜像 registry 安装 MTC Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword 字段查找 MTCs Operator
  3. 选择 Migration Toolkit for Containers Operator 并点 Install

    注意

    不要将订阅批准选项改为 Automatic。在源和目标集群中,Migration Toolkit for Containers 版本必须相同。

  4. 点击 Install

    Installed Operators 页中,openshift-migration 项目中会出现状态为 SucceededMigration Toolkit for Containers Operator

  5. Migration Toolkit for Containers Operator
  6. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  7. 点击 Create
  8. WorkloadsPods 来验证 MTC pod 正在运行 。

3.2.3. 升级 MTC

您可以使用 OpenShift Container Platform Web 控制台升级 MTC。

重要

您必须确保在所有集群中安装相同的 MTC 版本。

如果要升级 MTC 1.3,您必须执行额外步骤来更新 MigPlan 自定义资源(CR)。

3.2.3.1. 在 OpenShift Container Platform 4 集群中升级 MTC

您可以使用 OpenShift Container Platform Web 控制台在 OpenShift Container Platform 4 集群上升级 MTC。

先决条件

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

流程

  1. 在 OpenShift Container Platform 控制台中导航至 OperatorsInstalled Operators

    处于待定升级的 operator 会显示 Upgrade available 状态。

  2. Migration Toolkit for Containers Operator
  3. Subscription 标签页。任何需要批准的升级都会在 Upgrade Status 旁边显示。例如:它可能会显示 1 requires approval
  4. 1 requires approval,然后点 Preview Install Plan
  5. 查看列出可用于升级的资源,并点 Approve
  6. 返回 Operators → Installed Operators 页面来监控升级的过程。完成后,状态会变为 SucceededUp to date
  7. Migration Toolkit for Containers Operator
  8. Provided APIs 下,找到 Migration Controller 标题,再点 Create Instance
  9. 如果要在集群中升级 MTC,更新 MigrationController 自定义资源(CR)清单中的以下参数:

    spec:
    ...
      migration_controller: false
      migration_ui: false

    您不需要更新目标集群上的 MigrationController CR 清单。

  10. 点击 Create
  11. WorkloadsPods 来验证 MTC pod 正在运行 。

3.2.3.2. 将 MTC 1.3 升级到 1.4

如果要将 MTC 版本 1.3.x 升级到 1.4,您必须更新运行 MigrationController Pod 的集群中的 MigPlan 自定义资源(CR)清单。

由于 MTC 1.3 中不存在 indirectImageMigrationindirectVolumeMigration 参数,它们在 1.4 版中的默认值会为 false,这意味着启用了直接镜像迁移和直接卷迁移。由于没有满足直接迁移要求,迁移计划无法变为 Ready 状态,除非将这些参数值改为 true

先决条件

  • 已安装了 MTC 1.3。
  • 您必须以具有 cluster-admin 权限的用户身份登录。

流程

  1. 登录到运行 MigrationController Pod 的集群。
  2. 获取 MigPlan CR 清单:

    $ oc get migplan <migplan> -o yaml -n openshift-migration
  3. 更新以下参数值,并将文件保存为 migplan.yaml

    ...
    spec:
      indirectImageMigration: true
      indirectVolumeMigration: true
  4. 替换 MigPlan CR 清单以应用更改:

    $ oc replace -f migplan.yaml -n openshift-migration
  5. 获取更新的 MigPlan CR 清单以验证更改:

    $ oc get migplan <migplan> -o yaml -n openshift-migration

3.3. 为复制存储库配置对象存储

您必须将对象存储配置为用作复制存储库。MTC 将数据从源集群复制到复制存储库,然后从复制存储库复制到目标集群。

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

支持以下存储供应商:

在受限环境中,您可以创建一个内部托管的复制存储库。

先决条件

  • 所有集群都必须具有对复制存储库的不间断网络访问权限。
  • 如果您将代理服务器与内部托管的复制存储库搭配使用,您必须确保代理允许访问复制存储库。

3.3.1. 配置 MCG 存储桶做为复制存储库

您可以安装 OpenShift Container Storage Operator,并将一个 Multi-Cloud Object Gateway(MCG)存储桶配置为 Migration Toolkit for Containers(MTC)的复制仓库。

3.3.1.1. 安装 OpenShift Container Storage Operator

您可以从 OperatorHub 安装 OpenShift Container Storage Operator。

流程

  1. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  2. 使用 Filter by keyword (本例中为 OCS)来查找 OpenShift Container Storage Operator
  3. 选择 OpenShift Container Storage Operator 并点 Install
  4. 选择一个 Update ChannelInstallation ModeApproval Strategy
  5. 点击 Install

    Installed Operators 页面中,OpenShift Container Storage Operator 会出现在 openshift-storage 项目中,状态为 Succeeded

3.3.1.2. 创建 Multi-Cloud Object Gateway 存储桶

您可以创建 Multi-Cloud Object Gateway(MCG)存储桶的自定义资源(CR)。

流程

  1. 登录到 OpenShift Container Platform 集群:

    $ oc login
  2. 使用以下内容创建 NooBaa CR 配置文件,noobaa.yml

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: noobaa
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    对于非常小的集群,您可以将 cpu 的值改为 0.1
  3. 创建 NooBaa 对象:

    $ oc create -f noobaa.yml
  4. 使用以下内容创建 BackingStore CR 配置文件,bs.yml

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: mcg-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    指定持久性卷池中的卷数量。
    2
    指定卷的大小。
    3
    指定存储类。
  5. 创建 BackingStore 对象:

    $ oc create -f bs.yml
  6. 使用以下内容创建 BucketClass CR 配置文件,bc.yml

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: mcg-pv-pool-bc
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - mcg-pv-pool-bs
          placement: Spread
  7. 创建 BucketClass 对象:

    $ oc create -f bc.yml
  8. 使用以下内容创建 ObjectBucketClaim CR 配置文件,obc.yml

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    1
    记录在 MTC web 控制台中添加复制存储库的存储桶名称。
  9. 创建 ObjectBucketClaim 对象:

    $ oc create -f obc.yml
  10. 监控资源创建过程以验证 ObjectBucketClaim 的状态变为 Bound

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    这个过程可能需要五到十分钟。

  11. 获取并记录以下值,当您将复制存储库添加到 MTC web 控制台时需要这些值:

    • S3 端点:

      $ oc get route -n openshift-storage s3
    • S3 provider access key:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 provider secret access key:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

3.3.2. 将 AWS S3 存储桶配置为复制存储库

您可以将 AWS S3 存储桶配置为 MTC 的 Migration Toolkit 的复制仓库。

先决条件

  • AWS S3 存储桶必须可以被源和目标集群访问。
  • 您必须安装了 AWS CLI
  • 如果您使用快照复制方法:

    • 您必须有权访问 EC2 Elastic Block Storage (EBS)。
    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 创建 AWS S3 存储桶:

    $ aws s3api create-bucket \
        --bucket <bucket_name> \ 1
        --region <bucket_region> 2
    1
    指定 S3 存储桶名称。
    2
    指定 S3 存储桶区域,例如 us-east-1
  2. 创建 IAM 用户 velero

    $ aws iam create-user --user-name velero
  3. 创建 EC2 EBS 快照策略:

    $ cat > velero-ec2-snapshot-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
  4. 为一个或所有 S3 存储桶创建 AWS S3 访问策略:

    $ cat > velero-s3-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 2
                ]
            }
        ]
    }
    EOF
    1 2
    要授予对单一 S3 存储桶的访问权限,请指定存储桶名称。要授予对所有 AWS S3 存储桶的访问权限,请指定 * 而不是存储桶名称,如下例所示:

    输出示例

    "Resource": [
        "arn:aws:s3:::*"

  5. 将 EC2 EBS 策略附加到 velero

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-ebs \
      --policy-document file://velero-ec2-snapshot-policy.json
  6. 将 AWS S3 策略附加到 velero

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-s3 \
      --policy-document file://velero-s3-policy.json
  7. velero 创建访问密钥:

    $ aws iam create-access-key --user-name velero
    {
      "AccessKey": {
            "UserName": "velero",
            "Status": "Active",
            "CreateDate": "2017-07-31T22:24:41.576Z",
            "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>, 1
            "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
        }
    }
    1 2
    记录 AWS_SECRET_ACCESS_KEYAWS_ACCESS_KEY_ID 以将 AWS 存储库添加到 MTC web 控制台。

3.3.3. 将 Google Cloud Provider 存储桶配置为复制存储库

您可以将 Google Cloud Provider(GCP)存储桶配置为 MTC 的 Migration Toolkit for Containers 复制仓库。

先决条件

  • AWS S3 存储桶必须可以被源和目标集群访问。
  • 您必须安装了 gsutil
  • 如果您使用快照复制方法:

    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 登录到 gsutil:

    $ gsutil init

    输出示例

    Welcome! This command will take you through the configuration of gcloud.
    
    Your current configuration has been set to: [default]
    
    To continue, you must login. Would you like to login (Y/n)?

  2. 设置 BUCKET 变量:

    $ BUCKET=<bucket_name> 1
    1
    指定存储桶名称。
  3. 创建存储桶:

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 变量设置为您的活跃项目:

    $ PROJECT_ID=`gcloud config get-value project`
  5. 创建 velero IAM 服务帐户:

    $ gcloud iam service-accounts create velero \
        --display-name "Velero Storage"
  6. 创建 SERVICE_ACCOUNT_EMAIL 变量:

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
      --filter="displayName:Velero Storage" \
      --format 'value(email)'`
  7. 创建 ROLE_PERMISSIONS 变量:

    $ ROLE_PERMISSIONS=(
        compute.disks.get
        compute.disks.create
        compute.disks.createSnapshot
        compute.snapshots.get
        compute.snapshots.create
        compute.snapshots.useReadOnly
        compute.snapshots.delete
        compute.zones.get
    )
  8. 创建 velero.server 自定义角色:

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  9. 为项目添加 IAM 策略绑定:

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  10. 更新 IAM 服务帐户:

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  11. 将 IAM 服务帐户的密钥保存到当前目录中的 credentials-velero 文件中:

    $ gcloud iam service-accounts keys create credentials-velero \
      --iam-account $SERVICE_ACCOUNT_EMAIL

3.3.4. 将 Microsoft Azure Blob 存储容器配置为复制存储库

您可以将 Microsoft Azure Blob 存储容器配置为 Migration Toolkit for Containers(MTC)的复制仓库。

先决条件

  • 您必须具有 Azure 存储帐户
  • 您必须安装了 Azure CLI
  • Azure Blob 存储容器必须可以被源和目标集群访问。
  • 如果您使用快照复制方法:

    • 源和目标集群必须位于同一区域。
    • 源和目标集群必须具有相同的存储类。
    • 存储类必须与快照兼容。

流程

  1. 设置 AZURE_RESOURCE_GROUP 变量:

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  2. 创建 Azure 资源组:

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    指定位置。
  3. 设置 AZURE_STORAGE_ACCOUNT_ID 变量:

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
  4. 创建 Azure 存储帐户:

    $ az storage account create \
      --name $AZURE_STORAGE_ACCOUNT_ID \
      --resource-group $AZURE_RESOURCE_GROUP \
      --sku Standard_GRS \
      --encryption-services blob \
      --https-only true \
      --kind BlobStorage \
      --access-tier Hot
  5. 设置 BLOB_CONTAINER 变量:

    $ BLOB_CONTAINER=velero
  6. 创建 Azure Blob 存储容器:

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  7. velero 创建服务主体和凭证:

    $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
      AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
      AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" --role "Contributor" --query 'password' -o tsv` \
      AZURE_CLIENT_ID=`az ad sp list --display-name "velero" --query '[0].appId' -o tsv`
  8. credentials-velero 文件中保存服务主体的凭证:

    $ cat << EOF  > ./credentials-velero
    AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
    AZURE_TENANT_ID=${AZURE_TENANT_ID}
    AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
    AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
    AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
    AZURE_CLOUD_NAME=AzurePublicCloud
    EOF

3.4. 迁移应用程序

您可以使用 Migration Toolkit for Containers(MTC)web 控制台或命令行来迁移应用程序。

3.4.1. 先决条件

MTC(Migration Toolkit for Containers)有以下先决条件:

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 在所有集群中,MTC 版本必须相同。
  • Clusters:

    • 源集群必须升级到最新的 MTC z-stream 版本。
    • 运行 migration-controller pod 的集群必须具有对其他集群的不受限制的网络访问权限。
    • 集群必须具有相互无限的网络访问权限。
    • 集群必须具有对复制存储库的不受限制的网络访问权限。
    • 集群必须能够使用端口 443 上的 OpenShift 路由进行通信。
    • 集群不能有关键条件。
    • 集群必须处于 ready 状态。
  • 卷迁移:

    • 持久性卷(PV)必须有效。
    • PV 必须绑定到持久性卷声明。
    • 如果使用 move 方法复制 PV,集群必须具有对远程卷的不受限制的网络访问权限。
    • 如果使用快照复制方法复制 PV,则适用以下先决条件:

      • 云供应商必须支持快照。
      • 卷必须具有相同的云供应商。
      • 卷必须位于同一区域。
      • 卷必须具有相同的存储类。
  • 如果在代理环境中执行直接卷迁移,您必须配置 Stunnel TCP 代理。
  • 如果执行直接镜像迁移,您必须将源集群的内部 registry 公开给外部流量。

3.4.1.1. 创建 CA 证书捆绑包文件

如果您使用自签名证书来保护集群或 MTC 的 Migration Toolkit 的复制仓库的安全,则证书验证可能会失败,并显示以下错误消息: Certificate signed by unknown authority

您可以创建自定义 CA 证书捆绑包文件,并在添加集群或复制存储库时将其上传到 MTC web 控制台。

流程

从远程端点下载 CA 证书,并将其保存为 CA 捆绑包文件:

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
1
指定端点的主机 FQDN 和端口,如 api.my-cluster.example.com:6443
2
指定 CA 捆绑包文件的名称。

3.4.1.2. 为直接卷迁移配置代理

如果要从代理后面的源集群执行直接卷迁移,您必须在 MigrationController 自定义资源(CR)中配置 Stunnel 代理。stunnel 在源和目标集群之间为 TCP 连接创建透明的隧道,而不更改证书。

注意

直接卷迁移只支持一个代理。如果目标集群也位于代理后面,则源集群无法访问目标集群的路由。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。

流程

  1. 登录到运行 MigrationController Pod 的集群。
  2. 获取 MigrationController CR 清单:

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. 添加 stunnel_tcp_proxy 参数:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    指定 Stunnel 代理: http://<user_name>:<password>@<ip_address>:<port>
  4. 将清单保存为 migration-controller.yaml
  5. 应用更新的清单:

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

3.4.1.3. 为迁移 hook 编写 Ansible playbook

您可以编写 Ansible playbook 以用作迁移 hook。通过使用 MTC web 控制台或在 MigPlan 自定义资源(CR)清单中指定 spec.hooks 参数的值来在迁移计划中添加 hook。

Ansible playbook 作为一个配置映射挂载到 hook 容器上。hook 容器使用 MigPlan CR 中指定的集群、服务帐户和命名空间以作业的形式运行。hook 容器使用指定的服务帐户令牌,以便当任务在集群中运行前无需进行身份验证。

3.4.1.3.1. Ansible 模块

您可以使用 Ansible shell 模块来运行 oc 命令。

shell 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces

您可以使用 kubernetes.core 模块(如 k8s_info )与 Kubernetes 资源交互。

k8s_facts 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"

在非零退出状态通常不会生成的情况下,可以使用 fail 模块生成一个非零退出状态,以确保可以检测到 hook 的成功或失败。hook 以作业形式运行,hook 的成功或失败状态取决于作业容器的退出状态。

fail 模块示例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail

3.4.1.3.2. 环境变量

MigPlan CR 名称和迁移命名空间作为环境变量传递给 hook 容器。这些变量可使用 lookup 插件访问。

环境变量示例

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'migration_namespaces')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'migplan_name') }}"

3.4.1.4. 其他资源

3.4.2. 使用 MTC web 控制台迁移应用程序

您可以使用 MTC web 控制台配置集群和复制存储库。然后,您可以创建并运行迁移计划。

3.4.2.1. 启动 MTC web 控制台

您可以在浏览器中启动 MTC web 控制台。

先决条件

  • MTC web 控制台必须具有到 OpenShift Container Platform Web 控制台的网络访问权限。
  • MTC web 控制台必须具有到 OAuth 授权服务器的网络访问权限。

流程

  1. 登录到已安装 MTC 的 OpenShift Container Platform 集群。
  2. 输入以下命令来获取 MTC web 控制台 URL:

    $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

    输出类似于以下: https://migration-openshift-migration.apps.cluster.openshift.com

  3. 启动浏览器并进入 MTC web 控制台。

    注意

    如果在安装 MTC 工具套件 Operator 后尝试立即访问 MTC web 控制台,则该控制台可能无法加载,因为 Operator 仍然在配置集群。等待几分钟后重试。

  4. 如果您使用自签名的 CA 证书,则会提示您接受源集群 API 服务器的 CA 证书。网页会引导您接受剩余证书的过程。
  5. 使用 OpenShift Container Platform 的用户名密码进行登陆。

3.4.2.2. 在 MTC web 控制台中添加集群

您可以在 MTC web 控制台中添加一个集群到 Migration Toolkit for Containers(MTC)web 控制台。

先决条件

  • 如果要使用 Azure 快照复制数据:

    • 您必须为集群指定 Azure 资源组名称。
    • 集群必须位于同一 Azure 资源组中。
    • 集群必须位于同一地理位置。

流程

  1. 登录到集群。
  2. 获取 migration-controller 服务帐户令牌:

    $ oc sa get-token migration-controller -n openshift-migration
    eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ
  3. 在 MTC web 控制台中点 Clusters
  4. Add cluster
  5. 填写以下字段:

    • Cluster name:集群名称可包含小写字母(a-z)和数字(0-9)。它不能包含空格或国际字符。
    • URL:指定 API 服务器 URL,例如 https://<www.example.com>:8443
    • Service account token:粘贴 migration-controller 服务帐户令牌。
    • 公开的路由主机到镜像 registry:如果您使用直接镜像迁移,请指定源集群镜像 registry 的公开路由,例如 www.example.apps.cluster.com

      您可以指定一个端口。默认端口为 5000

    • Azure cluster:如果使用 Azure 快照复制数据,您必须选择此选项。
    • Azure resource group:如果选择了 Azure cluster,则会显示此字段。指定 Azure 资源组。
    • 需要 SSL 验证:可选:选择这个选项验证到集群的 SSL 连接。
    • CA bundle file:如果选择了 Require SSL 验证,则会显示此字段。如果您为自签名证书创建了自定义 CA 证书捆绑包文件,请点 Browse,选择 CA 捆绑包文件并上传它。
  6. Add cluster

    集群会出现在 Clusters 列表中。

3.4.2.3. 在 MTC web 控制台中添加复制存储库

您可以将对象存储桶作为复制仓库添加到 MTC 的 web 控制台的 Migration Toolkit for Containers(MTC)web 控制台。

先决条件

  • 您必须配置用于迁移数据的对象存储桶。

流程

  1. 在 MTC web 控制台中点 Replication repositories
  2. Add repository
  3. 选择 Storage provider type 并填写以下字段:

    • AWS 适用于 S3、MCSG 和通用 S3 供应商:

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • S3 bucket name:指定您创建的 S3 存储桶的名称。
      • S3 bucket region:指定 S3 存储桶区域。AWS S3 必填Optional 用于其他 S3 供应商。
      • S3 端点:指定 S3 服务的 URL,而不是存储桶,例如:https://<s3-storage.apps.cluster.com>。通用 S3 供应商必填。您必须使用 https:// 前缀。
      • S3 provider access key:为 AWS 指定 <AWS_SECRET_ACCESS_KEY> ,或者为 MCG 指定 S3 供应商访问密钥。
      • S3 provider secret access key:为 AWS 指定 <AWS_ACCESS_KEY_ID> ,或者为 MCG 指定 S3 供应商 secret 访问密钥。
      • Require SSL verification:如果您使用的是通用 S3 供应商,则清除此复选框。
      • 如果您使用自定义 CA 捆绑包,请点击 Browse 并浏览到所需的 Base64 编码的 CA 捆绑包文件。
    • GCP

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • GCP bucket name:指定 GCP 存储桶的名称。
      • GCP credential JSON blob:在 credentials-velero 文件中指定字符串。
    • Azure

      • Replication repository name:指定 MTC web 控制台中的复制存储库。
      • Azure resource group:指定 Azure Blob 存储的资源组。
      • Azure storage account name:指定 Azure Blob 存储帐户名称
      • Azure credentials - INI file contents:在 credentials-velero 文件中指定字符串。
  4. Add repository 并等待连接验证。
  5. Close

    新仓库会出现在 Replication repositories 列表中。

3.4.2.4. 在 MTC web 控制台中创建迁移计划

您可以在 Migration Toolkit for Containers(MTC)web 控制台中创建一个迁移计划。

先决条件

  • 必须使用在所有集群中具有 cluster-admin 权限的用户登录。
  • 您必须确保在所有集群中安装相同的 MTC 版本。
  • 您必须在 MTC web 控制台中添加集群和复制存储库。
  • 如果要使用 move 数据复制方法迁移持久性卷(PV),则源和目标集群必须有对远程卷的不间断网络访问权限。
  • 如果要使用直接镜像迁移,源集群的 MigCluster 自定义资源清单必须指定内部镜像 registry 的公开路由。

流程

  1. 在 MTC web 控制台中点 Migration Plan
  2. Add migration plan
  3. 输入 Plan name 并点 Next

    迁移计划名称不能超过 253 个小写字母数字字符(a-z, 0-9),且不能包含空格或下划线(_)。

  4. 选一个 Source cluster
  5. 选一个 Target cluster
  6. 选一个 Replication repository
  7. 选择要迁移的项目并点 Next
  8. 选择 Source clusterTarget clusterRepository,然后点 Next
  9. Namespaces 页面中,选择要迁移的项目并点 Next
  10. Persistent volumes 页面中,点每个 PV 的 迁移类型

    • Copy 选项将源集群的 PV 中的数据复制到复制存储库中,然后在目标集群中恢复新创建的具有类似特征的 PV 上的数据。
    • Move 选项从源集群中卸载一个远程卷(例如 NFS),在目标集群上创建一个指向这个远程卷的 PV 资源,然后在目标集群中挂载远程卷。在目标集群中运行的应用程序使用源集群使用的同一远程卷。
  11. Next
  12. Copy options 页面中,为每个 PV 选择 Copy method:

    • 快照复制使用云供应商的快照功能备份和恢复数据。它比 Filesystem copy 要快得多。
    • Filesystem copy 备份源集群中的文件,并在目标集群中恢复它们。

      直接卷迁移需要使用文件系统复制方法。

  13. 您可以选择 Verify copy 来验证使用 Filesystem copy 迁移的数据。数据是通过为每个源文件生成 checksum 并在恢复后检查 checksum 来验证。数据校验可能会显著降低性能
  14. 选择 目标存储类

    如果选择了 Filesystem copy,您可以更改目标存储类。

  15. Next
  16. Migration options 页面上,如果您为源集群指定了公开的镜像 registry 路由,则会选择 Direct 镜像迁移 选项。如果使用 Filesystem copy 迁移数据,Direct PV migration 选项会被选择。

    直接迁移选项将镜像和文件直接从源集群复制到目标集群。这个选项比将源集群的镜像和文件复制到复制存储库,然后再从复制存储库复制到目标集群要快。

  17. Next
  18. 可选:在 Hooks 页中,点 Add Hook 为迁移计划添加 hook。

    hook 运行自定义代码。您可以在单个迁移计划中最多添加四个 hook。每个 hook 在不同的迁移步骤中运行。

    1. 在 web 控制台中输入要显示的 hook 名称。
    2. 如果 hook 是一个 Ansible playbook,请选择 Ansible playbook,然后点 Browse 上传 playbook,或在字段中粘贴 playbook 的内容。
    3. 可选: 如果不使用默认 hook 镜像,请指定 Ansible 运行时镜像。
    4. 如果 hook 不是 Ansible playbook,选择 Custom container image 并指定镜像名称和路径。

      自定义容器镜像可以包含 Ansible playbook。

    5. 选择 Source clusterTarget cluster
    6. 输入 Service account nameService account namespace
    7. 为 hook 选择迁移步骤:

      • preBackup:在应用程序工作负载在源集群中备份前
      • PostBackup:在应用程序工作负载在源集群中备份后
      • preRestore:在目标集群中恢复应用程序工作负载前
      • postRestore:在目标集群中恢复应用程序工作负载后
    8. Add
  19. Finish

    迁移计划显示在 Migration Plan 列表中。

3.4.2.5. 在 MTC web 控制台中运行迁移计划

您可以使用在 Migration Toolkit for Containers(MTC)web 控制台中创建的迁移计划来 stage 或迁移应用程序和数据。

注意

迁移过程中,在目标集群中,MTC 将迁移的持久性卷(PV)的重新声明策略设置为 Retain

Backup 自定义资源包含一个 PVOriginalReclaimPolicy 注解,用于指示原始重新声明策略。您可以手动恢复迁移 PV 的重新声明策略。

先决条件

MTC web 控制台必须包含以下内容:

  • 处于 Ready 状态的源集群
  • 处于 Ready 状态的目标集群
  • 复制软件仓库
  • 有效的迁移计划

流程

  1. 登录到源集群。
  2. 删除旧镜像:

    $ oc adm prune images
  3. 登录到 MTC web 控制台并点 迁移计划
  4. 点击迁移计划 kebab 旁边的 Options 菜单,然后选择 Stage 将数据从源集群复制到目标集群,而不停止应用程序。

    您可以多次运行 Stage 以减少实际迁移时间。

  5. 当您准备好迁移应用程序工作负载时,在迁移计划 kebab 边的 Options 菜单并选择 Migrate
  6. 另外,还可以在 Migrate 窗口中选择 Do not stop applications on the source cluster during migration
  7. Migrate
  8. 迁移完成后,在 OpenShift Container Platform web 控制台中确认已成功迁移了应用程序:

    1. HomeProjects
    2. 点迁移的项目查看其状态。
    3. Routes 部分,点击 Location 验证应用程序是否正常运行。
    4. WorkloadsPods 来验证 pod 是否在迁移的命名空间中运行。
    5. StoragePersistent volumes 确认正确置备了被迁移的持久性卷。

3.4.3. 从命令行迁移应用程序

您可以使用 MTC 自定义资源(CR)在命令行中迁移应用程序。

您可以将应用程序从本地集群迁移到远程集群,从远程集群迁移到本地集群,并在远程集群间进行迁移。

MTC 术语

以下与配置集群相关的术语:

  • host 集群:

    • migration-controller pod 在 host 集群中运行。
    • host 集群不需要有一个公开的安全 registry 路由来直接进行镜像迁移。
  • 本地集群:本地集群通常与 host 集群相同,但这不是必须的。
  • 远程集群:

    • 远程集群必须具有公开的安全 registry 路由才能直接迁移镜像。
    • 远程集群必须具有包含 migration-controller 服务帐户令牌的 Secret CR。

以下与迁移相关的术语:

  • Source cluster(源集群):从中迁移应用程序的集群。
  • 目标集群(Destination cluster):将应用程序迁移到的集群。

3.4.3.1. 使用 MTC API 迁移应用程序

您可以使用 MTC API 在命令行中迁移应用程序。

您可以将应用程序从本地集群迁移到远程集群,从远程集群迁移到本地集群,并在远程集群间进行迁移。

这个步骤描述了如何执行间接迁移和直接迁移:

  • 间接迁移:镜像、卷和 Kubernetes 对象从源集群复制到复制存储库,然后从复制存储库复制到目标集群。
  • 直接迁移: 镜像或卷直接从源集群复制到目标集群。直接镜像迁移和直接卷迁移可显著提高性能。

创建以下自定义资源(CR)来执行迁移:

  • MigCluster CR:定义一个 host、本地或远程集群

    migration-controller pod 在 host 集群中运行。

  • Secret CR:包含远程集群或存储的凭证
  • MigStorage CR:定义一个复制存储库

    不同的存储供应商需要在 MigStorage CR 清单中使用不同的参数。

  • MigPlan CR:定义一个迁移计划
  • MigMigration CR:执行在关联的 MigPlan 中定义的一个迁移

    您可以针对以下目的,为单个 MigPlan CR 创建多个 MigMigration CR:

  • 在运行迁移前,执行一个阶段(stage)迁移(在不停止应用程序的情况下复制大多数数据)。阶段迁移可以提高迁移的性能。
  • 取消正在进行中的迁移
  • 回滚一个已完成的迁移

先决条件

  • 需要在所有集群中都有 cluster-admin 权限。
  • 您必须安装 OpenShift Container Platform CLI(oc)。
  • 您必须在所有集群中安装 MTC Operator。
  • 在所有集群中,安装的 Migration Toolkit for Containers Operator 的版本必须相同。
  • 您必须将对象存储配置为复制存储库。
  • 如果使用直接镜像迁移,则必须在所有远程集群中公开安全 registry 路由。
  • 如果您使用直接卷迁移,源集群不能配置 HTTP 代理。

流程

  1. host 集群创建一个名为 host-cluster.yamlMigCluster CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host 集群创建一个 MigCluster CR:

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. 为每个远程集群创建一个名为 cluster-secret.yamlSecret CR 清单:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    指定远程集群的 base64 编码的 migration-controller 服务帐户(SA)令牌。

    您可以运行以下命令来获取 SA 令牌:

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. 为每个远程集群创建一个 Secret CR:

    $ oc create -f cluster-secret.yaml
  5. 为每个远程集群创建一个名为 remote-cluster.yamlMigCluster CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    可选:指定公开的 registry 路由,例如 docker-registry-default.apps.example.cm,如果使用直接镜像迁移。
    2
    如果 false 则启用 SSL 验证。如果为 true,则不需要 CA 证书或不检查 CA 证书。
    3
    指定远程集群的 Secret CR。
    4
    指定远程集群的 URL。
  6. 为每个远程集群创建一个 MigCluster CR:

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. 验证所有集群是否处于 Ready 状态:

    $ oc describe cluster <cluster_name>
  8. 为名为 storage-secret.yaml 的复制存储库创建 Secret CR 清单:

    apiVersion: v1
    kind: Secret
    metadata:
      namespace: openshift-config
      name: <migstorage_creds>
    type: Opaque
    data:
      aws-access-key-id: <key_id_base64> 1
      aws-secret-access-key: <secret_key_base64> 2
    1
    指定 base64 格式的密钥 ID。
    2
    指定 base64 格式的 secret 密钥。

    AWS 凭证默认为 base64 编码。如果使用另一个存储供应商,则必须使用每个密钥运行以下命令来对凭证进行编码:

    $ echo -n "<key>" | base64 -w 0 1
    1
    指定密钥 ID 或 secret 密钥。这两个密钥都必须都是 base64 编码。
  9. 为复制存储库创建 Secret CR:

    $ oc create -f storage-secret.yaml
  10. 为复制存储库创建一个名为 migstorage.yamlMigStorage CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    指定存储桶名称。
    2
    指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。
    3
    指定存储供应商。
    4
    可选: 如果要使用快照复制数据,请指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。
    5
    可选: 如果您使用快照复制数据,请指定存储供应商。
  11. 创建 MigStorage CR:

    $ oc create -f migstorage.yaml -n openshift-migration
  12. 验证 MigStorage CR 是否处于 Ready 状态:

    $ oc describe migstorage <migstorage_name>
  13. 创建名为 migplan.yamlMigPlan CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    如果为 false,则启用直接镜像迁移。
    2
    如果为 false,则启用直接卷迁移。
    3
    指定 MigStorage CR 实例的名称。
    4
    指定要迁移的一个或多个命名空间。
    5
    指定源集群 MigCluster 实例的名称。
  14. 创建 MigPlan CR:

    $ oc create -f migplan.yaml -n openshift-migration
  15. 查看 MigPlan 实例,以验证它是否处于 Ready 状态:

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. 创建名为 migmigration.yamlMigMigration CR 清单:

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    指定 MigPlan CR 名称。
    2
    如果为 true,则源集群上的 pod 会在迁移前停止。
    3
    如果为 true,则进行阶段(stage)迁移,即在不停止应用程序的情况下复制大多数数据。
    4
    如果为 true,则会回滚到一个已完成的迁移。
  17. 创建 MigMigration CR 以启动 MigPlan CR 中定义的迁移:

    $ oc create -f migmigration.yaml -n openshift-migration
  18. 通过观察 MigMigration CR 来验证迁移的进度:

    $ oc watch migmigration <migmigration_name> -n openshift-migration

    输出类似于以下:

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

3.4.3.2. MTC 自定义资源清单

MTC 使用以下自定义资源(CR)清单来创建用于迁移应用程序的 CR。

3.4.3.2.1. DirectImageMigration

DirectImageMigration CR 直接将镜像从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
指定源集群的 MigCluster CR 名称。
2
指定目标集群的 MigCluster CR 名称。
3
指定包含要迁移的镜像的一个或多个命名空间。
3.4.3.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR 直接将镜像流引用从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
指定源集群的 MigCluster CR 名称。
2
指定目标集群的 MigCluster CR 名称。
3
指定镜像流名称。
4
指定源集群上的镜像流命名空间。
5
指定目标集群上的镜像流命名空间。
3.4.3.2.3. DirectVolumeMigration

DirectVolumeMigration CR 直接将持久性卷(PV)从源集群复制到目标集群。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <directvolumemigration_name>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: host 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc_name> 4
    namespace: <pvc_namespace> 5
  srcMigClusterRef:
    name: <source_cluster_ref> 6
    namespace: openshift-migration
1
如果为 true,在目标集群上为 PV 创建命名空间。
2
如果为 true,在迁移后会删除 DirectVolumeMigrationProgress CR。默认值为 false,这会保留 DirectVolumeMigrationProgress CR 以便进行故障排除。
3
如果目标集群不是主机集群,请更新集群名称。
4
指定使用直接卷迁移进行迁移的一个或多个 PVC。
5
指定每个 PVC 的命名空间。
6
指定源集群的 MigCluster CR 名称。
3.4.3.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR 显示 DirectVolumeMigration CR 的进度。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directvolumemigrationprogress_name
spec:
  clusterRef:
    name: source_cluster
    namespace: openshift-migration
  podRef:
    name: rsync_pod
    namespace: openshift-migration
3.4.3.2.5. MigAnalytic

MigAnalytic CR 从一个关联的 MigPlan CR 中收集镜像、Kubernetes 资源以及 PV 容量的数量。

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan_name> 1
  name: miganalytic_name
  namespace: openshift-migration
  labels:
    migplan: <migplan_name> 2
spec:
  analyzeImageCount: true 3
  analyzeK8SResources: true 4
  analyzePVCapacity: true 5
  listImages: false 6
  listImagesLimit: 50 7
  migPlanRef:
    name: migplan_name 8
    namespace: openshift-migration
1
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
2
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
3
可选:如果为 true,返回镜像数量。
4
可选:返回 Kubernetes 资源的数量、类型和 API 版本(如果为 true )。
5
可选:如果为 true 则返回 PV 容量。
6
如果为 true,则返回镜像名称列表。默认为 false,因此输出不会过长。
7
可选:指定如果 listImagestrue 时要返回的最大镜像名称数。
8
指定与 MigAnalytic 关联的 MigPlan CR 的名称。
3.4.3.2.6. MigCluster

MigCluster CR 定义一个主机、本地或远程集群。

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  azureResourceGroup: <azure_resource_group> 3
  caBundle: <ca_bundle_base64> 4
  insecure: false 5
  refresh: false 6
# The 'restartRestic' parameter is relevant for a source cluster.
# restartRestic: true 7
# The following parameters are relevant for a remote cluster.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
可选:如果 migration-controller pod 没有在这个集群中运行,则更新集群名称。
2
如果为 true,则 migration-controller pod 在此集群中运行。
3
可选: 如果存储供应商是 Microsoft Azure,请指定资源组。
4
可选:如果您为自签名 CA 证书创建了一个证书捆绑包,且 insecure 参数值为 false,请指定 base64 编码的证书捆绑包。
5
如果 false 则启用 SSL 验证。
6
如果为 true,集群会被验证。
7
如果为 true,在创建 stage pod 后 restic pod 会在源集群中重启。
8
可选:如果您使用直接镜像迁移,请指定远程集群的公开 registry 路径。
9
指定远程集群的 URL。
10
指定远程集群的 Secret CR 名称。
3.4.3.2.7. MigHook

MigHook CR 定义一个 Ansible playbook ,或一个自定义镜像,它在迁移的指定阶段运行任务。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 3
  custom: false 4
  image: <hook_image> 5
  playbook: <ansible_playbook_base64> 6
  targetCluster: source 7
1
可选:此参数的值后附加一个唯一的哈希值,以便每个迁移 hook 都有一个唯一的名称。您不需要指定 name 参数的值。
2
指定迁移 hook 名称,除非指定了 generateName 参数的值。
3
可选:指定 hook 可运行的最大秒数。默认值为 1800
4
如果为 true,则 hook 是一个自定义镜像。自定义镜像可以包括 Ansible,也可以使用不同的编程语言编写。
5
指定自定义镜像,例如 quay.io/konveyor/hook-runner:latest。如果 customtrue,则需要此项。
6
指定整个 base64 编码的 Ansible playbook。如果 customfalse,则必需。
7
指定 hook 要在其上运行的 sourcedestination 集群。
3.4.3.2.8. MigMigration

MigMigration CR 运行一个关联的 MigPlan CR。

您可以针对以下场景,创建多个与同一 MigPlan CR 关联的 MigMigration CR:

  • 您可以运行多个阶段迁移,或增量迁移,以在没有在源集群中停止 pod 的情况下复制数据。运行阶段迁移可提高实际迁移的性能。
  • 您可以取消正在进行中的迁移。
  • 您可以回滚迁移。
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  namespace: openshift-migration
spec:
  canceled: false 1
  rollback: false 2
  stage: false 3
  quiescePods: true 4
  keepAnnotations: true 5
  verify: false 6
  migPlanRef:
    name: <migplan_ref> 7
    namespace: openshift-migration
1
如果为 true,则会取消正在进行中的迁移。
2
如果为 true,则会回滚到一个已完成的迁移。
3
如果为 true,数据会被递增复制,pod 不会在源集群中停止。
4
如果为 true,在迁移的备份阶段后,源集群中的 pod 会被缩减为 0
5
如果为 true,则迁移期间应用的标签和注解将被保留。
6
如果 true ,检查目标集群中迁移的 pod 的状态,并返回处于 Running 状态的 pod 名称。
7
migPlanRef.name:指定关联的 MigPlan CR 的名称。
3.4.3.2.9. MigPlan

MigPlan CR 定义迁移计划的参数。它包含一组使用相同参数迁移的虚拟机。

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migplan_name
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_migcluster_ref> 2
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_migcluster_ref> 3
    namespace: openshift-migration
  hooks: 4
    - executionNamespace: <namespace> 5
      phase: <migration_phase> 6
      reference:
        name: <mighook_name> 7
        namespace: <hook_namespace> 8
      serviceAccount: <service_account> 9
  indirectImageMigration: true 10
  indirectVolumeMigration: false 11
  migStorageRef:
    name: <migstorage_name> 12
    namespace: openshift-migration
  namespaces:
  - <namespace>  13
  refresh: false  14
1
如果为 true,则迁移已完成。您不能为此 MigPlan CR 创建另一个 MigMigration CR。
2
指定源集群 MigCluster CR 的名称。
3
指定目标集群 MigCluster CR 的名称。
4
可选:最多可指定四个迁移 hook。
5
可选:指定运行 hook 的命名空间。
6
可选:指定 hook 运行期间的迁移阶段。一个 hook 可以分配给一个阶段。预期的值包括 PreBackupPostBackupPreRestorePostRestore
7
可选:指定 MigHook CR 的名称。
8
可选:指定 MigHook CR 的命名空间。
9
可选:指定一个具有 cluster-admin 权限的服务帐户。
10
如果为 true,则禁用直接镜像迁移。镜像从源集群复制到复制存储库,并从复制存储库复制到目标集群。
11
如果为 true,则禁用直接卷迁移。PV 从源集群复制到复制存储库,再从复制存储库复制到目标集群。
12
指定 MigStorage CR 的名称。
13
指定一个或多个命名空间。
14
如果为 trueMigPlan CR 会被验证。
3.4.3.2.10. MigStorage

MigStorage CR 描述了复制存储库的对象存储。您可以配置 Amazon Web Services、Microsoft Azure、Google Cloud Storage 和通用 S3 兼容云存储,如 Minio 或 NooBaa。

不同的供应商需要不同的参数。

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migstorage_name
  namespace: openshift-migration
spec:
  backupStorageProvider: <storage_provider> 1
  volumeSnapshotProvider: 2
  backupStorageConfig:
    awsBucketName: 3
    awsRegion: 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: 6
    awsPublicUrl: 7
    awsSignatureVersion: 8
  volumeSnapshotConfig:
    awsRegion: 9
    credsSecretRef:
      namespace: openshift-config
      name: 10
  refresh: false 11
1
指定存储供应商。
2
可选: 如果您使用快照复制方法,请指定存储供应商。
3
如果使用 AWS,请指定存储桶名称。
4
如果使用 AWS,请指定存储桶区域,如 us-east-1
5
指定为 MigStorage CR 创建的 Secret CR 的名称。
6
可选:如果您使用 AWS Key Management Service,请指定该密钥的唯一标识符。
7
可选: 如果授予 AWS 存储桶的公共访问权限,请指定存储桶 URL。
8
可选:指定向存储桶验证请求的 AWS 签名版本,例如 4
9
可选:如果您使用快照复制方法,请指定集群的地理位置。
10
可选:如果您使用快照复制方法,请指定为 MigStorage CR 创建的 Secret CR 名称。
11
如果为 true,集群会被验证。

3.4.3.3. 其他资源

3.4.4. 配置迁移计划

您可以增加要迁移或排除迁移的资源的数量。

3.4.4.1. 为大型迁移增加限制

您可以使用 MTC 为大型迁移增加迁移对象和容器资源的限制。

重要

您必须在生产环境中执行迁移前测试这些更改。

流程

  1. 编辑 MigrationController 自定义资源(CR)清单:

    $ oc edit migrationcontroller -n openshift-migration
  2. 更新以下参数:

    ...
    mig_controller_limits_cpu: "1" 1
    mig_controller_limits_memory: "10Gi" 2
    ...
    mig_controller_requests_cpu: "100m" 3
    mig_controller_requests_memory: "350Mi" 4
    ...
    mig_pv_limit: 100 5
    mig_pod_limit: 100 6
    mig_namespace_limit: 10 7
    ...
    1
    指定 MigrationController CR 可用的 CPU 数量。
    2
    指定 MigrationController CR 可用的内存量。
    3
    指定可用于 MigrationController CR 请求的 CPU 单元数。100m 代表 0.1 CPU 单元(100 * 1e-3)。
    4
    指定可用于 MigrationController CR 请求的内存量。
    5
    指定可迁移的持久性卷数量。
    6
    指定可迁移的 pod 数量。
    7
    指定可迁移的命名空间数量。
  3. 创建使用更新的参数验证更改的迁移计划。

    如果您的迁移计划超过 MigrationController CR 限制,则 MTC 控制台在保存迁移计划时会显示警告信息。

3.4.4.2. 从迁移计划中排除资源

您可以从 MTC 迁移计划中排除资源,如镜像流、持久性卷(PV)或订阅,以便减少迁移的资源负载,或使用其他工具迁移镜像或 PV。

默认情况下,MTC 会排除服务目录资源和 Operator Lifecycle Manager(OLM)资源。这些资源是服务目录 API 组和 OLM API 组的一部分,目前还不支持迁移。

流程

  1. 编辑 MigrationController 自定义资源清单:

    $ oc edit migrationcontroller <migration_controller> -n openshift-migration
  2. 更新 spec 部分,方法是添加参数以排除特定资源,或者在 exclude_resources 参数中添加资源(如果它本身没有排除参数):

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    spec:
      disable_image_migration: true 1
      disable_pv_migration: true 2
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
    1
    添加 disable_image_migration: true 以排除迁移中的镜像流。不要编辑 exclude_resources 参数。当 MigrationController pod 重启时,镜像流会添加到 excluded_resources
    2
    添加 disable_pv_migration: true 以将 PV 排除在迁移计划之外。不要编辑 exclude_resources 参数。当 MigrationController Pod 重启时,persistentvolumespersistentvolumeclaims 会被添加到 excluded_resources。禁用 PV 迁移会同时在创建迁移计划时禁用 PV 发现功能。
    3
    您可以将 OpenShift Container Platform 资源添加到 exclude_resources 列表中。不要删除默认排除的资源。对这些进行迁移可能会产生问题,因此必须被排除。
  3. 等待 2 分钟,使 MigrationController Pod 重启,以便应用更改。
  4. 验证资源是否排除:

    $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

    输出包含排除的资源:

    输出示例

        - name: EXCLUDED_RESOURCES
          value:
          imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

3.5. 故障排除

您可以查看 MTC 的 Migration Toolkit for Containers(MTC)自定义资源并下载日志来排除迁移失败的问题。

如果应用程序在迁移失败时停止,您必须手动回滚,以防止数据崩溃。

注意

如果应用程序在迁移过程中没有停止,则不需要手动回滚,因为原始应用程序仍然在源集群中运行。

3.5.1. 查看迁移自定义资源

MTC 会创建以下自定义资源(CR):

migration architecture diagram

20 MigCluster (配置, MTC 集群): 集群定义

20 MigStorage (配置, MTC 集群): Storage 定义

20 MigPlan (配置, MTC 集群):迁移计划

MigPlan CR 描述了要迁移的源和目标集群、复制仓库和命名空间。它与 0 个、1 个或多个 MigMigration CR 关联。

注意

删除 MigPlan CR 会删除关联的 MigMigration CR。

20 BackupStorageLocation (配置, MTC 集群): Velero 备份对象的位置

20 VolumeSnapshotLocation (配置, MTC 集群): Velero 卷快照的位置

20 MigMigration (操作,MTC 集群)::迁移,在每次进行 stage 或迁移数据时创建。每个 MigMigration CR 都与 MigPlan CR 关联。

20 Backup(操作,源集群):当运行迁移计划时,MigMigration CR 在每个源集群上创建两个 Velero 备份 CR:

  • 备份 CR #1 用于Kubernetes 对象
  • 备份 CR #2 用于 PV 数据

20 Restore (操作,目标集群):在运行迁移计划时,MigMigration CR 在目标集群上创建两个 Velero 恢复 CR:

  • 恢复 CR #1(使用备份 CR #2)用于 PV 数据
  • 恢复 CR #2(使用备份 CR #1)用于 Kubernetes 对象

流程

  1. 列出 openshift-migration 命名空间中的 MigMigration CR:

    $ oc get migmigration -n openshift-migration

    输出示例

    NAME                                   AGE
    88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

  2. 检查 MigMigration CR:

    $ oc describe migmigration 88435fe0-c9f8-11e9-85e6-5d593ce65e10 -n openshift-migration

    输出结果类似以下示例。

MigMigration 示例输出

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

Velero 备份 CR #2 示例输出来描述 PV 数据

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Velero 恢复 CR #2 示例输出来描述 Kubernetes 资源

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

3.5.2. 使用迁移日志读取器

您可以使用迁移日志读取器显示所有迁移日志的过滤视图。

流程

  1. 获取 mig-log-reader pod:

    $ oc -n openshift-migration get pods | grep log
  2. 输入以下命令显示单个迁移日志:

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    -c plain 选项显示没有颜色的日志。

3.5.3. 下载迁移日志

您可以在 Migration Toolkit for Containers(MTC)web 控制台中下载 VeleroResticMigrationController pod 日志,以排除迁移失败的问题。

流程

  1. 在 MTC 控制台中,点 Migration plan 查看迁移计划列表。
  2. 点击特定迁移计划 kebabOptions 菜单并选择 Logs
  3. Download Logs 为所有集群下载 MigrationControllerVeleroRestic pod 的日志。

    您可以选择集群、日志源和 pod 源下载单个日志,然后点 Download Selected

    您可以使用 oc logs 命令从 CLI 访问 pod 日志:

    $ oc logs <pod-name> -f -n openshift-migration 1
    1
    指定 pod 名称。

3.5.4. 更新已弃用的 API

如果您的源集群使用已弃用的 API,在 MTC web 控制台中创建迁移计划时会显示以下警告信息:

Some namespaces contain GVKs incompatible with destination cluster

您可以点 See details 查看命名空间和不兼容的 API。这个警告信息并不会阻止迁移。

在使用 Migration Toolkit for Containers(MTC)进行迁移的过程中,已弃用的 API 保存在用于 Kubernetes 对象的 Velero Backup #1 中。您可以下载 Velero Backup,提取已弃用的 API yaml 文件,并使用 oc convert 命令更新它们。然后您可以在目标集群中创建更新的 API。

流程

  1. 运行迁移计划
  2. 查看 MigPlan 自定义资源(CR):

    $ oc describe migplan <migplan_name> -n openshift-migration 1
    1
    指定 MigPlan CR 的名称。

    输出结果类似以下:

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    记录 MigPlan CR UID。
    2
    记录 gvks 部分中列出的已弃用 API。
  3. 获取与 MigPlan UID 关联的 MigMigration 名称:

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    指定 MigPlan CR UID。
  4. 获取与 MigMigration 名称关联的 MigMigration UID:

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    指定 MigMigration 名称。
  5. 获取与 MigMigration UID 关联的 Velero 备份名称:

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    指定 MigMigration UID。
  6. 根据您所使用的存储供应商运行以下命令,将 Velero 备份的内容下载到您的本地机器中:

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      指定存储桶、备份名称和您的本地备份目录名称。
    • GCP:

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      指定存储桶、备份名称和您的本地备份目录名称。
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      指定备份名称和您的本地备份目录名称。
  7. 解压 Velero 备份归档文件:

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 对于每个弃用的 API,以离线模式运行 oc convert

    $ oc convert -f <backup_local_dir>/resources/<gvk>.json
  9. 在目标集群中创建转换的 API:

    $ oc create -f <gvk>.json

3.5.5. 错误信息和解决方案

本节论述了您可能会在 Migration Toolkit for Containers(MTC)中遇到的常见错误消息,以及如何解决其底层原因。

3.5.5.1. Restic 超时错误

如果在第一次尝试访问 MTC 控制台时显示 CA 证书错误信息,则可能的原因是在一个集群中使用自签名的 CA 证书。

要解决这个问题,进入出错信息中显示的 oauth-authorization-server URL 并接受证书。要永久解决这个问题,将证书添加到网页浏览器的信任存储中。

如果您接受证书后显示 Unauthorized 信息,进入 MTC 控制台并刷新网页。

3.5.5.2. MTC 控制台中的 OAuth 超时错误

如果在接受自签名证书后,MTC 控制台中显示 connection has timed out,其原因可能是:

您可以确定超时的原因。

流程

  1. 进入 MTC 控制台,使用浏览器的 web 检查功能进行检查。
  2. 检查 MigrationUI pod 日志:

    $ oc logs <MigrationUI_Pod> -n openshift-migration

3.5.5.3. Velero pod 日志中的 PodVolumeBackups 超时错误

如果因为 Restic 超时造成迁移失败,以下错误会在 Velero pod 日志中显示。

输出示例

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

restic_timeout 的默认值为一小时。您可以为大型迁移增加这个参数值,请注意,高的值可能会延迟返回出错信息。

流程

  1. 在 OpenShift Container Platform web 控制台中导航至 OperatorsInstalled Operators
  2. Migration Toolkit for Containers Operator
  3. MigrationController 标签页中点 migration-controller
  4. YAML 标签页中,更新以下参数值:

    spec:
      restic_timeout: 1h 1
    1
    有效单元是 h (小时)、m (分钟)和 s (秒),例如 3h30m15s
  5. Save

3.5.5.4. MigMigration 自定义资源中的 ResticVerifyErrors

如果迁移使用文件系统数据复制方法的持久性卷时数据验证失败,在 MigMigration CR 中会显示以下错误。

输出示例

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2

1
错误消息指定了 Restore CR 名称。
2
ResticVerifyErrors 是一个包括验证错误的一般错误警告类型。
注意

数据验证错误不会导致迁移过程失败。

您可以检查 Restore CR,以识别数据验证错误的来源。

流程

  1. 登录到目标集群。
  2. 查看 Restore CR:

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    输出会标识出带有 PodVolumeRestore 错误的持久性卷。

    输出示例

    status:
      phase: Completed
      podVolumeRestoreErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration
      podVolumeRestoreResticErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration

  3. 查看 PodVolumeRestore CR:

    $ oc describe <migration-example-rvwcm-98t49>

    输出中标识了记录错误的 Restic pod。

    输出示例

      completionTimestamp: 2020-05-01T20:49:12Z
      errors: 1
      resticErrors: 1
      ...
      resticPod: <restic-nr2v5>

  4. 查看 Restic pod 日志以查找错误:

    $ oc logs -f <restic-nr2v5>

3.5.6. 直接卷迁移未完成

如果直接卷迁移未完成,则目标集群可能没有与源集群相同的 node-selector 注解。

MTC 在迁移命名空间时会保留所有注解,以保持安全性上下文约束和调度要求。在直接卷迁移过程中,MTC 在从源集群迁移的命名空间中在目标集群上创建 Rsync 传输 pod。如果目标集群命名空间没有与源集群命名空间相同的注解,则无法调度 Rsync 传输 pod。Rsync pod 处于 Pending 状态。

您可以执行以下步骤识别并解决这个问题。

流程

  1. 检查 MigMigration CR 的状态:

    $ oc describe migmigration <pod_name> -n openshift-migration

    输出包括以下状态消息:

    输出示例

    ...
    Some or all transfer pods are not running for more than 10 mins on destination cluster
    ...

  2. 在源集群中,获取迁移的命名空间的详情:

    $ oc get namespace <namespace> -o yaml 1
    1
    指定迁移的命名空间。
  3. 在目标集群中,编辑迁移的命名空间:

    $ oc edit namespace <namespace>
  4. 在迁移的命名空间中添加缺少的 openshift.io/node-selector 注解,如下例所示:

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. 再次运行迁移计划。

3.5.7. 使用 Velero CLI 调试备份和恢复 CR

您可以使用 Velero 命令行界面(CLI)调试 BackupRestore 自定义资源(CR)和迁移部分失败的情况。Velero CLI 在 velero pod 中运行。

3.5.7.1. Velero 命令语法

Velero CLI 命令使用以下语法:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero <resource> <command> <resource_id>

您可以在 $(oc get pods -n openshift-migration -o name | grep velero) 中指定 velero-<pod> -n openshift-migration

3.5.7.2. help 命令

Velero help 命令列出所有 Velero CLI 命令:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help

3.5.7.3. describe 命令

Velero describe 命令提供了与 Velero 资源相关的警告和错误概述信息:

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero  <resource> describe <resource_id>

示例

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

3.5.7.4. logs 命令

Velero logs 命令提供与 Velero 资源关联的日志:

velero <resource> logs <resource_id>

示例

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

3.5.7.5. 调试部分迁移失败

您可以使用 Velero CLI 检查 Restore 自定义资源(CR)日志来调试部分迁移失败警告消息。

当 Velero 遇到没有导致迁移失败的问题时,会导致迁移部分失败。例如,缺少自定义资源定义(CRD),或者源集群和目标集群的 CRD 版本之间存在冲突,则迁移会完成,但不会在目标集群上创建 CR。

Velero 将问题作为部分失败记录,然后处理 备份 CR 中的其他对象。

流程

  1. 检查 MigMigration CR 的状态:

    $ oc get migmigration <migmigration> -o yaml
    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings
  2. 使用 Velero describe 命令检查 Restore CR 的状态:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. 使用 Velero logs 命令检查 Restore CR 日志:

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    Restore CR 会记录日志错误消息, the server could not find the requested resource,代表迁移部分失败的原因。

3.5.8. 使用 must-gather 收集数据

如果您要在 红帽客户门户网站 上创建 MTC 支持问题单,则需要运行 must-gather

MTC 的 openshift-migration-must-gather-rhel8 镜像收集特定于迁移的日志,以及默认 must-gather 镜像不收集的数据。

流程

  1. 进入要存储 must-gather 数据的目录。
  2. 运行 must-gather 命令:

    $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.4
  3. 删除验证密钥和其他敏感信息。
  4. 创建一个包含 must-gather 数据目录内容的归档文件:

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/
  5. 将压缩文件作为附件上传到您的客户支持问题单中。

3.5.9. 回滚一个迁移

您可以使用 MTC web 控制台或 CLI 回滚迁移。

3.5.9.1. 在 MTC web 控制台中回滚迁移

您可以使用 Migration Toolkit for Containers(MTC)web 控制台回滚迁移。

如果应用程序在迁移失败时停止,您必须回滚迁移,以防止持久性卷中的数据崩溃。

如果应用程序在迁移过程中没有停止,则不需要回滚,因为原始应用程序仍然在源集群中运行。

流程

  1. 在 MTC web 控制台中点 Migration Plan
  2. 点击迁移计划 kebab 旁边的 Options 菜单并选择 Rollback
  3. Rollback 并等待回滚完成。

    在迁移计划详情中会显示 Rollback succeeded

  4. 验证源集群的 OpenShift Container Platform Web 控制台中是否成功回滚:

    1. HomeProjects
    2. 点迁移的项目查看其状态。
    3. Routes 部分,点击 Location 验证应用程序是否正常运行。
    4. WorkloadsPods 来验证 pod 是否在迁移的命名空间中运行。
    5. StoragePersistent volumes 确认正确置备了被迁移的持久性卷。
3.5.9.1.1. 通过 CLI 回滚迁移

您可以通过 CLI 创建 MigMigration 自定义资源(CR)来回滚迁移。

如果应用程序在迁移失败时停止,您必须回滚迁移,以防止持久性卷中的数据崩溃。

如果应用程序在迁移过程中没有停止,则不需要回滚,因为原始应用程序仍然在源集群中运行。

流程

  1. 根据以下示例创建一个 MigMigration CR:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: migration-rollback
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
    EOF
    1
    指定关联的 MigPlan CR 的名称。
  2. 在 MTC web 控制台中,验证迁移的项目资源是否已从目标集群中移除。
  3. 验证迁移的项目资源是否存在于源集群中,并且应用程序是否正在运行。

3.5.10. 已知问题

这个版本有以下已知问题:

  • 在迁移过程中,MTC 会保留以下命名空间注解:

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups
    • openshift.io/sa.scc.uid-range

      这些注解会保留 UID 范围,确保容器在目标集群中保留其文件系统权限。这可能会存在一定的风险。因为迁移的 UID 可能已存在于目标集群的现有或将来的命名空间中。(BZ#1748440)

  • 大多数集群范围的资源还没有由 MTC 处理。如果应用程序需要集群范围的资源,则可能需要在目标集群上手动创建。
  • 如果迁移失败,则迁移计划不会为静默的 pod 保留自定义 PV 设置。您必须手动回滚,删除迁移计划,并使用 PV 设置创建新的迁移计划。(BZ#1784899)
  • 如果因为 Restic 超时造成大型迁移失败,您可以提高MigrationController CR 清单中的 restic_timeout 参数值(默认为 1h)。
  • 如果您选择了为使用文件系统复制方法迁移的 PV 数据进行验证的选项,则性能会非常慢。
  • 如果您要从 NFS 存储中迁移数据,并且启用了 root_squash,将 Restic 映射为 nfsnobody。迁移失败,Restic Pod 日志中显示权限错误。(BZ#1873641)

    您可以通过在 MigrationController CR 清单中添加用于 Restic 的额外组来解决这个问题:

    spec:
    ...
      restic_supplemental_groups:
      - 5555
      - 6666
  • 如果您使用位于不同可用区的节点执行直接卷迁移,则迁移可能会失败,因为迁移的 pod 无法访问 PVC。(BZ#1947487)

3.5.11. 其他资源

法律通告

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.