搜索

12.4. 常见问题和关注

download PDF

本节介绍在迁移过程中可能导致问题的常见问题。

12.4.1. 更新已弃用的内部镜像

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

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

先决条件

  • 必须安装 podman
  • 您必须以具有 cluster-admin 权限的用户身份登录。
  • 如果您使用不安全的 registry,请将 registry 主机值添加到 /etc/container/registries.conf[registries.insecure] 部分,以确保 Podman 不会遇到 TLS 验证错误。
  • 内部 registry 必须在源和目标集群上公开。

流程

  1. 确保内部 registry 在 OpenShift Container Platform 3 和 4 集群中公开。

    OpenShift 镜像 registry 默认在 OpenShift Container Platform 4 中公开。

  2. 如果您使用不安全的 registry,请将 registry 主机值添加到 /etc/container/registries.conf[registries.insecure] 部分,以确保 Podman 不会遇到 TLS 验证错误。
  3. 运行以下命令登录到 OpenShift Container Platform 3 registry:

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
  4. 运行以下命令登录到 OpenShift Container Platform 4 registry:

    $ 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 registry 标记 OpenShift Container Platform 3 镜像:

    $ podman tag <registry_url>:<port>/openshift/<image> \ 1
      <registry_url>:<port>/openshift/<image> 2
    1
    指定 OpenShift Container Platform 3 集群的 registry URL 和端口。
    2
    指定 OpenShift Container Platform 4 集群的 registry URL 和端口。
  8. 运行以下命令将镜像推送到 OpenShift Container Platform 4 registry 中:

    $ 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

12.4.2. 直接卷迁移未完成

如果直接卷迁移未完成,则目标集群可能没有与源集群相同的 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. 再次运行迁移计划。

12.4.3. 错误信息和解决方案

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

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

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

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

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

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

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

要确定超时的原因:

  • 使用浏览器 web 检查器检查 MTC 控制台网页。
  • 检查 Migration UI pod 日志中的错误。

12.4.3.3. 由未知颁发机构签名的证书错误

如果您使用自签名证书来保护集群或 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 捆绑包文件的名称。

12.4.3.4. 在 Velero pod 日志中有备份存储位置错误

如果 Velero Backup 自定义资源包含对不存在的备份存储位置(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 不会导致迁移失败。

12.4.3.5. 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 控制台中导航至 Operators Installed 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

12.4.3.6. 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>

12.4.3.7. 从启用了 root_squash 的 NFS 存储中迁移时的 Restic 权限错误

如果您要从 NFS 存储中迁移数据,并且启用了 root_squashRestic 会映射到 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 重启,以便应用更改。

12.4.4. 已知问题

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

  • 在迁移过程中,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
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.