バージョン 3 から 4 への移行

手順

1. クライアントとターゲットクラスターの間に、アプリケーションロードバランサーやリバースプロキシーなどの外部ネットワークコンポーネントを配置します。
2. DNS サーバーのソースクラスターのアプリケーション FQDN を更新して、外部ネットワークコンポーネントの IP アドレスを返します。
3. ソースドメインのアプリケーション用に受信された要求をターゲットクラスタードメインのロードバランサーに送信するようにネットワークコンポーネントを設定します。
4. ソースクラスターのロードバランサーの IP アドレスを参照する *.apps.source.example.com ドメインのワイルドカード DNS レコードを作成します。
5. ターゲットクラスターの前に、外部ネットワークコンポーネントの IP アドレスを参照する各アプリケーションに DNS レコードを作成します。特定の DNS レコードの優先順位はワイルドカードレコードよりも高くなるため、アプリケーションの FQDN の解決時に競合は発生しません。

1. ソースクラスター内のアプリケーションの FQDN にアドレス指定された要求を受け入れるように設定されたターゲットクラスターのプロジェクトにルートを作成します。

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

   この新規ルートが有効な場合には、サーバーはその FQDN の要求を受け入れて、対応するアプリケーション Pod に送信します。さらに、アプリケーションを移行すると、ターゲットクラスタードメインに別のルートが作成されます。要求は、これらのホスト名のいずれかを使用して、移行されたアプリケーションに到達します。

2. ソースクラスター内のアプリケーションの FQDN がターゲットクラスターのデフォルトのロードバランサーの IP アドレスを指す DNS プロバイダーを使用して DNS レコードを作成します。これにより、トラフィックがソースクラスターからターゲットクラスターにリダイレクトされます。

   アプリケーションの FQDN は、ターゲットクラスターのロードバランサーに対して解決します。デフォルトの Ingress コントローラールーターは、そのホスト名のルートが公開されるため、対象となる FQDN の要求を受け入れます。

1. インストールプロセス中に作成されたデフォルトの Ingress コントローラーの x509 証明書をカスタム証明書に置き換えます。

2. この証明書に、subjectAltName フィールドにソースおよびターゲットクラスター両方のワイルドカード DNS ドメインが含まれるように設定します。

   新しい証明書は、いずれかの DNS ドメインを使用して確立された接続を保護するために有効です。

手順

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 フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

   httpProxy または httpsProxy フィールドのいずれも設定されていない場合、このフィールドは無視されます。

3. マニフェストを migration-controller.yaml として保存します。

4. 更新したマニフェストを適用します。

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

手順

1. NooBaa カスタムリソースで describe コマンドを実行して、S3 エンドポイントである AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY を取得します。

   これらの認証情報を使用して、MCG をレプリケーションリポジトリーとして追加します。

手順

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. email の値と一致するように SERVICE_ACCOUNT_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
   )

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` \
     AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
     --role "Contributor" --query 'password' -o tsv` \
     AZURE_CLIENT_ID=`az ad sp list --display-name "velero" \
     --query '[0].appId' -o tsv`

9. サービスプリンシパルの認証情報を 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 フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

   httpProxy または httpsProxy フィールドのいずれも設定されていない場合、このフィールドは無視されます。

3. マニフェストを migration-controller.yaml として保存します。

4. 更新したマニフェストを適用します。

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

手順

1. NooBaa カスタムリソースで describe コマンドを実行して、S3 エンドポイントである AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY を取得します。

手順

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 コンソールに移動します。

   注記

   Migration Toolkit for Containers Operator のインストール後すぐに MTC の Web コンソールにアクセスしようとする場合、Operator は依然としてクラスターを設定しているため、コンソールが読み込まれない可能性があります。数分待機した後に再試行します。

4. 自己署名 CA 証明書を使用している場合、ソースクラスター API サーバーの CA 証明書を受け入れることを求めるプロンプトが出されます。Web ページは、残りの証明書を受け入れるプロセスについて説明します。
5. OpenShift Container Platform の ユーザー名 および パスワード を使用してログインします。

手順

1. クラスターにログインする。

2. migration-controller サービスアカウントトークンを取得します。

   $ oc sa get-token migration-controller -n openshift-migration

   出力例

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

3. MTC の Web コンソールで、Clusters をクリックします。
4. Add cluster をクリックします。

5. 以下のフィールドに値を入力します。

   • Cluster name: クラスター名には、小文字 (a-z) および数字 (0-9) を含めることができます。スペースや国際的な文字を含めることはできません。
   • URL: API サーバー URL を指定します (例: https://<www.example.com>:8443)。
   • Service account token: migration-controller サービスアカウントトークンを貼り付けます。

   • Exposed route host to image 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 クラスター: Azure スナップショットを使用してデータをコピーする場合は、このオプションを選択する必要があります。
   • Azure resource group: このフィールドは、Azure cluster が選択されている場合に表示されます。Azure リソースグループを指定します。
   • Require SSL verification: オプション: このオプションを選択してクラスターへの SSL 接続を検証します。
   • CA bundle file: このフィールドは、Require SSL verification が選択されている場合に表示されます。自己署名証明書用にカスタム CA 証明書バンドルファイルを作成している場合は、Browse をクリックして CA バンドルファイルを選択し、これをアップロードします。

6. Add cluster をクリックします。

   クラスターが Clusters 一覧に表示されます。

手順

1. MTC の Web コンソールで、Replication repositories をクリックします。
2. Add repository をクリックします。

3. Storage provider type を選択し、以下のフィールドに入力します。

   • AWS および MCG を含む S3 プロバイダー向けの AWS

     • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
     • S3 bucket name: S3 バケットの名前を指定します。
     • S3 bucket region: S3 バケットリージョンを指定します。AWS S3 の場合に必須です。一部の S3 プロバイダーの場合は、オプション になります。予測値については、S3 プロバイダーの製品ドキュメントを確認してください。
     • S3 endpoint: バケットではなく 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 プロバイダーシークレットアクセスキーを指定します。
     • 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 plans をクリックします。
2. Add migration plan をクリックします。

3. Plan name を入力します。

   移行計画名には、253 以上の小文字の英数字 (a-z, 0-9) を使用できず、スペースやアンダースコア (_) を含めることはできません。

4. Source cluster、Target cluster、および Repository を選択します。
5. Next をクリックします。
6. 移行用のプロジェクトを選択します。
7. オプション: プロジェクトの横にある編集アイコンをクリックして、ターゲットの namespace を変更します。
8. Next をクリックします。

9. 各 PV の 移行タイプ を選択します。

   • Copy オプションは、ソースクラスターの PV のデータをレプリケーションリポジトリーにコピーしてから、データを同様の特徴のある新規に作成された PV でターゲットクラスターで復元します。
   • Move オプションは、ソースクラスターからリモートボリューム (例: NFS) をアンマウントし、リモートボリュームをポイントするターゲットクラスターで PV リソースを作成し、その後にリモートボリュームをターゲットクラスターにマウントします。ターゲットクラスターで実行されているアプリケーションは、ソースクラスターが使用していたものと同じリモートボリュームを使用します。
10. Next をクリックします。

11. 各 PV の Copy method を選択します。

    • スナップショットのコピー は、クラウドプロバイダーのスナップショット機能を使用してデータのバックアップおよび復元を行います。この場合、ファイルシステムのコピー を使用する場合よりもはるかに高速になります。

    • ファイルシステムのコピー は、ソースクラスターのファイルをバックアップし、それらをターゲットクラスターで復元します。

      ファイルシステムのコピー方法は、ボリュームの直接移行に必要です。

12. Verify copy を選択して、ファイルシステムのコピー で移行されたデータを確認します。データは、各ソースファイルのチェックサムを生成し、復元後のチェックサムを確認して検証されます。データ検証は、パフォーマンスを大幅に低下させます。

13. Target storage class を選択します。

    Filesystem copy を選択している場合、ターゲットストレージクラスを変更できます。

14. Next をクリックします。

15. Migration options ページで、ソースクラスターに公開されたイメージレジストリールートを指定した場合に Direct image migration オプションが選択されます。Filesystem copy でデータを移行する場合、Direct PV migration オプションが選択されます。

    直接の移行オプションは、イメージおよびファイルをソースクラスターからターゲットクラスターに直接コピーします。このオプションは、イメージおよびファイルをソースクラスターからレプリケーションリポジトリーにコピーしてから、レプリケーションリポジトリーからターゲットクラスターにコピーする場合よりもはるかに高速になります。

16. Next をクリックします。

17. オプション: Add Hook をクリックし、移行計画にフックを追加します。

    フックはカスタムコードを実行します。単一の移行計画計画に最大 4 つのフックを追加できます。各フックは異なる移行ステップで実行されます。

    1. Web コンソールに表示するフックの名前を入力します。
    2. フックが Ansible Playbook の場合はAnsible playbook を選択し、Browse をクリックして Playbook をアップロードするか、フィールドに Playbook の内容を貼り付けます。
    3. オプション: デフォルトのフックイメージを使用していない場合は、Ansible ランタイムイメージを指定します。

    4. フックが Ansible Playbook ではない場合には、Custom container image をクリックし、イメージ名とパスを指定します。

       カスタムコンテナーイメージには、Ansible Playbook を含めることができます。

    5. Source cluster または Target cluster を選択します。
    6. Service account name および Service account namespace を入力します。

    7. フックの移行手順を選択します。

       • preBackup: アプリケーションのワークロードがソースクラスターでバックアップされる前
       • postBackup: アプリケーションのワークロードがソースクラスターでバックアップされた後
       • preRestore: アプリケーションのワークロードがターゲットクラスターで復元される前
       • postRestore: アプリケーションのワークロードがターゲットクラスターで復元された後
    8. Add をクリックします。

18. Finish をクリックします。

    移行計画は、Migration plans 一覧に表示されます。

手順

1. MTC の Web コンソールにログインし、Migration plans をクリックします。

2. 移行計画の横にある Options メニュー をクリックし、Migration で以下のいずれかのオプションを選択します。

   • ステージ は、アプリケーションを停止せずにデータをソースクラスターからターゲットクラスターにコピーします。

   • Cutover はソースクラスターのトランザクションを停止し、リソースをターゲットクラスターに移動します。

     オプション: Cutover migration ダイアログで、移行時にソースクラスターで Halt トランザクションを消去できます。

   • State は、選択した永続ボリューム要求 (PVC) をコピーします。

     重要

     状態の移行を使用して、クラスター間で namespace を移行しないでください。代わりにステージまたはカットオーバー移行を使用してください。

     • State migration ダイアログで 1 つ以上の PVC を選択し、Migrate をクリックします。

3. 移行が完了したら、アプリケーションが OpenShift Container Platform Web コンソールで正常に移行されていることを確認します。

   1. Home → Projects をクリックします。
   2. 移行されたプロジェクトをクリックしてそのステータスを表示します。
   3. Routes セクションで Location をクリックし、アプリケーションが機能していることを確認します (該当する場合)。
   4. Workloads → Pods をクリックし、Pod が移行した namespace で実行されていることを確認します。
   5. Storage → Persistent volumes をクリックして、移行した永続ボリュームが正常にプロビジョニングされていることを確認します。

手順

1. host クラスターの 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

   オプション: イメージの直接移行には、公開されるレジストリールートを指定します。

   3

   SSL 検証は、false の場合に有効になります。CA 証明書は、true の場合は必要ではなく、チェックされません。

   4

   リモートクラスターの Secret オブジェクトを指定します。

   5

   リモートクラスターの URL を指定します。

4. すべてのクラスターが Ready 状態にあることを確認します。

   $ oc describe cluster <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

   キー ID を base64 形式で指定します。

   2

   シークレットキーを base64 形式で指定します。

   AWS 認証情報はデフォルトで base64 でエンコードされます。それぞれのキーを使用して以下のコマンドを実行して、認証情報をエンコードする必要があります。

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

   1

   キー ID またはシークレットキーを指定します。どちらの値も 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

   namespace を 1 つ以上指定します。デフォルトで、宛先 namespace の名前は同じです。

   5

   宛先 namespace が異なる場合には、宛先 namespace を指定します。

   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 の場合、アプリケーションを停止せずにほとんどのデータをコピーする段階移行が実行されます。

    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. ソースアプリケーションを休止します。

   これは、ワークロードリソースのレプリカを、ソースクラスターに直接設定するか、GitHub でマニフェストを更新して Argo CD アプリケーションを再同期することで、0 に設定できます。

3. アプリケーションマニフェストのクローンをターゲットクラスターに作成します。

   Argo CD を使用して、アプリケーションマニフェストのクローンをターゲットクラスターに作成できます。

4. 残りのボリュームデータをソースからターゲットクラスターに移行します。

   最終的なデータ移行を実行して、状態移行プロセス中にアプリケーションによって作成された新しいデータを移行します。

5. クローンを作成したアプリケーションが休止状態の場合は、停止を解除します。
6. DNS レコードをターゲットクラスターに切り替えて、ユーザートラフィックを移行されたアプリケーションにリダイレクトします。

手順

1. 永続ボリュームデータをソースからターゲットクラスターに移行します。

   この手順は、必要に応じて何度でも実行することができます。ソースアプリケーションは実行を継続します。

2. ソースアプリケーションを休止します。

   これは、ワークロードリソースのレプリカを、ソースクラスターに直接設定するか、GitHub でマニフェストを更新して Argo CD アプリケーションを再同期することで、0 に設定できます。

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 が再起動すると、imagestreams が main.yml の excluded_resources リストに追加されます。

   2

   disable_pv_migration: true を追加して、移行計画から PV を除外します。MigrationController Pod が再起動すると、persistentvolumes と persistentvolumeclaims が main.yml の excluded_resources リストに追加されます。PV 移行を無効にすると、移行計画の作成時に PV 検出も無効にできます。

   3

   除外する OpenShift Container Platform リソースを additional_excluded_resources リストに追加できます。

3. MigrationController Pod が再起動し、変更が適用されるまで 2 分待機します。

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. 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 リソースを移行します。正しい MigPlan が migPlanRef で参照されていることを確認します。

   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

   移行可能な namespace の数を指定します。

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

   PV のサイズ変更を無効にするには、値を false に設定します。

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. Migration resources を展開して、移行リソースおよびそれらのステータスをツリービューで表示します。

   注記

   移行の失敗をトラブルシューティングするには、失敗した高レベルのリソースで開始し、リソースツリーでより低い位置にあるリソースまで堀り下げます。

5. リソースの横にある Options メニュー をクリックし、以下のオプションのいずれかを選択します。

   • copy oc describe コマンド は、コマンドをクリップボードにコピーします。

     • 関連するクラスターにログインしてから、コマンドを実行します。

       リソースの条件およびイベントは YAML 形式で表示されます。

   • Copy oc logs コマンド は、コマンドをクリップボードにコピーします。

     • 関連するクラスターにログインしてから、コマンドを実行します。

       リソースがログフィルターに対応していると、フィルターされたログが表示されます。

   • JSON ビューは、Web ブラウザーで JSON 形式でリソースデータを表示します。

     データは oc get <resource> コマンドの出力と同じです。

手順

1. MTC Web コンソールで、Migration plans をクリックします。
2. 移行計画の横にある Migrations 番号をクリックします。
3. View logs をクリックします。
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 オプションは、色なしでログを表示します。

手順

1. OpenShift Container Platform Web コンソールで、Observe → Metrics をクリックします。

2. PromQL クエリーを入力し、表示する期間を選択し、Run Queries をクリックします。

   Web ブラウザーにすべての結果が表示されない場合は、Prometheus コンソールを使用します。

手順

1. must-gather データを保存するディレクトリーに移動します。

2. 次のデータ収集オプションのいずれかに対して、oc adm must-gather コマンドを実行します。

   • 過去 1 時間のデータを収集するには、以下を実行します。

     $ 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 として保存されます。

手順

1. prom_data.tar.gz ファイルを解凍します。

   $ tar -xvzf must-gather/metrics/prom_data.tar.gz

2. ローカルの Prometheus インスタンスを作成します。

   $ make prometheus-run

   このコマンドでは、Prometheus URL が出力されます。

   出力

   Started Prometheus on http://localhost:9090

3. Web ブラウザーを起動して URL に移動し、Prometheus Web コンソールを使用してデータを表示します。

4. データを確認した後に、Prometheus インスタンスおよびデータを削除します。

   $ make prometheus-cleanup

手順

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 namespace の 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. 内部レジストリーが OpenShift Container Platform 3 および 4 クラスターで公開されていることを確認します。

   内部レジストリーは、デフォルトでは 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 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 およびポートを指定します。

7. イメージを OpenShift Container Platform 4 レジストリーにプッシュします。

   $ podman push <registry_url>:<port>/openshift/<image> 1

   1

   OpenShift Container Platform 4 クラスターを指定します。

8. イメージに有効なイメージストリームがあることを確認します。

   $ 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

手順

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. ソースクラスターで、移行した namespace の詳細を取得します。

   $ oc get namespace <namespace> -o yaml 1

   1

   移行した namespace を指定します。

3. ターゲットクラスターで、移行した namespace を編集します。

   $ oc edit namespace <namespace>

4. 以下の例のように、欠落している openshift.io/node-selector アノテーションを移行した namespace に追加します。

   apiVersion: v1
   kind: Namespace
   metadata:
     annotations:
       openshift.io/node-selector: "region=east"
   ...

5. 移行計画を再度実行します。

手順

1. MTC Web コンソールで、Migration plans をクリックします。
2. 移行計画の横にある Options メニュー をクリックし、Migration の下にある Rollback を選択します。

3. Rollback をクリックし、ロールバックが完了するまで待機します。

   移行計画の詳細に、Rollback succeeded が表示されます。

4. ソースクラスターの OpenShift Container Platform Web コンソールでロールバックが正常に行われたことを確認します。

   1. Home → Projects をクリックします。
   2. 移行されたプロジェクトをクリックしてそのステータスを表示します。
   3. Routes セクションで Location をクリックし、アプリケーションが機能していることを確認します (該当する場合)。
   4. Workloads → Pods をクリックし、Pod が移行した namespace で実行されていることを確認します。
   5. Storage → Persistent volumes をクリックして、移行した永続ボリュームが正常にプロビジョニングされていることを確認します。

手順

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. 移行したプロジェクトリソースがソースクラスターにあり、アプリケーションが実行中であることを確認します。

手順

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>