容器迁移工具套件（MTC）

流程

1. 获取 MigrationController CR 清单：

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

2. 更新代理参数：

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
     noProxy: example.com 2

   1

   用于直接卷迁移的 stunnel 代理 URL。

   2

   要排除代理的目标域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。

   在域前面加 . 来仅匹配子域。例如： .y.com 匹配 x.y.com，但不匹配 y.com。使用 * 可对所有目的地绕过所有代理。如果您扩展了未包含在安装配置中 networking.machineNetwork[].cidr 字段定义的 worker，您必须将它们添加到此列表中，以防止连接问题。

   如果未设置 httpProxy 和 httpsProxy 字段，则此字段将被忽略。

3. 将清单保存为 migration-controller.yaml。

4. 应用更新的清单：

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

流程

1. 设置 BUCKET 变量：

   $ BUCKET=<your_bucket>

2. 设置 REGION 变量：

   $ REGION=<your_region>

3. 创建 AWS S3 存储桶：

   $ aws s3api create-bucket \
       --bucket $BUCKET \
       --region $REGION \
       --create-bucket-configuration LocationConstraint=$REGION 1

   1

   us-east-1 不支持 LocationConstraint。如果您的区域是 us-east-1，忽略 --create-bucket-configuration LocationConstraint=$REGION。

4. 创建一个 IAM 用户：

   $ aws iam create-user --user-name velero 1

   1

   如果要使用 Velero 备份具有多个 S3 存储桶的集群，请为每个集群创建一个唯一用户名。

5. 创建 velero-policy.json 文件：

   $ cat > velero-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}/*"
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket",
                   "s3:GetBucketLocation",
                   "s3:ListBucketMultipartUploads"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}"
               ]
           }
       ]
   }
   EOF

6. 附加策略，为 velero 用户提供所需的最低权限：

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero \
     --policy-document file://velero-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>,
           "AccessKeyId": <AWS_ACCESS_KEY_ID>
     }
   }

   记录 AWS_SECRET_ACCESS_KEY 和 AWS_ACCESS_KEY_ID。您可以使用凭证将 AWS 添加为复制存储库。

流程

1. 登录到 GCP:

   $ gcloud auth login

2. 设置 BUCKET 变量：

   $ BUCKET=<bucket> 1

   1

   指定存储桶名称。

3. 创建存储桶：

   $ gsutil mb gs://$BUCKET/

4. 将 PROJECT_ID 变量设置为您的活跃项目：

   $ PROJECT_ID=$(gcloud config get-value project)

5. 创建服务帐户：

   $ gcloud iam service-accounts create velero \
       --display-name "Velero service account"

6. 列出服务帐户：

   $ gcloud iam service-accounts list

7. 设置 SERVICE_ACCOUNT_EMAIL 变量，使其与 email 值匹配：

   $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --filter="displayName:Velero service account" \
       --format 'value(email)')

8. 附加策略，为 velero 用户提供所需的最低权限：

   $ 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
       storage.objects.create
       storage.objects.delete
       storage.objects.get
       storage.objects.list
       iam.serviceAccounts.signBlob
   )

9. 创建 velero.server 自定义角色：

   $ gcloud iam roles create velero.server \
       --project $PROJECT_ID \
       --title "Velero Server" \
       --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

10. 为项目添加 IAM 策略绑定：

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server

11. 更新 IAM 服务帐户：

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

12. 将 IAM 服务帐户的密钥保存到当前目录中的 credentials-velero 文件中：

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

    您可以使用 credentials-velero 文件将 GCP 添加为复制存储库。

流程

1. 登录到 Azure:

   $ az login

2. 设置 AZURE_RESOURCE_GROUP 变量：

   $ AZURE_RESOURCE_GROUP=Velero_Backups

3. 创建 Azure 资源组：

   $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 1

   1

   指定位置。

4. 设置 AZURE_STORAGE_ACCOUNT_ID 变量：

   $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"

5. 创建 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

6. 设置 BLOB_CONTAINER 变量：

   $ BLOB_CONTAINER=velero

7. 创建 Azure Blob 存储容器：

   $ az storage container create \
     -n $BLOB_CONTAINER \
     --public-access off \
     --account-name $AZURE_STORAGE_ACCOUNT_ID

8. 为 velero 创建服务主体和凭证：

   $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv`
     AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv`

9. 创建一个带有 Contributor 角色的服务主体，分配一个特定的 --role 和 --scopes:

   $ AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
                                                   --role "Contributor" \
                                                   --query 'password' -o tsv \
                                                   --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID/resourceGroups/$AZURE_RESOURCE_GROUP`

   CLI 为您生成一个密码。确保您记录了密码。

10. 创建服务主体后，获取客户端 ID。

    $ AZURE_CLIENT_ID=`az ad app credential list --id <your_app_id>`

    注意

    要成功完成此操作，您必须知道您的 Azure 应用程序 ID。

11. 在 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

    您可以使用 credentials-velero 文件将 Azure 添加为复制存储库。

流程

1. 获取 MigrationController CR 清单：

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

2. 更新代理参数：

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1
     noProxy: example.com 2

   1

   用于直接卷迁移的 stunnel 代理 URL。

   2

   要排除代理的目标域名、域、IP 地址或其他网络 CIDR 的逗号分隔列表。

   在域前面加 . 来仅匹配子域。例如： .y.com 匹配 x.y.com，但不匹配 y.com。使用 * 可对所有目的地绕过所有代理。如果您扩展了未包含在安装配置中 networking.machineNetwork[].cidr 字段定义的 worker，您必须将它们添加到此列表中，以防止连接问题。

   如果未设置 httpProxy 和 httpsProxy 字段，则此字段将被忽略。

3. 将清单保存为 migration-controller.yaml。

4. 应用更新的清单：

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

流程

1. 要以 root 用户身份运行 Rsync，请根据本例配置 MigMigration CR：

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     [...]
     runAsRoot: true

2. 要将 Rsync 作为特定用户 ID (UID)或特定组 ID (GID)运行，请根据本例配置 MigMigration CR：

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     [...]
     runAsUser: 10010001
     runAsGroup: 3

验证

1. 运行以下命令，验证 OLM 是否已完成 OADP 和 MTC 的升级：

   $ oc -n openshift-migration get subscriptions.operators.coreos.com mtc-operator -o json | jq '.status | (."state"=="AtLatestKnown")'

2. 当返回 true 值时，运行以下命令来验证每个订阅使用的频道：

   $ oc -n openshift-migration get sub -o json | jq -r '.items[] | {name: .metadata.name, channel: .spec.channel }'

   输出示例

   {
     "name": "mtc-operator",
     "channel": "release-v1.8"
   }
   {
     "name": "redhat-oadp-operator-stable-1.0-mtc-operator-catalog-openshift-marketplace",
     "channel": "stable-1.2"
   }

   Confirm that the `mtc-operator.v1.8.0` and `oadp-operator.v1.2.x` packages are installed by running the following command:

   $ oc -n openshift-migration get csv

   输出示例

   NAME                     DISPLAY                                     VERSION   REPLACES                 PHASE
   mtc-operator.v1.8.0      Migration Toolkit for Containers Operator   1.8.0     mtc-operator.v1.7.13     Succeeded
   oadp-operator.v1.2.2     OADP Operator                               1.2.2     oadp-operator.v1.0.13    Succeeded

流程

1. 将外部网络组件（如应用程序负载均衡器或反向代理）放在客户端和目标集群之间。
2. 更新 DNS 服务器上的源集群中的应用程序 FQDN，以返回 exterior 网络组件的 IP 地址。
3. 配置网络组件，将源域中为应用接收的请求发送到目标集群域中的负载均衡器。
4. 为 *.apps.source.example.com 域创建一个通配符 DNS 记录，指向源集群的负载均衡器的 IP 地址。
5. 为每个应用程序创建一个 DNS 记录，指向目标集群前面的 exterior 网络组件的 IP 地址。特定的 DNS 记录的优先级高于通配符记录，因此在解决应用 FQDN 时不会发生冲突。

1. 在目标集群的项目中创建一个路由，该路由配置为接受源集群中处理的应用程序 FQDN 的请求：

   $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
    -n <app1-namespace>

   新路由就位后，服务器接受对该 FQDN 的任何请求，并将它发送到对应的应用容器集。另外，当迁移应用程序时，会在目标集群域中创建另一个路由。请求会使用这些主机名之一到达迁移的应用。

2. 使用您的 DNS 供应商创建 DNS 记录，将源集群中的应用的 FQDN 指向目标集群的默认负载均衡器的 IP 地址。这会将来自源集群的流量重定向到目标集群。

   应用程序的 FQDN 解析到目标集群的负载均衡器。默认入口控制器路由器接受对该 FQDN 的请求，因为公开了该主机名的路由。

1. 将在安装过程中创建的默认入口控制器的 x509 证书替换为自定义证书。

2. 将这个证书配置为在 subjectAltName 字段中为源和目标集群包含通配符 DNS 域。

   新证书对于保护使用 DNS 域进行的连接有效。

流程

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. 登录到集群。

2. 获取 migration-controller 服务帐户令牌：

   $ oc create token migration-controller -n openshift-migration

   输出示例

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. 登录到 MTC web 控制台。
4. 在 MTC web 控制台中点 Clusters。
5. 点 Add cluster。

6. 填写以下字段：

   • Cluster name：集群名称可包含小写字母（a-z）和数字（0-9）。它不能包含空格或国际字符。
   • URL：指定 API 服务器 URL，例如 https://<www.example.com>:8443。
   • Service account token：粘贴 migration-controller 服务帐户令牌。

   • 公开的路由主机到镜像 registry：如果您使用直接镜像迁移，请指定源集群镜像 registry 公开的路由。

     要创建路由，请运行以下命令：

     • 对于 OpenShift Container Platform 3：

       $ oc create route passthrough --service=docker-registry --port=5000 -n default

     • 对于 OpenShift Container Platform 4：

       $ oc create route passthrough --service=image-registry --port=5000 -n openshift-image-registry

   • Azure cluster：如果使用 Azure 快照复制数据，您必须选择此选项。

     • Azure resource group：如果选择了 Azure cluster，则会显示此字段。指定 Azure 资源组。

       当在 Microsoft Azure 上创建 OpenShift Container Platform 集群时，会创建一个 Azure Resource Group，使其包含与集群关联的所有资源。在 Azure CLI 中，您可以通过发出以下命令显示所有资源组：

       $ az group list

       与 OpenShift Container Platform 集群关联的 ResourceGroups 被标记，其中 sample-rg-name 是您要提取并提供给 UI 的值：

       {
         "id": "/subscriptions/...//resourceGroups/sample-rg-name",
         "location": "centralus",
         "name": "...",
         "properties": {
           "provisioningState": "Succeeded"
         },
         "tags": {
           "kubernetes.io_cluster.sample-ld57c": "owned",
           "openshift_creationDate": "2019-10-25T23:28:57.988208+00:00"
         },
         "type": "Microsoft.Resources/resourceGroups"
       },

       此信息也可从 资源组 刀片的 Azure 门户 获取。

   • 需要 SSL 验证 ：可选：选择这个选项来验证到集群的安全套接字层(SSL)连接。
   • CA bundle file：如果选择了 Require SSL 验证，则会显示此字段。如果您为自签名证书创建了自定义 CA 证书捆绑包文件，请点 Browse，选择 CA 捆绑包文件并上传它。

7. 点 Add cluster。

   集群会出现在 Clusters 列表中。

流程

1. 在 MTC web 控制台中点 Replication repositories。
2. 点 Add repository。

3. 选择 Storage provider type 并填写以下字段：

   • 用于 S3 供应商的 AWS，包括 AWS 和 MCG:

     • Replication repository name：指定 MTC web 控制台中的复制存储库。
     • S3 bucket name：指定 S3 存储桶的名称。
     • S3 bucket region：指定 S3 存储桶区域。AWS S3 必填。对于某些 S3 供应商是可选的。检查 S3 供应商的产品文档，以获取预期值。
     • S3 端点：指定 S3 服务的 URL，而不是存储桶，例如：https://<s3-storage.apps.cluster.com>。通用 S3 供应商必填。您必须使用 https:// 前缀。
     • S3 provider access key ：为 AWS 指定 <AWS_SECRET_ACCESS_KEY>，或者为 MCG 和其他 S3 供应商指定 S3 供应商访问密钥。
     • S3 provider secret access key ：为 AWS 指定 <AWS_ACCESS_KEY_ID>，或为 MCG 和其他 S3 供应商指定 S3 provider secret 访问密钥。
     • Require SSL verification：如果您使用的是通用 S3 供应商，则清除此复选框。
     • 如果您为自签名证书创建了自定义 CA 证书捆绑包，点 Browse 并浏览到 Base64 编码的文件。

   • 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. 在 MTC web 控制台中点 Migration Plan。
2. 点 Add migration plan。

3. 输入 Plan 名称。

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

4. 选择 Source cluster、Target cluster 和 Repository。
5. 点击 Next。
6. 选择要迁移的项目。
7. 可选：点击项目旁边的编辑图标来更改目标命名空间。
8. 点击 Next。

9. 为每个 PV 选择一个 迁移类型：

   • Copy 选项将源集群的 PV 中的数据复制到复制存储库中，然后在目标集群中恢复新创建的具有类似特征的 PV 上的数据。
   • Move 选项从源集群中卸载一个远程卷（例如 NFS），在目标集群上创建一个指向这个远程卷的 PV 资源，然后在目标集群中挂载远程卷。在目标集群中运行的应用程序使用源集群使用的同一远程卷。
10. 点击 Next。

11. 为每个 PV 选择 Copy method：

    • 快照复制使用云供应商的快照功能备份和恢复数据。它比 Filesystem copy 要快得多。

    • Filesystem copy 备份源集群中的文件，并在目标集群中恢复它们。

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

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

13. 选择 目标存储类。

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

14. 点击 Next。

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

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

16. 点击 Next。

17. 可选：点 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 cluster 或 Target cluster。
    6. 输入 Service account name 和 Service account namespace。

    7. 为 hook 选择迁移步骤：

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

18. 点 Finish。

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

流程

1. 登录到 MTC web 控制台并点 迁移计划。

2. 点击迁移计划 旁边的 Options 菜单，并在 Migration 中选择以下选项之一：

   • stage 在不停止应用程序的情况下将数据从源集群复制到目标集群。

   • cutover 会停止源集群上的事务，并将资源移到目标集群。

     可选：在 Cutover 迁移 对话框中，您可以清除 Halt transactions on the source cluster during migration 多选设置。

   • State 会复制所选持久性卷声明(PVC)。

     重要

     不要使用状态迁移来在集群之间迁移命名空间。使用 stage 或 cutover migration。

     • 在状态迁移对话框中选择一个或多个 PVC 并点 Migrate。

3. 迁移完成后，在 OpenShift Container Platform web 控制台中确认已成功迁移了应用程序：

   1. 点 Home → Projects。
   2. 点迁移的项目查看其状态。
   3. 在 Routes 部分，点击 Location 验证应用程序是否正常运行。
   4. 点 Workloads → Pods 来验证 pod 是否在迁移的命名空间中运行。
   5. 点 Storage → Persistent volumes 来验证是否正确置备了已迁移的持久性卷。

流程

1. 为主机集群创建一个 MigCluster CR 清单：

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <host_cluster>
     namespace: openshift-migration
   spec:
     isHostCluster: true
   EOF

2. 为每个远程集群创建一个 Secret 对象清单：

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1
   EOF

   1

   指定远程集群的 base64 编码的 migration-controller 服务帐户（SA）令牌。您可以运行以下命令来获取令牌：

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

3. 为每个远程集群创建一个 MigCluster CR 清单：

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster> 1
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 2
     insecure: false 3
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 4
       namespace: openshift-config
     url: <remote_cluster_url> 5
   EOF

   1

   指定远程集群的 Cluster CR。

   2

   可选： 要直接镜像迁移，请指定公开的 registry 路由。

   3

   如果 false 则启用 SSL 验证。如果为 true，则不需要 CA 证书或不检查 CA 证书。

   4

   指定远程集群的 Secret 对象。

   5

   指定远程集群的 URL。

4. 验证所有集群是否处于 Ready 状态：

   $ oc describe MigCluster <cluster>

5. 为复制存储库创建 Secret 对象清单：

   $ cat << EOF | oc apply -f -
   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
   EOF

   1

   指定 base64 格式的密钥 ID。

   2

   指定 base64 格式的 secret 密钥。

   AWS 凭证默认为 base64 编码。对于其他存储供应商，您必须使用每个密钥运行以下命令来对凭证进行编码：

   $ echo -n "<key>" | base64 -w 0 1

   1

   指定密钥 ID 或 secret 密钥。这两个密钥都必须都是 base64 编码。

6. 为复制存储库创建一个 MigStorage CR 清单：

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigStorage
   metadata:
     name: <migstorage>
     namespace: openshift-migration
   spec:
     backupStorageConfig:
       awsBucketName: <bucket> 1
       credsSecretRef:
         name: <storage_secret> 2
         namespace: openshift-config
     backupStorageProvider: <storage_provider> 3
     volumeSnapshotConfig:
       credsSecretRef:
         name: <storage_secret> 4
         namespace: openshift-config
     volumeSnapshotProvider: <storage_provider> 5
   EOF

   1

   指定存储桶名称。

   2

   指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。

   3

   指定存储供应商。

   4

   可选： 如果要使用快照复制数据，请指定对象存储的 Secrets CR。您必须确保存储在对象存储的 Secrets CR 中的凭证是正确的。

   5

   可选： 如果您使用快照复制数据，请指定存储供应商。

7. 验证 MigStorage CR 是否处于 Ready 状态：

   $ oc describe migstorage <migstorage>

8. 创建一个 MigPlan CR 清单：

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigPlan
   metadata:
     name: <migplan>
     namespace: openshift-migration
   spec:
     destMigClusterRef:
       name: <host_cluster>
       namespace: openshift-migration
     indirectImageMigration: true 1
     indirectVolumeMigration: true 2
     migStorageRef:
       name: <migstorage> 3
       namespace: openshift-migration
     namespaces:
       - <source_namespace_1> 4
       - <source_namespace_2>
       - <source_namespace_3>:<destination_namespace> 5
     srcMigClusterRef:
       name: <remote_cluster> 6
       namespace: openshift-migration
   EOF

   1

   如果为 false，则启用直接镜像迁移。

   2

   如果为 false，则启用直接卷迁移。

   3

   指定 MigStorage CR 实例的名称。

   4

   指定一个或多个源命名空间。默认情况下，目标命名空间具有相同的名称。

   5

   如果目标命名空间与源命名空间不同，请指定目标命名空间。

   6

   指定源集群 MigCluster 实例的名称。

9. 验证 MigPlan 实例是否处于 Ready 状态：

   $ oc describe migplan <migplan> -n openshift-migration

10. 创建一个 MigMigration CR 清单，以启动 MigPlan 实例中定义的迁移：

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    EOF

    1

    指定 MigPlan CR 名称。

    2

    如果为 true，则源集群上的 pod 会在迁移前停止。

    3

    如果为 true，则进行阶段（stage）迁移，即在不停止应用程序的情况下复制大多数数据。

    4

    如果为 true，则会回滚到一个已完成的迁移。

11. 通过观察 MigMigration CR 进度来验证迁移：

    $ oc watch migmigration <migmigration> -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:       migplan
        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. 将持久性卷数据从源迁移到目标集群。

   您可以根据需要多次执行此步骤。源应用程序继续运行。

2. 静止源应用程序。

   您可以通过在源集群上直接将工作负载资源副本设置为 0 来完成此操作，或者更新 GitHub 中的清单并重新同步 Argo CD 应用程序。

3. 将应用程序清单克隆到目标集群。

   您可以使用 Argo CD 将应用程序清单克隆到目标集群。

4. 将剩余的卷数据从源迁移到目标集群。

   通过执行最终数据迁移，在状态迁移过程中迁移应用程序创建的任何新数据。

5. 如果克隆的应用程序处于静默状态，请取消静止它。
6. 将 DNS 记录切换到目标集群，将用户流量重新定向到已迁移的应用程序。

流程

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

   $ oc edit migrationcontroller <migration_controller> -n openshift-migration

2. 通过添加参数以排除特定资源，更新 spec 部分。对于没有自己的排除参数的资源，请添加 additional_excluded_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
     additional_excluded_resources: 3
     - resource1
     - resource2
     ...

   1

   添加 disable_image_migration: true 以排除迁移中的镜像流。当 MigrationController pod 重启时，镜像流 会添加到 main.yml 中的 exclude_resources 列表中。

   2

   添加 disable_pv_migration: true 以将 PV 排除在迁移计划之外。当 MigrationController pod 重启时，persistentvolumes 和 persistentvolumeclaims 会添加到 main.yml 中的 exclude_resources 列表中。禁用 PV 迁移会同时在创建迁移计划时禁用 PV 发现功能。

   3

   您可以添加要在 additional_excluded_resources 列表中排除的 OpenShift Container Platform 资源。

3. 等待两分钟，使 MigrationController Pod 重启，以便应用更改。

4. 验证资源是否排除：

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

   输出包含排除的资源：

   输出示例

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

流程

1. 在 OpenShift Container Platform Web 控制台的左侧导航窗格中，点 Projects。

2. 在项目列表中点击您的项目。

   此时会打开 Project 详情页面。

3. 点 DeploymentConfig 名称。记录其正在运行的 Pod 的名称。
4. 打开项目的 YAML 选项卡。查找 PV 并记下其对应的持久性卷声明(PVC)的名称。
5. 在 MTC web 控制台中点 Migration Plan。
6. 点 Add migration plan。

7. 输入 Plan 名称。

   迁移计划名称必须包含 3 到 63 个小写字母数字字符(a-z，0-9)且不得包含空格或下划线(_)。

8. 在 Migration type 菜单中，选择 Storage class conversion。
9. 从 Source 集群列表中，选择所需的集群进行存储类转换。

10. 点击 Next。

    Namespaces 页面将打开。

11. 选择所需的项目。

12. 点击 Next。

    此时会打开 Persistent volumes 页面。页面中显示项目中 PV，默认选中的所有 PV。

13. 对于每个 PV，选择所需的目标存储类。

14. 点击 Next。

    该向导会验证新的迁移计划，并显示它已就绪。

15. 单击 Close。

    新计划会出现在 Migration Plan 页面中。

16. 要开始转换，请点击新计划的选项菜单。

    在 Migrations 下会显示两个选项，即 Stage 和 Cutover。

    注意

    在应用程序中剪切迁移更新 PVC 引用。

    阶段迁移不会更新应用程序中的 PVC 引用。

17. 选择所需选项。

    根据您选择的选项，显示 Stage migration 或 Cutover migration 通知。

18. 点 Migrate。

    根据您选择的选项，Stage started 或 Cutover started 消息会显示。

19. 要查看当前迁移的状态，请点击 Migrations 列中的数量。

    此时会打开 Migrations 页面。

20. 要查看有关当前迁移和监控其进度的更多详细信息，请从 Type 列选择迁移。

    此时会打开 Migration 详情页面。当迁移进入 DirectVolume 步骤时，步骤的状态将变为 Running Rsync Pods to migrate Persistent Volume data，您可以点 View details 并查看副本的详细状态。

21. 在面包屑导航栏中，点 Stage 或 Cutover，并等待所有步骤完成。

22. 打开 OpenShift Container Platform Web 控制台的 PersistentVolumeClaims 选项卡。

    您可以看到新 PVC 名称，但以 new 结尾（使用目标存储类）。

23. 在左侧导航窗格中，点 Pods。查看您的项目的 pod 已再次运行。

流程

1. 更新 MigPlan CR，使其包含 Kubernetes 资源，并可选择性地通过添加 labelSelector 参数来过滤包含的资源：

   1. 更新 MigPlan CR 使其包含 Kubernetes 资源：

      apiVersion: migration.openshift.io/v1alpha1
      kind: MigPlan
      metadata:
        name: <migplan>
        namespace: openshift-migration
      spec:
        includedResources:
        - kind: <kind> 1
          group: ""
        - kind: <kind>
          group: ""

      1

      指定 Kubernetes 对象，如 Secret 或 ConfigMap。

   2. 可选：要通过添加 labelSelector 参数来过滤包含的资源：

      apiVersion: migration.openshift.io/v1alpha1
      kind: MigPlan
      metadata:
        name: <migplan>
        namespace: openshift-migration
      spec:
        includedResources:
        - kind: <kind> 1
          group: ""
        - kind: <kind>
          group: ""
      ...
        labelSelector:
          matchLabels:
            <label> 2

      1

      指定 Kubernetes 对象，如 Secret 或 ConfigMap。

      2

      指定要迁移的资源标签，如 app: frontend。

2. 创建一个 MigMigration CR 来迁移所选 Kubernetes 资源。验证 migPlanRef 引用了了正确的 MigPlan ：

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigMigration
   metadata:
     generateName: <migplan>
     namespace: openshift-migration
   spec:
     migPlanRef:
       name: <migplan>
       namespace: openshift-migration
     stage: false

流程

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. 登录主机集群。

2. 通过修补 MigrationController CR 来启用 PV 调整大小：

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"enable_dvm_pv_resizing":true}}' \ 1
     --type='merge' -n openshift-migration

   1

   将值设为 false 可禁用 PV 大小调整。

3. 可选：更新 pv_resizing_threshold 参数以增加阈值：

   $ oc patch migrationcontroller migration-controller -p '{"spec":{"pv_resizing_threshold":41}}' \ 1
     --type='merge' -n openshift-migration

   1

   默认值为 3。

   超过阈值时，MigPlan CR 状态中会显示以下状态信息：

   status:
     conditions:
   ...
     - category: Warn
       durable: true
       lastTransitionTime: "2021-06-17T08:57:01Z"
       message: 'Capacity of the following volumes will be automatically adjusted to avoid disk capacity issues in the target cluster:  [pvc-b800eb7b-cf3b-11eb-a3f7-0eae3e0555f3]'
       reason: Done
       status: "False"
       type: PvCapacityAdjustmentRequired

   注意

   对于 AWS gp2 存储，因为 gp2 计算卷用量和大小的方式，这个信息不会出现，除非 pv_resizing_threshold 为 42% 或更高。（BZ#1973148）

流程

1. 运行以下命令启用缓存的客户端：

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_enable_cache", "value": true}]'

2. 可选：运行以下命令来增加 MigrationController CR 内存限值：

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_limits_memory", "value": <10Gi>}]'

3. 可选：运行以下命令来增加 MigrationController CR 内存请求：

   $ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \
     '[{ "op": "replace", "path": "/spec/mig_controller_requests_memory", "value": <350Mi>}]'

流程

1. 在 MTC web 控制台中点 Migration Plans。
2. 点迁移计划旁边的 Migrations 编号来查看 Migrations 页面。
3. 点击迁移以查看迁移详情。

4. 扩展 迁移资源，以在树视图中查看迁移资源及其状态。

   注意

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

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

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

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

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

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

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

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

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

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

流程

1. 在 MTC web 控制台中点 Migration Plans。
2. 点迁移计划旁边的 Migrations 号。
3. 单击 View logs。
4. 点击 Copy 图标将 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 选项显示没有颜色的日志。

流程

1. 在 OpenShift Container Platform web 控制台中点 Observe → Metrics。

2. 输入 PromQL 查询，选择一个要显示的时间窗口，然后单击 Run Queries。

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

流程

1. 进入存储 must-gather 数据的目录。

2. 为以下数据收集选项之一运行 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 文件。您可以将此文件上传到红帽客户门户网站中的支持问题单中。

   • 要收集过去 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 文件。

流程

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 会记录日志错误消息， the server could not find the requested resource，代表迁移部分失败的原因。

流程

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

   输出结果类似以下示例。

流程

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. 再次运行迁移计划。