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. 其他资源