1.8. トラブルシューティング

手順

1. CR 名を取得します。

   $ oc get <migration_cr> -n openshift-migration 1

   1

   移行 CR を指定します (例: migmigration)。

   出力は以下の例のようになります。

   NAME                                   AGE
   88435fe0-c9f8-11e9-85e6-5d593ce65e10   6m42s

2. CR を表示します。

   $ oc describe <migration_cr> <88435fe0-c9f8-11e9-85e6-5d593ce65e10> -n openshift-migration

   出力は以下の例のようになります。

手順

1. CAM Web コンソールにログインします。
2. Plans をクリックし、 移行計画の一覧を表示します。
3. 特定の移行計画の Options メニュー をクリックし、Logs を選択します。
4. Download Logs をクリックし、すべてのクラスターの Migration コントローラー、Velero、および Restic のログをダウンロードします。

5. 特定のログをダウンロードするには、以下を実行します。

   1. ログオプションを指定します。

      • Cluster: ソース、ターゲット、または CAM ホストクラスターを選択します。
      • Log source: Velero、Restic、または Controller を選択します。

      • Pod source: Pod 名を選択します (例: controller-manager-78c469849c-v6wcf)。

        選択したログが表示されます。

        選択した内容を変更することで、ログ選択の設定をクリアできます。

   2. Download Selected をクリックし、選択したログをダウンロードします。

手順

1. 移行計画を実行します。

2. MigPlan CR を表示します。

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

   1

   移行計画の名前を指定します。

   出力は以下の例のようになります。

   metadata:
     ...
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
   status:
     ...
     conditions:
     - category: Warn
       lastTransitionTime: 2020-04-30T17:16:23Z
       message: 'Some namespaces contain GVKs incompatible with destination cluster.
         See: `incompatibleNamespaces` for details'
       status: "True"
       type: GVKsIncompatible
     incompatibleNamespaces:
     - gvks:
       - group: batch
         kind: cronjobs 2
         version: v2alpha1
       - group: batch
         kind: scheduledjobs 3
         version: v2alpha1

   1

   MigPlan UID を記録します。

   2 3

   非推奨の GVK を記録します。

3. MigPlan UID に関連付けられた MigMigration 名を取得します。

   $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1

   1

   MigPlan UID を指定します。

4. MigMigration 名に関連付けられた MigMigration UID を取得します。

   $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1

   1

   MigMigration 名を指定します。

5. MigMigration UID に関連付けられた Velero バックアップ名を取得します。

   $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1

   1

   MigMigration UID を指定します。

6. Velero バックアップの内容をローカルマシンにダウンロードします。

   • AWS S3 の場合:

     $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1

     1

     バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。

   • GCP の場合:

     $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1

     1

     バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。

   • Azure の場合:

     $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1

     1

     バックアップ名とローカルバックアップのディレクトリー名を指定します。

7. Velero バックアップアーカイブファイルを展開します。

   $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>

8. 非推奨となったそれぞれの GVK でオフラインモードで oc convert を実行します。

   $ oc convert -f <backup_local_dir>/resources/<gvk>.yaml 1

   1

   非推奨の GVK を指定します。

9. ターゲットクラスターで変換された GVK を作成します。

   $ oc create -f <gvk>.yaml 1

   1

   変換された GVK を指定します。

手順

1. ターゲットクラスター上で、移行したプロジェクトに切り替えます。

   $ oc project <project>

2. デプロイされたリソースを取得します。

   $ oc get all

3. デプロイされたリソースを削除し、アプリケーションがターゲットクラスターで実行されておらず、PVC 上にあるデータにアクセスできるようにします。

   $ oc delete <resource_type>

4. これを削除せずに DaemonSet を停止するには、YAML ファイルで nodeSelector を更新します。

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: hello-daemonset
   spec:
     selector:
         matchLabels:
           name: hello-daemonset
     template:
       metadata:
         labels:
           name: hello-daemonset
       spec:
         nodeSelector:
           role: worker 1

   1

   いずれのノードにも存在しない nodeSelector 値を指定します。

5. 不要なデータが削除されるように、各 PV の回収ポリシーを更新します。移行時に、バインドされた PV の回収ポリシーは Retain であり、アプリケーションがソースクラスターから削除される際にデータの損失が生じないようにされます。ロールバック時にこれらの PV を削除できます。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv0001
   spec:
     capacity:
       storage: 5Gi
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain 1
     ...
   status:
     ...

   1

   Recycle または Delete を指定します。

6. ソースクラスターで、移行したプロジェクトに切り替えます。

   $ oc project <project_name>

7. プロジェクトのデプロイされたリソースを取得します。

   $ oc get all

8. デプロイされた各リソースのレプリカを開始します。

   $ oc scale --replicas=1 <resource_type>/<resource_name>

9. 手順の実行時に変更した場合は、DaemonSet の nodeSelector を元の値に更新します。

手順

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

2. oc adm must-gather コマンドを実行します。

   $ oc adm must-gather --image=registry.redhat.io/rhcam-1-2/openshift-migration-must-gather-rhel8

   must-gather ツールはクラスター情報を収集し、これを must-gather.local.<uid> ディレクトリーに保存します。

3. 認証キーおよびその他の機密情報を must-gather データから削除します。

4. must-gather.local.<uid> ディレクトリーの内容を含むアーカイブファイルを作成します。

   $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/

   圧縮ファイルを Red Hat カスタマーポータル上のサポートケースに添付します。