×
故障排除
MTC 工作流程
您可以使用容器迁移工具包 (MTC) 网络控制台或 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 网络控制台迁移应用程序涉及以下步骤：
-
在所有集群上安装容器迁移工具包操作符。
您可以在具有有限或无互联网访问权限的受限环境中安装容器迁移工具包操作符。源集群和目标集群必须彼此之间以及镜像注册表之间具有网络访问权限。
-
配置复制存储库，这是一个 MTC 用于迁移数据的中间对象存储。
迁移期间，源集群和目标集群必须能够访问复制存储库。如果您使用的是代理服务器，则必须将其配置为允许复制存储库和集群之间的网络流量。
-
将源集群添加到 MTC 网络控制台。
-
将复制存储库添加到 MTC 网络控制台。
-
创建一个迁移计划，其中包含以下数据迁移选项之一：
-
复制：MTC 将数据从源集群复制到复制存储库，然后从复制存储库复制到目标集群。
如果您使用的是直接镜像迁移或直接卷迁移，则镜像或卷将直接从源集群复制到目标集群。
-
移动：MTC 将远程卷（例如 NFS）从源集群卸载，在目标集群上创建指向远程卷的 PV 资源，然后将远程卷挂载到目标集群。目标集群上运行的应用程序使用源集群正在使用的同一远程卷。远程卷必须可供源集群和目标集群访问。
尽管此图中未显示复制存储库，但它是迁移所必需的。
-
-
运行迁移计划，选择以下选项之一：
-
分阶段将数据复制到目标集群，而不会停止应用程序。
可以多次运行分阶段迁移，以便在迁移之前将大部分数据复制到目标。运行一个或多个分阶段迁移可以缩短切换迁移的持续时间。
-
切换停止源集群上的应用程序并将资源移动到目标集群。
可选：您可以清除在迁移期间停止源集群上的事务复选框。
-
关于 MTC 自定义资源
容器迁移工具包 (MTC) 创建以下自定义资源 (CR)：
MigCluster（配置，MTC 集群）：集群定义
MigStorage（配置，MTC 集群）：存储定义
MigPlan (配置，MTC 集群): 迁移计划
MigPlan CR 描述了源集群和目标集群、复制库以及正在迁移的命名空间。它与 0 个、1 个或多个 MigMigration CR 相关联。
|
删除 |
BackupStorageLocation (配置，MTC 集群): Velero 备份对象的存储位置
VolumeSnapshotLocation (配置，MTC 集群): Velero 卷快照的存储位置
备份 (操作，源集群): 运行迁移计划时，MigMigration CR 在每个源集群上创建两个 Velero 备份 CR。
-
Kubernetes 对象的备份 CR #1
-
PV 数据的备份 CR #2
恢复 (操作，目标集群): 运行迁移计划时，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-migrationMigAnalytic
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) 查看迁移计划资源以监控正在运行的迁移或对失败的迁移进行故障排除。
步骤
-
在 MTC Web 控制台中，单击迁移计划。
-
单击迁移计划旁边的迁移数量以查看迁移页面。
-
单击迁移以查看迁移详细信息。
-
展开迁移资源以树状视图查看迁移资源及其状态。
要对失败的迁移进行故障排除，请从失败的高级资源开始，然后沿资源树向下遍历到较低级别的资源。
-
单击资源旁边的选项菜单
并选择以下选项之一-
复制
oc describe命令会将命令复制到剪贴板。-
登录到相关集群，然后运行该命令。
资源的条件和事件将以 YAML 格式显示。
-
-
复制
oc logs命令会将命令复制到剪贴板。-
登录到相关集群，然后运行该命令。
如果资源支持日志过滤，则会显示过滤后的日志。
-
-
查看 JSON会在 Web 浏览器中以 JSON 格式显示资源数据。
数据与
oc get <resource>命令的输出相同。
-
查看迁移计划日志
您可以查看迁移计划的聚合日志。您可以使用 MTC Web 控制台将命令复制到剪贴板，然后从命令行界面 (CLI) 运行该命令。
该命令将显示以下 Pod 的过滤日志
-
迁移控制器 -
Velero -
Restic -
Rsync -
Stunnel -
注册表
步骤
-
在 MTC Web 控制台中，单击迁移计划。
-
点击迁移计划旁边的**迁移**数字。
-
点击**查看日志**。
-
点击复制图标将
oc logs命令复制到剪贴板。 -
登录到相关集群并在CLI上输入命令。
迁移计划的聚合日志将显示。
使用迁移日志阅读器
您可以使用迁移日志阅读器显示所有迁移日志的单个过滤视图。
步骤
-
获取
mig-log-readerpod$ oc -n openshift-migration get pods | grep log -
输入以下命令以显示单个迁移日志
$ 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 控制台访问性能指标并运行查询。
步骤
-
在 OpenShift Container Platform Web 控制台中，点击**监控** → **指标**。
-
输入 PromQL 查询，选择要显示的时间窗口，然后点击**运行查询**。
如果您的 Web 浏览器未显示所有结果，请使用 Prometheus 控制台。
提供的指标
MigrationController自定义资源 (CR) 提供MigMigration CR 计数及其 API 请求的指标。
cam_app_workload_migrations
此指标是随时间推移MigMigration CR 的计数。它与mtc_client_request_count和mtc_client_request_elapsed指标一起使用，可以将 API 请求信息与迁移状态更改关联起来。此指标包含在遥测中。
| 可查询标签名称 | 示例标签值 | 标签描述 |
|---|---|---|
status |
|
|
type |
stage, final |
|
mtc_client_request_count
此指标是MigrationController发出的 Kubernetes API 请求的累积计数。它不包含在遥测中。
| 可查询标签名称 | 示例标签值 | 标签描述 |
|---|---|---|
cluster |
|
发出请求的集群 |
component |
|
发出请求的子控制器 API |
function |
|
发出请求的函数 |
kind |
|
发出请求的 Kubernetes 类型 |
mtc_client_request_elapsed
此指标是MigrationController发出的 Kubernetes API 请求的累积延迟（以毫秒为单位）。它不包含在遥测中。
| 可查询标签名称 | 示例标签值 | 标签描述 |
|---|---|---|
cluster |
|
发出请求的集群 |
component |
|
发出请求的子控制器 API |
function |
|
发出请求的函数 |
kind |
|
发出请求的 Kubernetes 资源 |
有用的查询
该表列出了一些可用于监控性能的有用查询。
| 查询 | 描述 |
|---|---|
|
发出的 API 请求数量，按请求类型排序 |
|
发出的 API 请求总数 |
|
API 请求延迟，按请求类型排序 |
|
API 请求的总延迟 |
|
API 请求的平均延迟 |
|
API 请求的平均延迟，按请求类型排序 |
|
正在运行的迁移计数，乘以 100 以便于与请求计数一起查看 |
使用 must-gather 工具
您可以使用must-gather工具收集日志、指标和有关 MTC 自定义资源的信息。
必须将must-gather数据附加到所有客户案例。
您可以收集过去一小时或 24 小时的数据，并使用 Prometheus 控制台查看数据。
先决条件
-
您必须以具有
cluster-admin角色的用户身份登录到 OpenShift Container Platform 集群。 -
您必须安装 OpenShift CLI (
oc)。
步骤
-
导航到要存储
must-gather数据的目录。 -
针对以下数据收集选项之一运行
oc adm must-gather命令-
要收集过去 24 小时的数据，请运行以下命令
$ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.8此命令将数据保存为
must-gather/must-gather.tar.gz文件。您可以将此文件上传到Red Hat 客户门户上的支持案例。 -
要收集过去 24 小时的数据，请运行以下命令
$ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.8 -- /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描述命令
使用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-2d8qlvelero describe请求的输出中显示以下类型的还原错误和警告
-
Velero：与 Velero 本身操作相关的消息列表，例如，与连接到云、读取备份文件等相关的消息 -
Cluster：与备份或还原集群范围资源相关的消息列表 -
Namespaces：与备份或还原存储在命名空间中的资源相关的消息列表
这些类别中的一项或多项错误会导致Restore操作的状态为PartiallyFailed而不是Completed。警告不会导致完成状态发生变化。
|
日志命令
使用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 中其余的对象。
步骤
-
检查
MigMigrationCR 的状态$ 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 -
使用 Velero 的
describe命令检查RestoreCR 的状态$ 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 -
使用 Velero 的
logs命令检查RestoreCR 日志$ 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-x4lbfRestoreCR 日志错误消息“服务器找不到请求的资源”指明了部分失败迁移的原因。
使用 MTC 自定义资源进行故障排除
您可以检查以下容器迁移工具包 (MTC) 自定义资源 (CR) 以排除迁移失败的原因
-
MigCluster -
MigStorage -
MigPlan -
BackupStorageLocationBackupStorageLocationCR 包含一个migrationcontroller标签，用于标识创建该 CR 的 MTC 实例。labels: migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93 -
VolumeSnapshotLocationVolumeSnapshotLocationCR 包含一个migrationcontroller标签，用于标识创建该 CR 的 MTC 实例。labels: migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93 -
MigMigration -
BackupMTC 将迁移的持久卷 (PV) 在目标集群上的回收策略更改为
Retain。BackupCR 包含一个openshift.io/orig-reclaim-policy注解，指示原始回收策略。您可以手动恢复迁移的 PV 的回收策略。 -
Restore
步骤
-
列出
openshift-migration命名空间中的MigMigrationCR$ oc get migmigration -n openshift-migration示例输出NAME AGE 88435fe0-c9f8-11e9-85e6-5d593ce65e10 6m42s -
检查
MigMigrationCR$ 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常见问题和注意事项
本节描述了迁移过程中可能导致问题的常见问题和注意事项。
直接卷迁移未完成
如果直接卷迁移未完成，则目标集群可能没有与源集群相同的 node-selector 注解。
容器迁移工具包 (MTC) 迁移具有所有注解的命名空间，以保留安全上下文约束和调度要求。在直接卷迁移过程中，MTC 在从源集群迁移的命名空间的目标集群中创建 Rsync 传输 Pod。如果目标集群命名空间没有与源集群命名空间相同的注解，则无法调度 Rsync 传输 Pod。Rsync Pod 保持 Pending 状态。
您可以通过执行以下步骤来识别和解决此问题。
步骤
-
检查
MigMigrationCR 的状态$ oc describe migmigration <pod> -n openshift-migration输出包括以下状态消息
示例输出Some or all transfer pods are not running for more than 10 mins on destination cluster -
在源集群上，获取已迁移命名空间的详细信息
$ oc get namespace <namespace> -o yaml (1)1 指定已迁移的命名空间。 -
在目标集群上，编辑已迁移的命名空间
$ oc edit namespace <namespace> -
添加缺少的
openshift.io/node-selector注解到已迁移的命名空间，如下例所示apiVersion: v1 kind: Namespace metadata: annotations: openshift.io/node-selector: "region=east" ... -
重新运行迁移计划。
错误消息和解决方案
本节描述了您在使用容器迁移工具包 (MTC) 时可能遇到的常见错误消息以及如何解决其根本原因。
首次访问 MTC 控制台时显示 CA 证书错误
如果在您第一次尝试访问 MTC 控制台时显示 CA 证书错误 消息，则可能的原因是在其中一个集群中使用了自签名 CA 证书。
要解决此问题，请导航到错误消息中显示的 oauth-authorization-server URL 并接受证书。要永久解决此问题，请将证书添加到 Web 浏览器的信任存储区。
如果您在接受证书后显示 Unauthorized 消息，请导航到 MTC 控制台并刷新网页。
MTC 控制台中的 OAuth 超时错误
如果您在接受自签名证书后在 MTC 控制台中显示 连接超时 消息，则可能的原因如下
-
中断对 OAuth 服务器的网络访问
-
中断对 OpenShift Container Platform 控制台的网络访问
-
阻止访问
oauth-authorization-serverURL 的代理配置。有关详细信息，请参阅 由于 OAuth 超时错误导致 MTC 控制台不可访问。
要确定超时原因
-
使用浏览器 Web 检查器检查 MTC 控制台网页。
-
检查
Migration UIPod 日志中的错误。
证书由未知机构签名的错误
如果您使用自签名证书来保护集群或 MTC 的复制存储库，则证书验证可能会失败，并显示以下错误消息：证书由未知机构签名。
您可以创建一个自定义 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 捆绑文件的名称。 |
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 不会导致迁移失败。
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=v1restic_timeout 的默认值为一小时。对于大型迁移，您可以增加此参数，但请记住，较高的值可能会延迟错误消息的返回。
步骤
-
在 OpenShift Container Platform Web 控制台中，导航到**操作符** → **已安装的操作符**。
-
单击**容器迁移工具包操作符**。
-
在**MigrationController** 选项卡中，单击**migration-controller**。
-
在**YAML** 选项卡中，更新以下参数值
spec: restic_timeout: 1h (1)1 有效单位为 h（小时）、m（分钟）和s（秒），例如3h30m15s。 -
单击**保存**。
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 以识别数据验证错误的来源。
步骤
-
登录到目标集群。
-
查看
RestoreCR$ 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 -
查看
PodVolumeRestoreCR$ oc describe <migration-example-rvwcm-98t49>输出结果会识别出记录错误的
ResticPod。示例输出completionTimestamp: 2020-05-01T20:49:12Z errors: 1 resticErrors: 1 ... resticPod: <restic-nr2v5> -
查看
ResticPod 日志以查找错误$ 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清单中来解决此问题。
步骤
-
在NFS存储上为Restic创建一个补充组。
-
在NFS目录上设置
setgid位，以便继承组所有权。 -
在源集群和目标集群上将
restic_supplemental_groups参数添加到MigrationControllerCR清单中spec: restic_supplemental_groups: <group_id> (1)1 指定补充组ID。 -
等待
ResticPod重启，以便应用更改。
在OpenShift Container Platform上运行的工作负载中自动应用跳过SELinux重新标记的解决方法（使用spc_t）
当尝试使用容器迁移工具包(MTC)迁移命名空间及其关联的大容量卷时，rsync-server可能会冻结，且没有任何进一步的信息来排查问题。
诊断是否需要跳过SELinux重新标记的解决方法
在运行直接卷迁移(DVM)的rsync-server所在的节点的kubelet日志中搜索Unable to attach or mount volumes for pod…timed out waiting for the condition错误。
kubelet日志示例
kubenswrapper[3879]: W0326 16:30:36.749224 3879 volume_linux.go:49] Setting volume ownership for /var/lib/kubelet/pods/8905d88e-6531-4d65-9c2a-eff11dc7eb29/volumes/kubernetes.io~csi/pvc-287d1988-3fd9-4517-a0c7-22539acd31e6/mount and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699
kubenswrapper[3879]: E0326 16:32:02.706363 3879 kubelet.go:1841] "Unable to attach or mount volumes for pod; skipping pod" err="unmounted volumes=[8db9d5b032dab17d4ea9495af12e085a], unattached volumes=[crane2-rsync-server-secret 8db9d5b032dab17d4ea9495af12e085a kube-api-access-dlbd2 crane2-stunnel-server-config crane2-stunnel-server-secret crane2-rsync-server-config]: timed out waiting for the condition" pod="caboodle-preprod/rsync-server"
kubenswrapper[3879]: E0326 16:32:02.706496 3879 pod_workers.go:965] "Error syncing pod, skipping" err="unmounted volumes=[8db9d5b032dab17d4ea9495af12e085a], unattached volumes=[crane2-rsync-server-secret 8db9d5b032dab17d4ea9495af12e085a kube-api-access-dlbd2 crane2-stunnel-server-config crane2-stunnel-server-secret crane2-rsync-server-config]: timed out waiting for the condition" pod="caboodle-preprod/rsync-server" podUID=8905d88e-6531-4d65-9c2a-eff11dc7eb29使用跳过SELinux重新标记的解决方法来解决问题
要解决此问题，请使用MigrationController自定义资源(CR)在源MigClusters和目标MigClusters中将migration_rsync_super_privileged参数设置为true。
MigrationController CR示例
apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
name: migration-controller
namespace: openshift-migration
spec:
migration_rsync_super_privileged: true (1)
azure_resource_group: ""
cluster_name: host
mig_namespace_limit: "10"
mig_pod_limit: "100"
mig_pv_limit: "100"
migration_controller: true
migration_log_reader: true
migration_ui: true
migration_velero: true
olm_managed: true
restic_timeout: 1h
version: 1.8.3| 1 | migration_rsync_super_privileged参数的值指示是否以超级特权容器（spc_t selinux context）运行Rsync Pod。有效设置为true或false。 |
回滚迁移
您可以使用MTC Web控制台或CLI回滚迁移。
您也可以手动回滚迁移。
使用MTC Web控制台回滚迁移
您可以使用容器迁移工具包(MTC) Web控制台回滚迁移。
|
直接卷迁移(DVM)失败后，以下资源将保留在已迁移的命名空间中以进行调试
这些资源不会影响回滚。您可以手动删除它们。 如果您稍后成功运行相同的迁移计划，则会自动删除失败迁移的资源。 |
如果应用程序在迁移期间停止，则必须回滚迁移以防止持久卷中的数据损坏。
如果应用程序在迁移期间未停止，则不需要回滚，因为原始应用程序仍在源集群上运行。
步骤
-
在MTC Web控制台中，单击**迁移计划**。
-
单击迁移计划旁边的选项菜单
，然后在**迁移**下选择**回滚**。 -
单击**回滚**并等待回滚完成。
在迁移计划详细信息中，将显示**回滚成功**。
-
在源集群的OpenShift Container Platform Web控制台中验证回滚是否成功
-
单击**主页** → **项目**。
-
单击已迁移的项目以查看其状态。
-
在**路由**部分，单击**位置**以验证应用程序是否正常运行（如果适用）。
-
单击**工作负载** → **Pod** 以验证 Pod 是否在已迁移的命名空间中运行。
-
单击**存储** → **持久卷** 以验证已迁移的持久卷是否已正确置备。
-
从命令行界面回滚迁移
您可以通过从命令行界面创建MigMigration自定义资源(CR)来回滚迁移。
|
直接卷迁移(DVM)失败后，以下资源将保留在已迁移的命名空间中以进行调试
这些资源不会影响回滚。您可以手动删除它们。 如果您稍后成功运行相同的迁移计划，则会自动删除失败迁移的资源。 |
如果应用程序在迁移期间停止，则必须回滚迁移以防止持久卷中的数据损坏。
如果应用程序在迁移期间未停止，则不需要回滚，因为原始应用程序仍在源集群上运行。
步骤
-
根据以下示例创建
MigMigrationCR$ 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 EOF1 指定关联的 MigPlanCR的名称。 -
在MTC Web控制台中，验证已迁移的项目资源是否已从目标集群中删除。
-
验证已迁移的项目资源是否存在于源集群中，并且应用程序正在运行。
手动回滚迁移
您可以通过删除stage Pod并取消应用程序的静默来手动回滚失败的迁移。
如果您成功运行相同的迁移计划，则会自动删除失败迁移的资源。
|
直接卷迁移(DVM)失败后，以下资源将保留在已迁移的命名空间中
这些资源不会影响回滚。您可以手动删除它们。 |
步骤
-
删除所有集群上的
stagePod$ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) (1)1 MigPlanCR中指定的命名空间。 -
通过将副本数扩展到迁移前的数量来取消源集群上应用程序的静默
$ oc scale deployment <deployment> --replicas=<premigration_replicas>DeploymentCR中的migration.openshift.io/preQuiesceReplicas注释显示迁移前的副本数量apiVersion: extensions/v1beta1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" migration.openshift.io/preQuiesceReplicas: "1" -
验证应用程序 Pod 是否正在源集群上运行
$ oc get pod -n <namespace>