OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的所在地）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

故障排除

MTC 工作流程

您可以使用容器迁移工具包 (MTC) Web 控制台或 Kubernetes API 将 Kubernetes 资源、持久卷数据和内部容器镜像迁移到 OpenShift Container Platform 4.17。

MTC 迁移以下资源

  • 迁移计划中指定的命名空间。

  • 命名空间范围的资源：当 MTC 迁移命名空间时，它会迁移与该命名空间关联的所有对象和资源，例如服务或 Pod。此外，如果命名空间中存在但集群级别不存在的资源依赖于集群级别存在的资源，则 MTC 会迁移这两个资源。

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

    根据资源的不同，可能需要手动迁移集群范围的资源。

  • 自定义资源 (CR) 和自定义资源定义 (CRD)：MTC 会自动迁移命名空间级别的 CR 和 CRD。

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

  1. 在所有集群上安装容器迁移工具包运算符。

    您可以在具有有限或无互联网访问权限的受限环境中安装容器迁移工具包运算符。源集群和目标集群必须能够相互访问网络以及镜像注册表。

  2. 配置复制存储库，这是一个 MTC 用于迁移数据的中间对象存储。

    在迁移期间，源集群和目标集群必须能够访问复制存储库的网络。如果您使用的是代理服务器，则必须将其配置为允许复制存储库和集群之间的网络流量。

  3. 将源集群添加到 MTC Web 控制台。

  4. 将复制存储库添加到 MTC Web 控制台。

  5. 创建迁移计划，其中包含以下数据迁移选项之一

    • 复制：MTC 将数据从源集群复制到复制存储库，然后从复制存储库复制到目标集群。

      如果您使用的是直接镜像迁移或直接卷迁移，则镜像或卷将直接从源集群复制到目标集群。
      migration PV copy

    • 移动：MTC 从源集群卸载远程卷（例如，NFS），在目标集群上创建一个指向远程卷的 PV 资源，然后将远程卷挂载到目标集群。在目标集群上运行的应用程序使用与源集群使用的相同的远程卷。源集群和目标集群必须能够访问远程卷。

      虽然此图中未显示复制存储库，但它是迁移所必需的。
      migration PV move

  6. 运行迁移计划，选择以下其中一个选项：

    • 分阶段迁移将数据复制到目标集群，无需停止应用程序。

      分阶段迁移可以运行多次，以便在迁移之前将大部分数据复制到目标集群。运行一次或多次分阶段迁移可以缩短切换迁移的持续时间。

    • 切换迁移停止源集群上的应用程序并将资源移动到目标集群。

      可选：您可以取消选中迁移期间停止源集群上的事务复选框。

OCP 3 to 4 App migration

关于 MTC 自定义资源

容器迁移工具包 (MTC) 创建以下自定义资源 (CR)：

migration architecture diagram

20 MigCluster（配置，MTC 集群）：集群定义

20 MigStorage（配置，MTC 集群）：存储定义

20 MigPlan（配置，MTC 集群）：迁移计划

MigPlan CR 描述了源集群和目标集群、复制存储库以及正在迁移的命名空间。它与 0 个、1 个或多个 MigMigration CR 相关联。

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

20 BackupStorageLocation（配置，MTC 集群）：Velero 备份对象的存储位置

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

20 MigMigration (操作，MTC 集群): 每次你准备或迁移数据时创建的迁移，每个`MigMigration` CR都与一个`MigPlan` CR关联。

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

  • Kubernetes 对象的备份 CR #1

  • PV 数据的备份 CR #2

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

  • 恢复 CR #1（使用备份 CR #2）用于 PV 数据

  • 恢复 CR #2（使用备份 CR #1）用于 Kubernetes 对象

容器迁移工具包自定义资源清单

容器迁移工具包 (MTC) 使用以下自定义资源 (CR) 清单来迁移应用程序。

DirectImageMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  namespaces: (1)
    - <source_namespace_1>
    - <source_namespace_2>:<destination_namespace_3> (2)
1 一个或多个包含要迁移镜像的命名空间。默认情况下，目标命名空间与源命名空间名称相同。
2 源命名空间映射到名称不同的目标命名空间。

DirectImageStreamMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_stream_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream>
    namespace: <source_image_stream_namespace>
  destNamespace: <destination_image_stream_namespace>

DirectVolumeMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <direct_volume_migration>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false (1)
  deleteProgressReportingCRs: false (2)
  destMigClusterRef:
    name: <host_cluster> (3)
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc> (4)
    namespace: <pvc_namespace>
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
1 设置为 true 以在目标集群上为 PV 创建命名空间。
2 设置为 true 以在迁移后删除 DirectVolumeMigrationProgress CR。默认值为 false，以便保留 DirectVolumeMigrationProgress CR 用于故障排除。
3 如果目标集群不是主机集群，请更新集群名称。
4 指定一个或多个要迁移的 PVC。

DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR 显示 DirectVolumeMigration CR 的进度。

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

MigAnalytic

MigAnalytic CR 从关联的 MigPlan CR 中收集镜像数量、Kubernetes 资源数量和持久卷 (PV) 容量。

您可以配置它收集的数据。

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan>
  name: <miganalytic>
  namespace: openshift-migration
  labels:
    migplan: <migplan>
spec:
  analyzeImageCount: true (1)
  analyzeK8SResources: true (2)
  analyzePVCapacity: true (3)
  listImages: false (4)
  listImagesLimit: 50 (5)
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1 可选：返回镜像数量。
2 可选：返回 Kubernetes 资源的数量、种类和 API 版本。
3 可选：返回 PV 容量。
4 返回镜像名称列表。默认值为 false，以便输出不会过长。
5 可选：如果 listImages 为 true，则指定要返回的镜像名称的最大数量。

MigCluster

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

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <host_cluster> (1)
  namespace: openshift-migration
spec:
  isHostCluster: true (2)
# The 'azureResourceGroup' parameter is relevant only for Microsoft Azure.
  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.
  exposedRegistryPath: <registry_route> (8)
  url: <destination_cluster_url> (9)
  serviceAccountSecretRef:
    name: <source_secret> (10)
    namespace: openshift-config
1 如果 migration-controller pod 没有在这个集群上运行，请更新集群名称。
2 如果为 true，则 migration-controller pod 在此集群上运行。
3 仅限 Microsoft Azure：指定资源组。
4 可选：如果您为自签名 CA 证书创建了证书包，并且 insecure 参数值为 false，请指定 base64 编码的证书包。
5 设置为 true 以禁用 SSL 验证。
6 设置为 true 以验证集群。
7 设置为 true 以在创建 Stage pod 后重新启动源集群上的 Restic pod。
8 仅限远程集群和直接镜像迁移：指定公开的安全注册表路径。
9 仅限远程集群：指定 URL。
10 仅限远程集群：指定 Secret 对象的名称。

MigHook

MigHook CR 定义一个迁移钩子，它在迁移的指定阶段运行自定义代码。您可以创建最多四个迁移钩子。每个钩子在迁移的不同阶段运行。

您可以配置钩子名称、运行时间、自定义镜像和钩子将运行的集群。

迁移阶段和钩子的命名空间在 MigPlan CR 中配置。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> (1)
  name: <mighook> (2)
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 1800 (3)
  custom: false (4)
  image: <hook_image> (5)
  playbook: <ansible_playbook_base64> (6)
  targetCluster: source (7)
1 可选：将唯一哈希附加到此参数的值，以便每个迁移钩子都有一个唯一的名称。您不需要指定 name 参数的值。
2 指定迁移钩子名称，除非您指定 generateName 参数的值。
3 可选：指定钩子可以运行的最大秒数。默认为 1800。
4 如果为 true，则钩子是自定义镜像。自定义镜像可以包含 Ansible，也可以用其他编程语言编写。
5 指定自定义镜像，例如 quay.io/konveyor/hook-runner:latest。如果 custom 为 true，则需要此参数。
6 Base64 编码的 Ansible playbook。如果 custom 为 false，则需要此参数。
7 指定钩子将运行的集群。有效值为 source 或 destination。

MigMigration

MigMigration CR 运行 MigPlan CR。

您可以配置 Migmigration CR 来运行阶段迁移或增量迁移，取消正在进行的迁移，或回滚已完成的迁移。

apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migmigration>
  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>
    namespace: openshift-migration
1 设置为 true 以取消正在进行的迁移。
2 设置为 true 以回滚已完成的迁移。
3 设置为 true 以运行阶段迁移。数据增量复制，并且不会停止源集群上的 pod。
4 设置为 true 以在迁移期间停止应用程序。在 Backup 阶段之后，源集群上的 pod 将缩放到 0。
5 设置为 true 以保留迁移期间应用的标签和注释。
6 设置为 true 以检查目标集群上已迁移 pod 的状态，并返回未处于 Running 状态的 pod 的名称。

MigPlan

MigPlan CR 定义迁移计划的参数。

您可以配置目标命名空间、钩子阶段以及直接或间接迁移。

默认情况下，目标命名空间与源命名空间同名。如果您配置不同的目标命名空间，则必须确保源集群或目标集群上不重复命名空间，因为 UID 和 GID 范围在迁移期间会被复制。

 
apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migplan>
  namespace: openshift-migration
spec:
  closed: false (1)
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  hooks: (2)
    - executionNamespace: <namespace> (3)
      phase: <migration_phase> (4)
      reference:
        name: <hook> (5)
        namespace: <hook_namespace> (6)
      serviceAccount: <service_account> (7)
  indirectImageMigration: true (8)
  indirectVolumeMigration: false (9)
  migStorageRef:
    name: <migstorage>
    namespace: openshift-migration
  namespaces:
    - <source_namespace_1> (10)
    - <source_namespace_2>
    - <source_namespace_3>:<destination_namespace_4> (11)
  refresh: false  (12)
1 如果为 true，则迁移已完成。您不能为此 MigPlan CR 创建另一个 MigMigration CR。
2 可选：您可以指定最多四个迁移钩子。每个钩子必须在不同的迁移阶段运行。
3 可选：指定钩子将在其中运行的命名空间。
4 可选：指定钩子运行的迁移阶段。一个钩子可以分配给一个阶段。有效值为 PreBackup、PostBackup、PreRestore 和 PostRestore。
5 可选：指定 MigHook CR 的名称。
6 可选：指定 MigHook CR 的命名空间。
7 可选：指定具有 cluster-admin 权限的服务帐户。
8 如果为 true，则禁用直接镜像迁移。镜像从源集群复制到复制存储库，然后从复制存储库复制到目标集群。
9 如果为 true，则禁用直接卷迁移。PV 从源集群复制到复制存储库，然后从复制存储库复制到目标集群。
10 指定一个或多个源命名空间。如果您只指定源命名空间，则目标命名空间相同。
11 如果目标命名空间与源命名空间不同，请指定目标命名空间。
12 如果为 true，则验证 MigPlan CR。

MigStorage

MigStorage CR 描述复制存储库的对象存储。

支持 Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Storage、多云对象网关和通用的兼容 S3 的云存储。

AWS 和快照复制方法具有其他参数。

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migstorage>
  namespace: openshift-migration
spec:
  backupStorageProvider: <backup_storage_provider> (1)
  volumeSnapshotProvider: <snapshot_storage_provider> (2)
  backupStorageConfig:
    awsBucketName: <bucket> (3)
    awsRegion: <region> (4)
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> (5)
    awsKmsKeyId: <key_id> (6)
    awsPublicUrl: <public_url> (7)
    awsSignatureVersion: <signature_version> (8)
  volumeSnapshotConfig:
    awsRegion: <region> (9)
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> (10)
  refresh: false (11)
1 指定存储提供商。
2 仅限快照复制方法：指定存储提供商。
3 仅限 AWS：指定存储桶名称。
4 仅限 AWS：指定存储桶区域，例如 us-east-1。
5 指定您为存储创建的 Secret 对象的名称。
6 仅限 AWS：如果您使用 AWS Key Management Service，请指定密钥的唯一标识符。
7 仅限 AWS：如果您向 AWS 存储桶授予了公共访问权限，请指定存储桶 URL。
8 仅限 AWS：指定用于向存储桶认证请求的 AWS 签名版本，例如4。
9 仅限快照复制方法：指定集群的地理区域。
10 仅限快照复制方法：指定为存储创建的Secret对象的名称。
11 设置为 true 以验证集群。

日志和调试工具

本节介绍可用于故障排除的日志和调试工具。

查看迁移计划资源

您可以使用 MTC Web 控制台和命令行界面 (CLI) 查看迁移计划资源，以监控正在运行的迁移或对失败的迁移进行故障排除。

步骤

  1. 在 MTC Web 控制台中，单击迁移计划。

  2. 单击迁移计划旁边的迁移数量以查看迁移页面。

  3. 单击迁移以查看迁移详细信息。

  4. 展开迁移资源以树状视图查看迁移资源及其状态。

    要对失败的迁移进行故障排除，请从失败的高级资源开始，然后沿资源树向下移动到较低级别的资源。

  5. 单击资源旁边的选项菜单 kebab 并选择以下选项之一

    • 复制oc describe命令将命令复制到剪贴板。

      • 登录到相关集群，然后运行该命令。

        资源的条件和事件将以 YAML 格式显示。

    • 复制oc logs命令将命令复制到剪贴板。

      • 登录到相关集群，然后运行该命令。

        如果资源支持日志过滤，则会显示过滤后的日志。

    • 查看 JSON在 Web 浏览器中以 JSON 格式显示资源数据。

      数据与oc get <resource>命令的输出相同。

查看迁移计划日志

您可以查看迁移计划的聚合日志。您可以使用 MTC Web 控制台将命令复制到剪贴板，然后从命令行界面 (CLI) 运行该命令。

该命令将显示以下 Pod 的过滤日志：

  • 迁移控制器

  • Velero

  • Restic

  • Rsync

  • Stunnel

  • 注册表

步骤

  1. 在 MTC Web 控制台中，单击迁移计划。

  2. 单击迁移计划旁边的迁移数量。

  3. 单击查看日志。

  4. 单击复制图标将oc logs命令复制到剪贴板。

  5. 登录到相关集群并在 CLI 上输入命令。

    将显示迁移计划的聚合日志。

使用迁移日志阅读器

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

步骤

  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选项将显示无颜色的日志。

访问性能指标

MigrationController自定义资源 (CR) 记录指标并将它们提取到集群内监控存储中。您可以使用 Prometheus 查询语言 (PromQL) 查询指标以诊断迁移性能问题。所有指标在 Migration Controller Pod 重启时都会重置。

您可以使用 OpenShift Container Platform Web 控制台访问性能指标和运行查询。

步骤

  1. 在 OpenShift Container Platform Web 控制台中，单击观察→指标。

  2. 输入 PromQL 查询，选择要显示的时间窗口，然后单击运行查询。

    如果您的 Web 浏览器未显示所有结果，请使用 Prometheus 控制台。

提供的指标

MigrationController自定义资源 (CR) 提供MigMigration CR 计数及其 API 请求的指标。

cam_app_workload_migrations

此指标是随时间推移的MigMigration CR 计数。它与mtc_client_request_count和mtc_client_request_elapsed指标一起使用，可以将 API 请求信息与迁移状态更改关联起来。此指标包含在遥测中。

表 1. cam_app_workload_migrations 指标
可查询标签名称 示例标签值 标签描述

状态

运行中、空闲、失败、已完成

MigMigration CR 的状态

类型

阶段、最终

MigMigration CR 的类型
mtc_client_request_count

此指标是MigrationController发出的 Kubernetes API 请求的累积计数。它不包含在遥测中。

表 2. mtc_client_request_count 指标
可查询标签名称 示例标签值 标签描述

集群

https://migcluster-url:443

发出请求的集群

组件

MigPlan、MigCluster

发出请求的子控制器 API

功能

(*ReconcileMigPlan).Reconcile

发出请求的功能

种类

SecretList、Deployment

为其发出请求的 Kubernetes 种类
mtc_client_request_elapsed

此指标是MigrationController发出的 Kubernetes API 请求的累积延迟（以毫秒为单位）。它不包含在遥测中。

表 3. mtc_client_request_elapsed 指标
可查询标签名称 示例标签值 标签描述

集群

https://cluster-url.com:443

发出请求的集群

组件

migplan、migcluster

发出请求的子控制器 API

功能

(*ReconcileMigPlan).Reconcile

发出请求的功能

种类

SecretList、Deployment

为其发出请求的 Kubernetes 资源
有用的查询

该表列出了一些可用于监控性能的有用查询。

表 4. 有用的查询
查询 描述

mtc_client_request_count

发出的 API 请求数量，按请求类型排序

sum(mtc_client_request_count)

发出的 API 请求总数

mtc_client_request_elapsed

API 请求延迟，按请求类型排序

sum(mtc_client_request_elapsed)

API 请求的总延迟

sum(mtc_client_request_elapsed) / sum(mtc_client_request_count)

API 请求的平均延迟

mtc_client_request_elapsed / mtc_client_request_count

API 请求的平均延迟，按请求类型排序

cam_app_workload_migrations{status="running"} * 100

正在运行的迁移计数，乘以 100 便于与请求计数一起查看

使用 must-gather 工具

您可以使用must-gather工具收集关于MTC自定义资源的日志、指标和信息。

所有客户案例都必须附加must-gather数据。

您可以收集一小时或24小时的数据，并使用Prometheus控制台查看数据。

先决条件

  • 您必须以具有cluster-admin角色的用户身份登录到OpenShift Container Platform集群。

  • 您必须安装OpenShift CLI（oc）。

步骤

  1. 导航到要存储must-gather数据的目录。

  2. 针对以下数据收集选项之一运行oc adm must-gather命令

    • 要收集过去一小时的数据，请运行以下命令：

      $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.7

      此命令将数据保存为must-gather/must-gather.tar.gz文件。您可以将此文件上传到Red Hat客户门户上的支持案例。

    • 要收集过去24小时的数据，请运行以下命令：

      $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.7 -- /usr/bin/gather_metrics_dump

      此操作可能需要很长时间。此命令将数据保存为must-gather/metrics/prom_data.tar.gz文件。

使用Velero CLI工具调试Velero资源

您可以使用Velero CLI工具调试Backup和Restore自定义资源 (CR) 并检索日志。

Velero CLI工具提供比OpenShift CLI工具更详细的信息。

语法

使用oc exec命令运行Velero CLI命令

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> <command> <cr_name>
示例
$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

帮助选项

使用velero --help选项列出所有Velero CLI命令

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  --help

describe命令

使用velero describe命令检索与Backup或Restore CR相关的警告和错误摘要

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> describe <cr_name>
示例
$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

velero describe请求的输出中显示以下类型的恢复错误和警告：

  • Velero：与Velero本身的操作相关的消息列表，例如，与连接到云、读取备份文件等相关的消息

  • Cluster：与备份或恢复集群范围资源相关的消息列表

  • Namespaces：与备份或恢复存储在命名空间中的资源相关的消息列表

这些类别中的一个或多个错误会导致Restore操作的状态为PartiallyFailed而不是Completed。警告不会导致完成状态发生变化。

  • 对于特定于资源的错误，即Cluster和Namespaces错误，restore describe --details输出包含一个资源列表，其中列出了Velero成功恢复的所有资源。对于任何出现此类错误的资源，请检查该资源是否实际存在于集群中。

  • 如果describe命令的输出中存在Velero错误，但没有特定于资源的错误，则恢复可能已完成，而恢复工作负载没有任何实际问题，但请仔细验证恢复后的应用程序。

    例如，如果输出包含PodVolumeRestore或节点代理相关的错误，请检查PodVolumeRestores和DataDownloads的状态。如果这些都没有失败或仍在运行，则卷数据可能已完全恢复。

logs命令

使用velero logs命令检索Backup或Restore CR的日志

$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  <backup_restore_cr> logs <cr_name>
示例
$ oc -n openshift-migration exec deployment/velero -c velero -- ./velero \
  restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

调试部分迁移失败

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

当Velero遇到不会导致迁移失败的问题时，就会发生部分失败。例如，如果自定义资源定义 (CRD) 丢失，或者源集群和目标集群上的CRD版本之间存在差异，则迁移将完成，但CR不会在目标集群上创建。

Velero 将该问题记录为部分失败，然后处理Backup 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 -n {namespace} exec deployment/velero -c velero -- ./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 -n {namespace} exec deployment/velero -c velero -- ./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日志错误消息“服务器找不到请求的资源”指示部分失败迁移的原因。

使用MTC自定义资源进行故障排除

您可以检查以下迁移工具包 (MTC) 自定义资源 (CR) 以对迁移失败进行故障排除：

  • MigCluster

  • MigStorage

  • MigPlan

  • BackupStorageLocation

    BackupStorageLocation CR包含一个migrationcontroller标签，用于标识创建该CR的MTC实例。

        labels:
      migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93

  • VolumeSnapshotLocation

    VolumeSnapshotLocation CR包含一个migrationcontroller标签，用于标识创建该CR的MTC实例。

        labels:
      migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93

  • MigMigration

  • Backup

    MTC将迁移的持久卷 (PV) 的回收策略更改为目标集群上的Retain。Backup CR包含一个openshift.io/orig-reclaim-policy注释，指示原始回收策略。您可以手动恢复迁移的PV的回收策略。

  • Restore

步骤

  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>
描述PV数据的Velero备份CR #2示例输出
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
    openshift.io/orig-reclaim-policy: delete
  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
描述Kubernetes资源的Velero恢复CR #2示例输出
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

常见问题和注意事项

本节描述了迁移过程中可能导致问题的常见问题和注意事项。

更新已弃用的内部镜像

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

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

先决条件

  • 您必须安装podman。

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

  • 如果您使用的是不安全的注册表，请将您的注册表主机值添加到/etc/container/registries.conf的[registries.insecure]部分，以确保podman不会遇到TLS验证错误。

  • 内部注册表必须在源集群和目标集群上公开。

步骤

  1. 确保在OpenShift Container Platform 3和4集群上公开了内部注册表。

    OpenShift镜像注册表在OpenShift Container Platform 4上默认公开。

  2. 如果您使用的是不安全的注册表，请将您的注册表主机值添加到/etc/container/registries.conf的[registries.insecure]部分，以确保podman不会遇到TLS验证错误。

  3. 通过运行以下命令登录到OpenShift Container Platform 3注册表：

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>

  4. 通过运行以下命令登录到OpenShift Container Platform 4注册表：

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>

  5. 通过运行以下命令拉取OpenShift Container Platform 3镜像：

    $ podman pull <registry_url>:<port>/openshift/<image>

  6. 通过运行以下命令扫描OpenShift Container Platform 3镜像中已弃用的命名空间：

    $ oc get bc --all-namespaces --template='range .items
"BuildConfig:" .metadata.namespace/.metadata.name =>
"\t""ImageStream(FROM):" .spec.strategy.sourceStrategy.from.namespace/.spec.strategy.sourceStrategy.from.name
"\t""ImageStream(TO):" .spec.output.to.namespace/.spec.output.to.name
end'

  7. 运行以下命令，为 OpenShift Container Platform 4 注册表标记 OpenShift Container Platform 3 镜像

    $ podman tag <registry_url>:<port>/openshift/<image> \ (1)
  <registry_url>:<port>/openshift/<image> (2)
    1 指定 OpenShift Container Platform 3 集群的注册表 URL 和端口。
    2 指定 OpenShift Container Platform 4 集群的注册表 URL 和端口。

  8. 运行以下命令，将镜像推送到 OpenShift Container Platform 4 注册表

    $ podman push <registry_url>:<port>/openshift/<image> (1)
    1 指定 OpenShift Container Platform 4 集群。

  9. 运行以下命令，验证镜像是否具有有效的镜像流

    $ oc get imagestream -n openshift | grep <image>
    示例输出
    NAME      IMAGE REPOSITORY                                                      TAGS    UPDATED
my_image  image-registry.openshift-image-registry.svc:5000/openshift/my_image  latest  32 seconds ago

直接卷迁移未完成

如果直接卷迁移未完成，则目标集群可能与源集群具有不同的node-selector注释。

容器迁移工具包 (MTC) 迁移包含所有注释的命名空间，以保留安全上下文约束和调度要求。在直接卷迁移期间，MTC 在目标集群中从源集群迁移的命名空间中创建 Rsync 传输 Pod。如果目标集群命名空间与源集群命名空间的注释不同，则无法调度 Rsync 传输 Pod。Rsync Pod 保持Pending状态。

您可以通过执行以下步骤来识别和解决此问题。

步骤

  1. 检查MigMigration CR 的状态

    $ oc describe migmigration <pod> -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. 再次运行迁移计划。

错误消息和解决方案

本节描述您在使用容器迁移工具包 (MTC) 时可能遇到的常见错误消息以及如何解决其根本原因。

首次访问 MTC 控制台时显示 CA 证书错误

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

要解决此问题，请导航到错误消息中显示的oauth-authorization-server URL 并接受证书。要永久解决此问题，请将证书添加到 Web 浏览器的信任存储区。

如果您已接受证书后显示未授权消息，请导航到 MTC 控制台并刷新网页。

MTC 控制台中的 OAuth 超时错误

如果您在接受自签名证书后在 MTC 控制台中显示连接超时消息，则可能原因如下

要确定超时原因

  • 使用浏览器 Web 检查器检查 MTC 控制台网页。

  • 检查Migration UI Pod 日志中的错误。

证书由未知机构签名的错误

如果您使用自签名证书来保护集群或 MTC 的复制存储库，则证书验证可能会失败并显示以下错误消息：证书由未知机构签名。

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

步骤

从远程端点下载 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 捆绑文件的名称。

Velero Pod 日志中的备份存储位置错误

如果VeleroBackup自定义资源包含对不存在的备份存储位置 (BSL) 的引用，则Velero Pod 日志可能会显示以下错误消息

$ oc logs <Velero_Pod> -n openshift-migration
示例输出
level=error msg="Error checking repository for stale locks" error="error getting backup storage location: BackupStorageLocation.velero.io \"ts-dpa-1\" not found" error.file="/remote-source/src/github.com/vmware-tanzu/velero/pkg/restic/repository_manager.go:259"

您可以忽略这些错误消息。缺少 BSL 不会导致迁移失败。

Velero Pod 日志中的 Pod 卷备份超时错误

如果迁移失败是因为 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 控制台中，导航到**操作符**→**已安装的操作符**。

  2. 单击**容器迁移工具包操作符**。

  3. 在**MigrationController**选项卡中，单击**migration-controller**。

  4. 在**YAML**选项卡中，更新以下参数值

    spec:
  restic_timeout: 1h (1)
    1 有效单位为h（小时）、m（分钟）和s（秒），例如3h30m15s。

  5. 单击**保存**。

MigMigration 自定义资源中的 Restic 验证错误

如果使用文件系统数据复制方法迁移持久卷时数据验证失败，则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>

从启用了 root_squash 的 NFS 存储迁移时出现 Restic 权限错误

如果您正在从 NFS 存储迁移数据并且启用了root_squash，则Restic映射到nfsnobody并且没有权限执行迁移。Restic Pod 日志中会显示以下错误。

示例输出
backup=openshift-migration/<backup_id> controller=pod-volume-backup error="fork/exec /usr/bin/restic: permission denied" error.file="/go/src/github.com/vmware-tanzu/velero/pkg/controller/pod_volume_backup_controller.go:280" error.function="github.com/vmware-tanzu/velero/pkg/controller.(*podVolumeBackupController).processBackup" logSource="pkg/controller/pod_volume_backup_controller.go:280" name=<backup_id> namespace=openshift-migration

您可以通过为 Restic 创建补充组并将组 ID 添加到MigrationController CR 清单来解决此问题。

步骤

  1. 在 NFS 存储上为 Restic 创建一个补充组。

  2. 在 NFS 目录上设置setgid位，以便继承组所有权。

  3. 将restic_supplemental_groups参数添加到源集群和目标集群上的MigrationController CR 清单中

    spec:
  restic_supplemental_groups: <group_id> (1)
    1 指定补充组 ID。

  4. 等待Restic Pod 重启，以便应用更改。

已知问题

此版本存在以下已知问题

  • 在迁移过程中，容器迁移工具包 (MTC) 会保留以下命名空间注释：

    • openshift.io/sa.scc.mcs

    • openshift.io/sa.scc.supplemental-groups

    • openshift.io/sa.scc.uid-range

      这些注释保留了 UID 范围，确保容器在目标集群上保留其文件系统权限。但存在迁移的 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）

回滚迁移

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

您也可以手动回滚迁移。

使用 MTC Web 控制台回滚迁移

您可以使用容器迁移工具包 (MTC) Web 控制台回滚迁移。

直接卷迁移 (DVM) 失败后，以下资源将保留在已迁移的命名空间中以进行调试：

  • 配置映射（源集群和目标集群）

  • Secret 对象（源集群和目标集群）

  • Rsync CR（源集群）

这些资源不会影响回滚。您可以手动删除它们。

如果您稍后成功运行相同的迁移计划，则会自动删除失败迁移的资源。

如果您的应用程序在迁移失败期间停止，则必须回滚迁移以防止持久卷中的数据损坏。

如果应用程序在迁移期间未停止，则不需要回滚，因为原始应用程序仍在源集群上运行。

步骤

  1. 在 MTC Web 控制台中，单击**迁移计划**。

  2. 单击迁移计划旁边的选项菜单kebab，然后在**迁移**下选择**回滚**。

  3. 单击**回滚**并等待回滚完成。

    在迁移计划详细信息中，将显示**回滚成功**。

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

    1. 单击**主页**→**项目**。

    2. 单击已迁移的项目以查看其状态。

    3. 在**路由**部分，单击**位置**以验证应用程序是否正常运行（如果适用）。

    4. 单击**工作负载**→**Pod**以验证 Pod 是否在已迁移的命名空间中运行。

    5. 单击**存储**→**持久卷**以验证已迁移的持久卷是否已正确配置。

从命令行界面回滚迁移

您可以通过从命令行界面创建MigMigration自定义资源 (CR) 来回滚迁移。

直接卷迁移 (DVM) 失败后，以下资源将保留在已迁移的命名空间中以进行调试：

  • 配置映射（源集群和目标集群）

  • Secret 对象（源集群和目标集群）

  • Rsync 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: <migmigration>
  namespace: openshift-migration
spec:
...
  rollback: true
...
  migPlanRef:
    name: <migplan> (1)
    namespace: openshift-migration
EOF
    1 指定关联的MigPlan CR 的名称。

  2. 在 MTC Web 控制台中，验证已迁移的项目资源是否已从目标集群中删除。

  3. 验证已迁移的项目资源是否存在于源集群中，以及应用程序是否正在运行。

手动回滚迁移

您可以通过删除stage Pod 并取消暂停应用程序来手动回滚失败的迁移。

如果您成功运行相同的迁移计划，则会自动删除失败迁移的资源。

直接卷迁移 (DVM) 失败后，以下资源将保留在已迁移的命名空间中：

  • 配置映射（源集群和目标集群）

  • Secret 对象（源集群和目标集群）

  • Rsync CR（源集群）

这些资源不会影响回滚。您可以手动删除它们。
步骤

  1. 删除所有集群上的stage Pod。

    $ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) (1)
    1 MigPlan CR 中指定的命名空间。

  2. 通过将副本数缩放到迁移前的数量来取消暂停源集群上的应用程序。

    $ oc scale deployment <deployment> --replicas=<premigration_replicas>

    Deployment CR 中的migration.openshift.io/preQuiesceReplicas注释显示迁移前的副本数。

    apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
    migration.openshift.io/preQuiesceReplicas: "1"

  3. 验证应用程序 Pod 是否正在源集群上运行。

    $ oc get pod -n <namespace>

其他资源