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

MTC (Migration Toolkit for Containers) カスタムリソース (CR) を表示し、ログをダウンロードして失敗した移行のトラブルシューティングを行うことができます。

移行の失敗時にアプリケーションが停止した場合は、データ破損を防ぐためにアプリケーションをロールバックする必要があります。

注記

移行時にアプリケーションが停止しなかった場合には、手動のロールバックは必要ありません。元のアプリケーションがソースクラスター上で依然として実行されているためです。

2.5.1. 移行カスタムリソースの表示

MTC (Migration Toolkit for Containers) は以下のカスタムリソース (CR) を作成します。

移行アーキテクチャーの図

20 MigCluster (設定、MTC クラスター): クラスター定義

20 MigStorage (設定、MTC クラスター): ストレージ定義

20 MigPlan (設定、MTC クラスター): 移行計画

MigPlan CR は、移行されるソースおよびターゲットクラスター、レプリケーションリポジトリー、および namespace を記述します。これは 0、1 または多数の MigMigration CR に関連付けられます。

注記

MigPlan CR を削除すると、関連付けられた MigMigration CR が削除されます。

20 BackupStorageLocation (設定、MTC クラスター): Velero バックアップオブジェクトの場所

20 VolumeSnapshotLocation (設定、MTC クラスター): Velero ボリュームスナップショットの場所

20 MigMigration (アクション、MTC クラスター): データのステージングまたは移行時に毎回作成される移行。各 MigMigration CR は MigPlan CR に関連付けられます。

20 Backup (アクション、ソースクラスター): 移行計画の実行時に、MigMigration CR は各ソースクラスターに 2 つの Velero バックアップ CR を作成します。

  • Kubernetes オブジェクトのバックアップ CR #1
  • PV データのバックアップ CR #2

20 Restore (アクション、ターゲットクラスター): 移行計画の実行時に、MigMigration CR はターゲットクラスターに 2 つの Velero 復元 CR を作成します。

  • PV データの復元 CR #1 (バックアップ CR #2 の使用)
  • Kubernetes オブジェクトの復元 CR #2 (バックアップ CR #1 の使用)

手順

  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

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

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

2.5.2. 移行ログリーダーの使用

移行ログリーダーを使用して、すべての移行ログの単一のフィルタービューを表示できます。

手順

  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 オプションは、色なしでログを表示します。

2.5.3. 移行ログのダウンロード

MTC (Migration Toolkit for Containers) の Web コンソールで VeleroRestic、および MigrationController Pod ログをダウンロードして、移行の失敗についてトラブルシューティングを行うことができます。

手順

  1. MTC コンソールで、Migration plans をクリックし、移行計画を表示します。
  2. 特定の移行計画の Options メニュー kebab をクリックし、Logs を選択します。
  3. Download Logs をクリックし、すべてのクラスターの MigrationControllerVelero、および Restic Pod のログをダウンロードします。

    単一ログは、クラスター、ログソース、および Pod ソースを選択してから Download Selected をクリックしてダウンロードできます。

    oc logs コマンドを使用して、CLI から Pod ログにアクセスできます。

    $ oc logs <pod-name> -f -n openshift-migration 1
    1
    Pod 名を指定します。

2.5.4. 非推奨の API の更新

ソースクラスターが非推奨の API を使用する場合、MTC (Migration Toolkit for Containers) Web コンソールで移行計画を作成する際に以下の警告メッセージが表示されます。

Some namespaces contain GVKs incompatible with destination cluster

See details をクリックして namespace および互換性のない API を表示します。この警告メッセージは移行をブロックしません。

MTC (Migration Toolkit for Containers) を使用した移行時に、非推奨の API は Kubernetes オブジェクトの Velero バックアップ #1 に保存されます。Velero バックアップをダウンロードし、非推奨の API yaml ファイルを展開し、それらを oc convert コマンドで更新できます。次に、ターゲットクラスターで更新された API を作成できます。

手順

  1. 移行計画を実行します。
  2. MigPlan カスタムリソース (CR) を表示します:

    $ oc describe migplan <migplan_name> -n openshift-migration 1
    1
    MigPlan CR の名前を指定します。

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

    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: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    MigPlan CR UID を記録します。
    2
    gvks セクションに一覧表示された非推奨の API を記録します。
  3. MigPlan UID に関連付けられた MigMigration 名を取得します。

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    MigPlan CR 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. 非推奨のそれぞれの API でオフラインモードで oc convert を実行します。

    $ oc convert -f <backup_local_dir>/resources/<gvk>.json
  9. ターゲットクラスターで変換された API を作成します。

    $ oc create -f <gvk>.json

2.5.5. エラーメッセージおよび解決

このセクションでは、MTC (Migration Toolkit for Containers) で発生する可能性のある一般的なエラーメッセージと、それらの根本的な原因を解決する方法について説明します。

2.5.5.1. Restic タイムアウトエラー

MTC コンソールへの初回アクセスを試みる際に CA certificate error が表示される場合、クラスターのいずれかでの自己署名 CA 証明書の使用が原因である可能性があります。

この問題を解決するには、エラーメッセージに表示される oauth-authorization-server URL に移動し、証明書を受け入れます。この問題を永続的に解決するには、Web ブラウザーの信頼ストアに証明書を追加します。

証明書を受け入れた後に Unauthorized メッセージが表示される場合は、MTC コンソールに移動し、Web ページを更新します。

2.5.5.2. MTC コンソールの OAuth タイムアウトエラー

自己署名証明書を受け入れた後に connection has timed out メッセージが MTC コンソールに表示される場合、以下の原因が考えられます。

  • OAuth サーバーへのネットワークアクセスが中断された。
  • OpenShift Container Platform Web コンソールへのネットワークアクセスが中断された。
  • oauth-authorization-server URL へのアクセスをブロックするプロキシー設定。詳細は、「MTC console inaccessible because of OAuth timeout error」を参照してください。

タイムアウトの原因を特定できます。

手順

  1. MTC コンソールに移動し、ブラウザーの Web インスペクターで要素を検査します。
  2. MigrationUI Pod ログを確認します。

    $ oc logs <MigrationUI_Pod> -n openshift-migration

2.5.5.3. Velero Pod ログの PodVolumeBackups タイムアウトエラー

Restic のタイムアウトにより移行が失敗する場合、以下のエラーが Velero Pod ログに表示されます。

出力例

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

restic_timeout のデフォルト値は 1 時間です。大規模な移行では、このパラメーターの値を大きくすることができます。値を高くすると、エラーメッセージが返されるタイミングが遅れる可能性があることに注意してください。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsInstalled Operators に移動します。
  2. Migration Toolkit for Containers Operator をクリックします。
  3. MigrationController タブで、migration-controller をクリックします。
  4. YAML タブで、以下のパラメーター値を更新します。

    spec:
      restic_timeout: 1h 1
    1
    有効な単位は h (時間)、m (分)、および s (秒) です (例: 3h30m15s)。
  5. Save をクリックします。

2.5.5.4. MigMigration カスタムリソースの ResticVerifyErrors

ファイルシステムデータのコピー方法を使用して永続ボリュームを移行する際にデータ検証が失敗すると、以下のエラーが MigMigration CR に表示されます。

出力例

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details 1
    status: "True"
    type: ResticVerifyErrors 2

1
エラーメッセージは Restore CR 名を識別します。
2
ResticVerifyErrors は、検証エラーが含まれる一般的なエラーの警告です。
注記

データ検証エラーによって移行プロセスが失敗することはありません。

Restore CR を確認して、データ検証エラーのソースを特定できます。

手順

  1. ターゲットクラスターにログインします。
  2. Restore CR を表示します。

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    出力では、PodVolumeRestore エラーのある永続ボリュームを特定できます。

    出力例

    status:
      phase: Completed
      podVolumeRestoreErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration
      podVolumeRestoreResticErrors:
      - kind: PodVolumeRestore
        name: <registry-example-migration-rvwcm-98t49>
        namespace: openshift-migration

  3. PodVolumeRestore CR を表示します。

    $ oc describe <migration-example-rvwcm-98t49>

    出力では、エラーをログに記録した Restic Pod を特定できます。

    出力例

      completionTimestamp: 2020-05-01T20:49:12Z
      errors: 1
      resticErrors: 1
      ...
      resticPod: <restic-nr2v5>

  4. Restic Pod ログを表示し、エラーを見つけます。

    $ oc logs -f <restic-nr2v5>

2.5.6. ボリュームの直接移行が完了しない

ボリュームの直接移行が完了しない場合、ターゲットクラスターにソースクラスターと同じ node-selector アノテーションが含まれていない場合があります。

MTC (Migration Toolkit for Containers) は、SCC (Security Context Constraints) およびスケジューリング要件を保持するためにすべてのアノテーションで namespace を移行します。ボリュームの直接移行の際に、MTC はソースクラスターから移行された namespace のターゲットクラスターで Rsync 転送 Pod を作成します。ターゲットクラスター namespace にソースクラスター namespace と同じアノテーションがない場合、Rsync 転送 Pod はスケジュールできません。Rsync Pod は Pending 状態のままになります。

以下の手順に従って、この問題を特定し、修正できます。

手順

  1. MigMigration CR のステータスを確認します。

    $ oc describe migmigration <pod_name> -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. 移行計画を再度実行します。

2.5.7. Velero CLI を使用したバックアップおよび復元 CR のデバッグ

Velero コマンドラインインターフェース (CLI) を使用して Backup および Restore カスタムリソース (CR) と部分的な移行の失敗をデバッグできます。Velero CLI は velero Pod で実行されます。

2.5.7.1. Velero コマンド構文

Velero CLI コマンドは以下の構文を使用します。

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero <resource> <command> <resource_id>

$(oc get pods -n openshift-migration -o name | grep velero)velero-<pod> -n openshift-migration を指定できます。

2.5.7.2. Help コマンド

Velero help コマンドは、すべての Velero CLI コマンドを一覧表示します。

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero --help

2.5.7.3. describe コマンド

Velero describe コマンドは、Velero リソースに関連する警告およびエラーの要約を示します。

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero  <resource> describe <resource_id>

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

2.5.7.4. logs コマンド

Velero logs コマンドは、Velero リソースに関連付けられたログを提供します。

velero <resource> logs <resource_id>

$ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -- ./velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

2.5.7.5. 部分的な移行の失敗のデバッグ

Velero CLI を使用して Restore カスタムリソース (CR) ログを確認し、部分的な移行の失敗についての警告メッセージをデバッグできます。

部分的な障害は、Velero で移行の失敗を生じさせない問題が発生する際に見られます。たとえば、カスタムリソース定義 (CRD) がない場合や、ソースクラスターおよびターゲットクラスターの CRD バージョン間で不一致がある場合、移行は完了しますが、CR はターゲットクラスターで作成されません。

Velero は問題を部分的な障害としてログに記録し、Backup CR の残りのオブジェクトを処理します。

手順

  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 exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./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 exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./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 は、部分的に失敗した移行の原因を示します。

2.5.8. must-gather を使用したデータ収集

Red Hat カスタマーポータル で MTC (Migration Toolkit for Containers) についてカスタマーサポートケースを作成する場合、must-gather ツールを実行する必要があります。

MTC の openshift-migration-must-gather-rhel8 イメージは移行に固有のログを収集し、デフォルトの must-gather イメージで収集されないデータを収集します。

手順

  1. must-gather データを保存するディレクトリーに移動します。
  2. must-gather コマンドを実行します。

    $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.4
  3. 認証キーおよびその他の機密情報を削除します。
  4. must-gather データディレクトリーの内容を含むアーカイブファイルを作成します。

    $ tar cvaf must-gather.tar.gz must-gather.local.<uid>/
  5. 圧縮ファイルをお客様のサポートケースの添付としてアップロードします。

2.5.9. 移行のロールバック

MTC の Web コンソールまたは CLI を使用して移行をロールバックできます。

2.5.9.1. MTC の Web コンソールでの移行のロールバック

MTC (Migration Toolkit for Containers) Web コンソールで移行をロールバックできます。

移行の失敗時にアプリケーションが停止されている場合、永続ボリュームでのデータの破損を防ぐために移行をロールバックする必要があります。

移行時にアプリケーションが停止しなかった場合には、ロールバックは必要ありません。元のアプリケーションがソースクラスター上で依然として実行されているためです。

手順

  1. MTC Web コンソールで、Migration plans をクリックします。
  2. 移行計画の横にある Options メニュー kebab をクリックし、 Rollback を選択します。
  3. Rollback をクリックし、ロールバックが完了するまで待機します。

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

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

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

CLI で MigMigration カスタムリソース (CR) を作成して移行をロールバックできます。

移行の失敗時にアプリケーションが停止されている場合、永続ボリュームでのデータの破損を防ぐために移行をロールバックする必要があります。

移行時にアプリケーションが停止しなかった場合には、ロールバックは必要ありません。元のアプリケーションがソースクラスター上で依然として実行されているためです。

手順

  1. 以下の例に基づいて MigMigration CR オブジェクトを作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: migration-rollback
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
    EOF
    1
    関連付けられた MigPlan CR の名前を指定します。
  2. MTC の Web コンソールで、移行したプロジェクトリソースがターゲットクラスターから削除されていることを確認します。
  3. 移行したプロジェクトリソースがソースクラスターにあり、アプリケーションが実行中であることを確認します。

2.5.10. 既知の問題

本リリースには、以下の既知の問題があります。

  • 移行時に、MTC (Migration Toolkit for Containers) は以下の namespace アノテーションを保持します。

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups
    • openshift.io/sa.scc.uid-range

      これらのアノテーションは UID 範囲を保持し、コンテナーがターゲットクラスターのファイルシステムのパーミッションを保持できるようにします。移行された UID が、ターゲットクラスターの既存の namespace または今後の namespace 内の UID を重複させるリスクがあります。(BZ#1748440)

  • ほとんどのクラスタースコープのリソースは MTC で処理されません。アプリケーションがクラスタースコープのリソースを必要とする場合、ターゲットクラスターでそれらを手動で作成する必要がある場合があります。
  • 移行に失敗すると、移行計画は休止状態の Pod のカスタム PV 設定を保持しません。移行を手動でロールバックし、移行計画を削除し、PV 設定で新たな移行計画を作成する必要があります。(BZ#1784899)
  • Restic のタイムアウトにより大規模な移行が失敗する場合は、MigrationController カスタマーリソース (CR) マニフェストの restic_timeout パラメーターの値 (デフォルト: 1h)を増やすことができます。
  • ファイルシステムのコピー方法で移行される PV のデータ検証オプションを選択すると、パフォーマンスは大幅に遅くなります。
  • NFS ストレージからデータを移行していて、root_squash が有効になっている場合、Resticnfsnobody にマップされます。移行に失敗し、パーミッションエラーが Restic Pod ログに表示されます。(BZ#1873641)

    Restic の補助グループを MigrationController CR マニフェストに追加することで、この問題を解決することができます。

    spec:
    ...
      restic_supplemental_groups:
      - 5555
      - 6666
  • 異なるアベイラビリティーゾーンにあるノードでボリュームの直接移行を実行する場合、移行した Pod は PVC にアクセスできないために移行が失敗する可能性があります。(BZ#1947487)

2.5.11. 追加リソース