MTC (Migration Toolkit for Containers)

OpenShift Container Platform 4.8

OpenShift Container Platform 4 への移行

概要

本書では、アプリケーションのワークロードを OpenShift Container Platform 4 から最新バージョンに移行する方法について説明します。

第1章 MTC (Migration Toolkit for Containers)

MTC (Migration Toolkit for Containers) を使用すると、OpenShift Container Platform 4 クラスター間でステートフルなアプリケーションのワークロードを namespace のレベルで移行できます。

状態の移行を使用して、同じクラスター内でアプリケーションを移行できます。

MTC には、Web コンソールおよび API が同梱されており、Kubernetes カスタムリソースに基づいて移行を制御してアプリケーションのダウンタイムを最小限に抑えることができます。

MTC コンソールはデフォルトでターゲットクラスターにインストールされます。Migration Toolkit for Containers Operator を、コンソールをリモートクラスターにインストールするように設定できます。

以下のトピックの詳細は、「高度な移行オプション」を参照してください。

  • 移行フックおよび MTC API で移行を自動化する。
  • リソースを除外して大規模な移行をサポートし、ボリュームを直接移行する場合の自動 PV サイズ調整を有効化にするように移行計画を設定する。

1.1. 用語

表1.1 MTC の用語

用語定義

ソースクラスター

アプリケーションの移行元となるクラスター。

宛先クラスター[1]

アプリケーションが移行されるクラスター。

レプリケーションリポジトリー

ボリュームとイメージの直接的な移行時の Kubernetes オブジェクトに使用するオブジェクトストレージ、または間接的な移行時にイメージ、ボリューム、Kubernetes オブジェクトのコピーに使用するオブジェクトストレージ。

レプリケーションリポジトリーはすべてのクラスターからアクセスできる必要があります。

ホストクラスター

migration-controller Pod および Web コンソールが実行されているクラスター。ホストクラスターは通常宛先クラスターですが、これは必須ではありません。

ホストクラスターには、イメージの直接移行にレジストリールートを公開する必要はありません。

リモートクラスター

通常、リモートクラスターはソースクラスターですが、これは必須ではありません。

リモートクラスターには、migration-controller サービスアカウントトークンが含まれる Secret カスタムリソースが必要です。

リモートクラスターには、直接のイメージ移行用にセキュアなレジストリールートを公開する必要があります。

間接的な移行

イメージ、ボリューム、および Kubernetes オブジェクトはソースクラスターからレプリケーションリポジトリーにコピーされ、その後にレプリケーションリポジトリーから宛先クラスターにコピーされます。

ボリュームの直接移行

永続ボリュームはソースクラスターから宛先クラスターに直接コピーされます。

イメージの直接移行

イメージはソースクラスターから宛先クラスターに直接コピーされます。

段階移行

データはアプリケーションを停止せずに、宛先クラスターにコピーされます。

段階移行を複数回実行すると、カットオーバー移行の時間が短縮されます。

カットオーバー移行

ソースクラスター上のアプリケーションが停止され、アプリケーションリソースが宛先クラスターに移行されます。

状態の移行

アプリケーションの状態は、特定の永続ボリューム要求(PVC)および Kubernetes オブジェクトを宛先クラスターにコピーして移行されます。

ロールバック移行

ロールバック移行は完了した移行をロールバックします。

1 MTC の Web コンソールの ターゲットクラスターを指します。

1.2. MTC ワークフロー

MTC (Migration Toolkit for Containers) の Web コンソールまたは Kubernetes API を使用して、Kubernetes リソース、永続ボリュームデータ、および内部コンテナーイメージを OpenShift Container Platform 4.8 に移行できます。

MTC は以下のリソースを移行します。

  • 移行計画に指定される namespace。
  • namespace スコープのリソース: MTC が namespace を移行する場合、サービスや Pod などのその namespace に関連付けられるすべてのオブジェクトおよびリソースを移行します。さらに、namespace に存在するものの、クラスターレベルに存在しないリソースがクラスターレベルに存在するリソースに依存する場合、MTC は両方のリソースを移行します。

    たとえば、SCC (Security Context Constraints) はクラスターレベルに存在するリソースであり、サービスアカウント (SA) は namespace レベルに存在するリソースです。SA が MTC が移行する namespace に存在する場合、MTC は SA にリンクされている SCC を自動的に識別し、それらの SCC も移行します。同様に、MTC は namespace の永続ボリュームにリンクされた永続ボリューム要求 (PVC)を移行します。

    注記

    クラスタースコープのリソースは、リソースによっては手動で移行する必要がある場合があります。

  • カスタムリソース (CR) およびカスタムリソース定義 (CRD): MTC は、namespace レベルで CR および CRD を自動的に移行します。

MTC Web コンソールを使用してアプリケーションを移行するには、以下の手順が必要です。

  1. すべてのクラスターに MTC (Migration Toolkit for Containers Operator) をインストールします。

    インターネットアクセスが制限されているか、またはインターネットアクセスのない制限された環境で Migration Toolkit for Containers Operator をインストールできます。ソースおよびターゲットクラスターは、相互に対するネットワークアクセスおよびミラーレジストリーへのネットワークアクセスがなければなりません。

  2. MTC がデータ移行に使用する中間オブジェクトストレージであるレプリケーションリポジトリーを設定します。

    ソースおよびターゲットクラスターには、移行時にレプリケーションリポジトリーへのネットワークアクセスがなければなりません。制限された環境では、Multi-Cloud Object Gateway (MCG) を使用できます。プロキシーサーバーを使用している場合は、レプリケーションリポジトリーとクラスター間のネットワークトラフィックを許可するように設定する必要があります。

  3. ソースクラスターを MTC の Web コンソールに追加します。
  4. レプリケーションリポジトリーを MTC の Web コンソールに追加します。
  5. 以下のデータ移行オプションのいずれかを使用して、移行計画を作成します。

    • Copy: MTC は、データをソースクラスターからレプリケーションリポジトリーにコピーし、レプリケーションリポジトリーからターゲットクラスターにコピーします。

      注記

      イメージの直接移行またはボリュームの直接移行を使用している場合、イメージまたはボリュームはソースクラスターからターゲットクラスターに直接コピーされます。

      migration PV copy
    • Move: MTC は、ソースクラスターからリモートボリューム (例: NFS) をアンマウントし、リモートボリュームをポイントするターゲットクラスターで PV リソースを作成し、その後にリモートボリュームをターゲットクラスターにマウントします。ターゲットクラスターで実行されているアプリケーションは、ソースクラスターが使用していたものと同じリモートボリュームを使用します。リモートボリュームは、ソースクラスターおよびターゲットクラスターからアクセスできる必要があります。

      注記

      レプリケーションリポジトリーはこの図には表示されていませんが、これは移行に必要です。

      migration PV move
  6. 以下のオプションのいずれかを使用して、移行計画を実行します。

    • 段階 移行は、アプリケーションを停止せずにデータをターゲットクラスターにコピーします。

      段階移行は複数回実行して、移行前にほとんどのデータがターゲットにコピーされるようにします。1 つ以上の段階移行を実行すると、カットオーバー移行の期間が短縮されます。

    • カットオーバー は、ソースクラスターでアプリケーションを停止し、リソースをターゲットクラスターに移動します。

      オプション:Halt transactions on the source cluster during migrationのチェックボックスのチェックを解除できます。

OCP 3 to 4 App migration

1.3. データのコピー方法

MTC (Migration Toolkit for Containers) は、ソースクラスターからターゲットクラスターにデータを移行するために、ファイルシステムおよびスナップショットによるデータのコピー方法をサポートします。ご使用の環境に適した方法で、ストレージプロバイダーでサポートされる方法を選択できます。

1.3.1. ファイルシステムのコピー方法

MTC は、データファイルをソースクラスターからレプリケーションリポジトリーにコピーし、そこからターゲットクラスターにコピーします。

ファイルシステムのコピー方法は、間接的な移行にはResticを、直接ボリュームの移行にはRsyncを使用します。

表1.2 ファイルシステムのコピー方法の概要

利点制限
  • クラスターで複数の異なるストレージクラスを使用することが可能
  • すべての S3 ストレージプロバイダーでサポートされている
  • チェックサムを使用したオプションのデータ検証
  • ボリュームの直接移行をサポートします。これにより、パフォーマンスを大幅に向上させることができます。
  • スナップショットのコピー方法よりも遅い
  • オプションのデータ検証は、パフォーマンスを大幅に低下させます。

1.3.2. スナップショットのコピー方法

MTC は、ソースクラスターのデータのスナップショットを、クラウドプロバイダーのレプリケーションリポジトリーにコピーします。データはターゲットクラスターで復元されます。

スナップショットコピー方式は、Amazon Web Services、Google Cloud Provider、Microsoft Azureで使用できます。

表1.3 スナップショットのコピー方法の概要

利点制限
  • ファイルシステムのコピー方法よりも高速
  • クラウドプロバイダーはスナップショットをサポートしている必要があります。
  • クラスターは同じクラウドプロバイダーになければなりません。
  • クラスターは、同じ場所またはリージョンにある必要があります。
  • クラスターには同じストレージクラスがなければなりません。
  • ストレージクラスにはスナップショットとの互換性がある必要があります。
  • ボリュームの直接移行はサポートしません。

1.4. ボリュームの直接移行とイメージの直接移行

イメージの直接移行 (DIM) およびボリュームの直接移行 (DVM) を使用して、イメージおよびデータをソースクラスターからターゲットクラスターに直接移行できます。

異なるアベイラビリティーゾーンにあるノードで DVM を実行する場合に、移行した Pod は永続ボリューム要求にアクセスできないために移行が失敗する可能性があります。

DIM および DVM では、ソースクラスターからレプリケーションリポジトリーにファイルのバックアップを作成し、レプリケーションリポジトリーからターゲットクラスターにファイルを復元する中間ステップが省略されるため、大きなパフォーマンス上の利点があります。データは Rsync で転送されます。

DIM および DVM には追加の前提条件があります。

第2章 MTC (Migration Toolkit for Containers) リリースノート

MTC(Migration Toolkit for Containers)を使用すると、namespace の粒度で OpenShift Container Platform クラスター間でアプリケーションワークロードを移行できます。

OpenShift Container Platform 3 から 4.8 および OpenShift Container Platform 4 クラスター間で移行できます。

MTC には、Web コンソールおよび API が同梱されており、Kubernetes カスタムリソースに基づいて移行を制御してアプリケーションのダウンタイムを最小限に抑えることができます。

2.1. MTC(Migration Toolkit for Containers 1.6)リリースノート

MTC(Migration Toolkit for Containers)バージョン 1.6 リリースノートでは、新機能および拡張機能、非推奨となった機能、および既知の問題について説明しています。

2.1.1. 新機能および改良された機能

本リリースには、以下の新機能および機能拡張が含まれています。

  • 状態の移行:特定の永続ボリューム要求(PVC)を選択して、反復可能な状態のみの移行を実行できます。
  • "New operator version available" の通知: MTC の Web コンソールのクラスターページには、新しい Migration Toolkit for Containers Operator が利用可能になると通知が表示されます。

2.1.2. 非推奨の機能

以下の機能が非推奨になりました。

  • MTC バージョン 1.4 はサポートされなくなりました。

2.1.3. 既知の問題

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

  • OpenShift Container Platform 3.10 では、MigrationController Pod の再起動に過剰に時間を要します。Bugzilla レポートには回避策が含まれています。(BZ#1986796)
  • 段階 Pod は、IBM Cloud の従来の OpenShift Container Platform ソースクラスターからボリュームの直接移行時に失敗します。IBM ブロックストレージプラグインでは、同じノードの複数の Pod に、同じボリュームをマウントすることはできません。その結果、PVC は Rsync Pod およびアプリケーション Pod を同時にマウントすることはできません。この問題を解決するには、移行前にアプリケーション Pod を停止します。(BZ#1887526)
  • AWS gp2 PVC に利用可能な領域がない場合に、MigPlan カスタムリソースには警告は表示されません。(BZ#1963927)
  • IBM Cloud のブロックストレージは、同じアベイラビリティーゾーンに所属している必要があります。仮想プライベートクラウドのブロックストレージに関する IBM FAQ を参照してください。

2.2. Migration Toolkit for Containers 1.5 リリースノート

MTC (Migration Toolkit for Containers) バージョン 1.5 リリースノートでは、新機能、拡張機能、および既知の問題を説明します。

2.2.1. 新機能および改良された機能

本リリースには、以下の新機能および機能拡張が含まれています。

  • Web コンソールの Migration 詳細 ページの Migration リソースツリーが、追加のリソース、Kubernetes イベント、および移行の監視およびデバッグ用のライブステータス情報と共に強化されました。
  • Web コンソールは、数百もの移行プランをサポートできます。
  • ソース名前空間は、移行計画で別のターゲット名前空間にマッピングすることができます。以前のバージョンでは、ソース名前空間は同じ名前を持つターゲット名前空間にマップされていました。
  • ステータス情報を含むフックフェーズは、移行時に Web コンソールに表示されます。
  • Rsync 再試行試行の数は、ボリュームの直接移行時に Web コンソールに表示されます。
  • 永続ボリューム (PV) のサイズ変更は、ターゲットクラスターがディスク領域不足しないように、ボリュームの直接移行用に有効にできます。
  • PV のサイズ変更をトリガーするしきい値は設定可能です。以前のバージョンでは、ディスクの使用状況が 97% を超えると PV のサイズ変更が発生していました。
  • Velero がバージョン 1.6 にアップグレードされ、多くの修正および機能強化が数多く追加されました。
  • キャッシュされた Kubernetes クライアントを有効にして、パフォーマンスを向上させることができます。

2.2.2. 非推奨の機能

以下の機能が非推奨になりました。

  • MTC バージョン 1.2 および 1.3 はサポートされなくなりました。
  • oc convert コマンドが非推奨になるため、非推奨の API の更新手順は、ドキュメントのトラブルシューティングセクションから削除されました。

2.2.3. 既知の問題

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

  • 400 を超える移行プランを作成する場合、Microsoft Azure ストレージは利用できません。MigStorage カスタムリソースは、以下のメッセージを表示します。The request is being throttled as the limit has been reached for operation type (このリクエストは、操作タイプの制限に達したため、スロットルされています)。(BZ#1977226)
  • 移行に失敗すると、移行計画は休止状態の Pod のカスタム永続ボリューム (PV) 設定を保持しません。移行を手動でロールバックし、移行計画を削除し、PV 設定で新たな移行計画を作成する必要があります。(BZ#1784899)
  • PV のサイズ変更は、pv_resizing_threshold が 42% 以上でない限り、AWS gp2 ストレージでは期待どおりに動作しません。(BZ#1973148)
  • PV のサイズ変更は、以下のシナリオでは OpenShift Container Platform 3.7 および 3.9 ソースクラスターでは機能しません。

    • アプリケーションは、MTC のインストール後にインストールされている。
    • アプリケーション Pod は MTC のインストール後に別のノードで再スケジュールされました。

      OpenShift Container Platform 3.7 および 3.9 では、Velero が Restic Pod に PV を自動的にマウントできるようにする Mount Propagation 機能をサポートしません。MigAnalytic カスタムリソース (CR) は、Restic Pod から PV データを収集できず、リソースを 0 として報告します。MigPlan CR は以下のようなステータスを表示します。

      出力例

      status:
        conditions:
        - category: Warn
          lastTransitionTime: 2021-07-15T04:11:44Z
          message: Failed gathering extended PV usage information for PVs [nginx-logs nginx-html], please see MigAnalytic openshift-migration/ocp-24706-basicvolmig-migplan-1626319591-szwd6 for details
          reason: FailedRunningDf
          status: "True"
          type: ExtendedPVAnalysisFailed

      PV のサイズ変更を有効にするには、ソースクラスターで Restic daemonset を手動で再起動するか、アプリケーションと同じノードで Restic Pod を再起動します。Restic を再起動しない場合、PV のサイズ変更なしにボリュームの直接移行を実行できます。(BZ#1982729)

2.2.4. 技術上の変更点

本リリースには、以下の技術上の変更点があります。

  • OpenShift Container Platform バージョン 3.7 から 4.5 では、従来の Migration Toolkit for Containers Operator バージョン 1.5.1 は手動でインストールします。
  • OpenShift Container Platform バージョン 4.6 以降では、Migration Toolkit for Containers Operator バージョン 1.5.1 は、Operator Lifecycle Manager を使用してインストールします。

2.3. Migration Toolkit for Containers 1.4 リリースノート

MTC (Migration Toolkit for Containers) バージョン 1.4 リリースノートでは、新機能、拡張機能、および既知の問題を説明します。

2.3.1. 既知の問題

  • MTC 1.4.6 を OpenShift Container Platform 3.9 (BZ#1981794) または 3.10 (BZ#1981537) にデプロイできません。

第3章 MTC (Migration Toolkit for Containers) のインストール

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4 にインストールできます。

従来の Migration Toolkit for Containers Operator を OpenShift Container Platform 4 ソースクラスターに手動でインストールした後に、Operator Lifecycle Manager を使用して OpenShift Container Platform 4.8 ターゲットクラスターに Migration Toolkit for Containers Operator をインストールします。

デフォルトで、MTC Web コンソールおよび Migration Controller Pod はターゲットクラスターで実行されます。Migration Controller カスタムリソースマニフェストを、MTC の Web コンソールおよび Migration Controller Pod をリモートクラスターで実行するように設定できます。

MTC をインストールした後、オブジェクトストレージをレプリケーションリポジトリーとして使用するように設定する必要があります。

3.1. 互換性のガイドライン

OpenShift Container Platform バージョンと互換性がある MTC (Migration Toolkit for Containers) バージョンをインストールする必要があります。

カスタムリソース定義 API バージョンが互換性がないため、MTC 1.6.x を OpenShift Container Platform バージョン 3.7 から 4.5 にインストールすることはできません。

MigrationController カスタムリソースおよび MTC の Web コンソールがターゲットクラスターで実行されている限り、MTC 1.5.1 のあるソースクラスターから MTC 1.6.x のターゲットクラスターに移行できます。

表3.1 OpenShift Container Platform および MTC の互換性

OpenShift Container Platform バージョンMTC のバージョンMigration Toolkit for Containers Operator

3.7

1.5.1

従来の Migration Toolkit for Containers Operator。

operator-3.7.yml ファイルで手動でインストールします。

3.9 から 4.5

1.5.1

従来の Migration Toolkit for Containers Operator。

operator.yml ファイルで手動で インストールします。

4.6 以降

1.6.x[1]

Migration Toolkit for Containers Operator。

Operator Lifecycle Manager でインストールします。

1 最新の z-stream リリース。

3.2. OpenShift Container Platform 4.2 での従来の Migration Toolkit for Containers Operator の 4.5 へのインストール

レガシー Migration Toolkit for Containers Operator を手動で OpenShift Container Platform バージョン 4.2 から 4.5 にインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • registry.redhat.io にアクセスできる必要があります。
  • podman がインストールされている必要があります。

手順

  1. Red Hat カスタマーポータルの認証情報を使用して registry.redhat.io にログインします。

    $ sudo podman login registry.redhat.io
  2. operator.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.1):/operator.yml ./
  3. controller.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.1):/controller.yml ./
  4. OpenShift Container Platform 3 クラスターにログインします。
  5. クラスターが registry.redhat.io で認証できることを確認します。

    $ oc run test --image registry.redhat.io/ubi8 --command sleep infinity
  6. Migration Toolkit for Containers Operator オブジェクトを作成します。

    $ oc create -f operator.yml

    出力例

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Error from server (AlreadyExists) メッセージは無視できます。これらは、以降のリソースで提供される OpenShift Container Platform 3 の以前のバージョン用にリソースを作成する Migration Toolkit for Containers Operator によって生じます。
  7. MigrationController オブジェクトを作成します。

    $ oc create -f controller.yml
  8. MTC Pod が実行されていることを確認します。

    $ oc get pods -n openshift-migration

3.3. Migration Toolkit for Containers Operator の OpenShift Container Platform 4.8 へのインストール

Operator Lifecycle Manager を使用して OpenShift Container Platform 4.8 に Migration Toolkit for Containers Operator をインストールします。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  2. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。
  3. Migration Toolkit for Containers Operator を選択し、Install をクリックします。
  4. Install をクリックします。

    Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

  5. Migration Toolkit for Containers Operator をクリックします。
  6. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
  7. Create をクリックします。
  8. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

3.4. プロキシーの設定

OpenShift Container Platform 4.1 以前のバージョンでは、これらのバージョンはクラスター全体の proxy オブジェクトをサポートしないため、Migration Toolkit for Containers Operator のインストール後に、MigrationController カスタムリソース (CR) マニフェストでプロキシーを設定する必要があります。

OpenShift Container Platform 4.2 から 4.8 の場合、MTC (Migration Toolkit for Containers) はクラスター全体のプロキシー設定を継承します。クラスター全体のプロキシー設定を上書きする場合は、プロキシーパラメーターを変更できます。

プロキシーを設定して SPDY プロトコルを有効にし、Upgrade HTTP ヘッダーを API サーバーに転送する必要があります。それ以外の場合は、Upgrade request required エラーが表示されます。MigrationController CR は SPDY を使用してリモート Pod 内でコマンドを実行します。API サーバーとの Websocket 接続を開くには、Upgrade HTTP ヘッダーが必要です。

ボリュームの直接移行

プロキシーの背後にあるソースクラスターから DVM (直接ボリューム移行) を実行している場合は、Stunnel プロキシーを設定する必要があります。Stunnel は、証明書を変更せずに、TCP 接続のソースクラスターとターゲットクラスター間に透過的なトンネルを作成します。

DVM は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

手順

  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
      httpProxy: http://<username>:<password>@<ip>:<port> 2
      httpsProxy: http://<username>:<password>@<ip>:<port> 3
      noProxy: example.com 4
    1
    ボリュームの直接移行のための Stunnel プロキシー URL。
    2
    クラスター外部で HTTP 接続を作成するためのプロキシー URL。URL スキームは http である必要があります。
    3
    クラスター外部で HTTPS 接続を作成するためのプロキシー URL。これが指定されていない場合、HTTP および HTTPS 接続の両方に httpProxy が使用されます。
    4
    プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス、または他のネットワーク CIDR のカンマ区切りの一覧。

    サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。インストール設定で networking.machineNetwork[].cidr フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

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

  3. マニフェストを migration-controller.yaml として保存します。
  4. 更新したマニフェストを適用します。

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

詳細は、「Configuring the cluster-wide proxy」を参照してください。

3.5. レプリケーションリポジトリーの設定

オブジェクトストレージをレプリケーションリポジトリーとして使用するように設定する必要があります。MTC (Migration Toolkit for Containers) は、データをソースクラスターからレプリケーションリポジトリーにコピーしてから、レプリケーションリポジトリーからターゲットクラスターにコピーします。

MTC は、ソースクラスターからターゲットクラスターにデータを移行するために、ファイルシステムおよびスナップショットによるデータのコピー方法をサポートします。ご使用の環境に適しており、ストレージプロバイダーでサポートされる方法を選択します。

MTC は、以下のストレージプロバイダーをサポートしています。

  • Multi-Cloud Object Gateway (MCG)
  • Amazon Web Services (AWS) S3
  • Google Cloud Platform (GCP)
  • Microsoft Azure Blob
  • 汎用 S3 オブジェクトストレージ(例: Minio または Ceph S3)

3.5.1. 前提条件

  • すべてのクラスターには、レプリケーションリポジトリーへの中断されないネットワークアクセスが必要です。
  • 内部でホストされるレプリケーションリポジトリーでプロキシーサーバーを使用する場合は、プロキシーがレプリケーションリポジトリーへのアクセスを許可することを確認する必要があります。

3.5.2. Multi-Cloud Object Gateway の設定

OpenShift Container Storage Operator をインストールし、Multi-Cloud Object Gateway (MCG) ストレージバケットを MTC (Migration Toolkit for Containers) のレプリケーションリポジトリーとして設定できます。

3.5.2.1. OpenShift Container Storage Operator のインストール

OpenShift Container Storage Operator は、OperatorHub からインストールできます。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  2. Filter by keyword (この場合は、OCS) を使用し、 OpenShift Container Storage Operator を見つけます。
  3. OpenShift Container Storage Operator を選択し、Install をクリックします。
  4. Update ChannelInstallation Mode、および Approval Strategy を選択します。
  5. Install をクリックします。

    Installed Operators ページで、OpenShift Container Storage Operator は、Succeeded のステータスと共に openshift-storage プロジェクトに表示されます。

3.5.2.2. Multi-Cloud Object Gateway ストレージバケットの作成

Multi-Cloud Object Gateway (MCG) ストレージバケットのカスタムリソース (CR) を作成できます。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ oc login -u <username>
  2. NooBaa CR 設定ファイル noobaa.yml を以下の内容で作成します。

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: <noobaa>
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    非常に小規模なクラスターの場合、値を 0.1 に変更できます。
  3. NooBaa オブジェクトを作成します。

    $ oc create -f noobaa.yml
  4. 以下の内容で、BackingStore CR 設定ファイル bs.yml を作成します。

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <mcg_backing_store>
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: <volume_size> 2
        storageClass: <storage_class> 3
      type: pv-pool
    1
    永続ボリュームプール内のボリューム数を指定します。
    2
    50Gi などに、ボリュームのサイズを指定します。
    3
    gp2 などに、ストレージクラスを作成します。
  5. BackingStore オブジェクトを作成します。

    $ oc create -f bs.yml
  6. 以下の内容で BucketClass CR 設定ファイル bc.yml を作成します。

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: <mcg_bucket_class>
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - <mcg_backing_store>
          placement: Spread
  7. BucketClass オブジェクトを作成します。

    $ oc create -f bc.yml
  8. 以下の内容で ObjectBucketClaim CR 設定ファイル obc.yml を作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <bucket>
      namespace: openshift-storage
    spec:
      bucketName: <bucket> 1
      storageClassName: <storage_class>
      additionalConfig:
        bucketclass: <mcg_bucket_class>
    1
    レプリケーションリポジトリーを MTC の Web コンソールに追加するために使用するバケット名を記録します。
  9. ObjectBucketClaim オブジェクトを作成します。

    $ oc create -f obc.yml
  10. リソース作成プロセスを監視し、ObjectBucketClaim ステータスが Bound であることを確認します。

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    このプロセスには、5 分から 10 分の時間がかかる場合があります。

  11. 以下の値を取得して記録します。この値は、レプリケーションリポジトリーを MTC の Web コンソールに追加する際に必要になります。

    • S3 エンドポイント:

      $ oc get route -n openshift-storage s3
    • S3 プロバイダーアクセスキー:

      $ oc get secret -n openshift-storage migstorage \
        -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 プロバイダーシークレットアクセスキー:

      $ oc get secret -n openshift-storage migstorage \
        -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

3.5.3. Amazon Web Services S3 の設定

Amazon Web Services (AWS) S3 ストレージバケットを MTC (Migration Toolkit for Containers) のレプリケーションリポジトリーとして設定できます。

前提条件

  • AWS S3 ストレージバケットは、ソースクラスターおよびターゲットクラスターからアクセスできる必要があります。
  • AWS CLI がインストールされていること。
  • スナップショットのコピー方法を使用する場合は、以下の条件を満たす必要があります。

    • EC2 Elastic Block Storage (EBS) にアクセスできる必要があります。
    • ソースおよびターゲットクラスターが同じリージョンにある必要があります。
    • ソースおよびターゲットクラスターには、同じストレージクラスがある必要があります。
    • ストレージクラスはスナップショットと互換性がある必要があります。

手順

  1. AWS S3 バケットを作成します。

    $ aws s3api create-bucket \
        --bucket <bucket> \ 1
        --region <bucket_region> 2
    1
    S3 バケット名を指定します。
    2
    S3 バケットリージョンを指定します (例: us-east-1)。
  2. IAM ユーザー velero を作成します。

    $ aws iam create-user --user-name velero
  3. EC2 EBS スナップショットポリシーを作成します。

    $ cat > velero-ec2-snapshot-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            }
        ]
    }
    EOF
  4. 1 つまたはすべての S3 バケットの AWS S3 アクセスポリシーを作成します。

    $ cat > velero-s3-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket>" 2
                ]
            }
        ]
    }
    EOF
    1 2
    単一の S3 バケットへのアクセスを付与するには、バケット名を指定します。すべての AWS S3 バケットへのアクセスを付与するには、以下の例が示すようにバケット名の代わりに * を指定します。

    出力例

    "Resource": [
        "arn:aws:s3:::*"

  5. EC2 EBS ポリシーを velero に割り当てます。

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-ebs \
      --policy-document file://velero-ec2-snapshot-policy.json
  6. AWS S3 ポリシーを velero に割り当てます。

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero-s3 \
      --policy-document file://velero-s3-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>, 1
            "AccessKeyId": <AWS_ACCESS_KEY_ID> 2
        }
    }
    1 2
    AWS リポジトリーを MTC の Web コンソールに追加するために AWS_SECRET_ACCESS_KEY および AWS_ACCESS_KEY_ID を記録します。

3.5.4. Google Cloud Provider の設定

Google Cloud Provider (GCP) ストレージバケットを MTC (Migration Toolkit for Containers) のレプリケーションリポジトリーとして設定できます。

前提条件

  • GCP ストレージバケットは、ソースクラスターおよびターゲットクラスターからアクセスできる必要があります。
  • gsutil がインストールされていること。
  • スナップショットのコピー方法を使用する場合は、以下の条件を満たす必要があります。

    • ソースおよびターゲットクラスターが同じリージョンにある必要があります。
    • ソースおよびターゲットクラスターには、同じストレージクラスがある必要があります。
    • ストレージクラスはスナップショットと互換性がある必要があります。

手順

  1. gsutil にログインします。

    $ gsutil init

    出力例

    Welcome! This command will take you through the configuration of gcloud.
    
    Your current configuration has been set to: [default]
    
    To continue, you must login. Would you like to login (Y/n)?

  2. BUCKET 変数を設定します。

    $ BUCKET=<bucket> 1
    1
    バケット名を指定します。
  3. ストレージバケットを作成します。

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 変数をアクティブなプロジェクトに設定します。

    $ PROJECT_ID=`gcloud config get-value project`
  5. velero IAM サービスアカウントを作成します。

    $ gcloud iam service-accounts create velero \
        --display-name "Velero Storage"
  6. SERVICE_ACCOUNT_EMAIL 変数を作成します。

    $ SERVICE_ACCOUNT_EMAIL=`gcloud iam service-accounts list \
      --filter="displayName:Velero Storage" \
      --format 'value(email)'`
  7. ROLE_PERMISSIONS 変数を作成します。

    $ 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
    )
  8. velero.server カスタムロールを作成します。

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  9. IAM ポリシーバインディングをプロジェクトに追加します。

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  10. IAM サービスアカウントを更新します。

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  11. IAM サービスアカウントのキーを現在のディレクトリーにある credentials-velero ファイルに保存します。

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

3.5.5. Microsoft Azure Blob の設定

Microsoft Azure Blob ストレージコンテナーを MTC (Migration Toolkit for Containers) のレプリケーションリポジトリーとして設定できます。

前提条件

  • Azure ストレージアカウント があること。
  • Azure CLI がインストールされていること。
  • Azure Blob ストレージコンテナーがソースクラスターおよびターゲットクラスターからアクセスできること。
  • スナップショットのコピー方法を使用する場合は、以下の条件を満たす必要があります。

    • ソースおよびターゲットクラスターが同じリージョンにある必要があります。
    • ソースおよびターゲットクラスターには、同じストレージクラスがある必要があります。
    • ストレージクラスはスナップショットと互換性がある必要があります。

手順

  1. AZURE_RESOURCE_GROUP 変数を設定します。

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  2. Azure リソースグループを作成します。

    $ az group create -n $AZURE_RESOURCE_GROUP --location <CentralUS> 1
    1
    場所を指定します。
  3. AZURE_STORAGE_ACCOUNT_ID 変数を設定します。

    $ AZURE_STORAGE_ACCOUNT_ID=velerobackups
  4. 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
  5. BLOB_CONTAINER 変数を設定します。

    $ BLOB_CONTAINER=velero
  6. Azure Blob ストレージコンテナーを作成します。

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  7. 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`
  8. サービスプリンシパルの認証情報を 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

3.5.6. レプリケーションリポジトリーを設定するためのその他のリソース

第4章 ネットワークの制限された環境での Migration Toolkit for Containers Operator のインストール

以下の手順を実行して、ネットワークが制限された環境で OpenShift Container Platform 4 に MTC (Migration Toolkit for Containers) をインストールすることができます。

  1. ミラーリングされたOperatorカタログを作成します。

    このプロセスは、registry.redhat.io イメージとミラーレジストリーイメージ間のマッピングを含む mapping.txt ファイルを作成します。mapping.txt ファイルは、レガシーの Migration Toolkit for Containers Operator を OpenShift Container Platform 4.2 から 4.5 ソースクラスターにインストールするために必要です。

  2. Operator Lifecycle Managerを使用して、OpenShift Container Platform 4.8のターゲットクラスタにMigration Toolkit for Containers Operatorをインストールします。

    デフォルトで、MTC Web コンソールおよび Migration Controller Pod はターゲットクラスターで実行されます。Migration Controller カスタムリソースマニフェストを、MTC の Web コンソールおよび Migration Controller Pod をリモートクラスターで実行するように設定できます。

  3. Migration Toolkit for Containers Operator をソースクラスターにインストールします。

    • OpenShift Container Platform 4.6 以降: Operator Lifecycle Manager を使用して Migration Toolkit for Containers Operator をインストールします。
    • OpenShift Container Platform 4.2 から 4.5: コマンドラインインターフェースからレガシー Migration Toolkit for Containers Operator をインストールします。
  4. オブジェクトストレージをレプリケーションリポジトリーとして使用するように設定します。

4.1. 互換性のガイドライン

OpenShift Container Platform バージョンと互換性がある MTC (Migration Toolkit for Containers) バージョンをインストールする必要があります。

カスタムリソース定義 API バージョンが互換性がないため、MTC 1.6.x を OpenShift Container Platform バージョン 3.7 から 4.5 にインストールすることはできません。

MigrationController カスタムリソースおよび MTC の Web コンソールがターゲットクラスターで実行されている限り、MTC 1.5.1 のあるソースクラスターから MTC 1.6.x のターゲットクラスターに移行できます。

表4.1 OpenShift Container Platform および MTC の互換性

OpenShift Container Platform バージョンMTC のバージョンMigration Toolkit for Containers Operator

3.7

1.5.1

従来の Migration Toolkit for Containers Operator。

operator-3.7.yml ファイルで手動でインストールします。

3.9 から 4.5

1.5.1

従来の Migration Toolkit for Containers Operator。

operator.yml ファイルで手動で インストールします。

4.6 以降

1.6.x[1]

Migration Toolkit for Containers Operator。

Operator Lifecycle Manager でインストールします。

1 最新の z-stream リリース。

4.2. Migration Toolkit for Containers Operator の OpenShift Container Platform 4.8 へのインストール

Operator Lifecycle Manager を使用して OpenShift Container Platform 4.8 に Migration Toolkit for Containers Operator をインストールします。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • ローカルレジストリーのミラーイメージで Operator カタログを作成する必要があります。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  2. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。
  3. Migration Toolkit for Containers Operator を選択し、Install をクリックします。
  4. Install をクリックします。

    Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

  5. Migration Toolkit for Containers Operator をクリックします。
  6. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
  7. Create をクリックします。
  8. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

4.3. OpenShift Container Platform 4.2 での従来の Migration Toolkit for Containers Operator の 4.5 へのインストール

レガシー Migration Toolkit for Containers Operator を手動で OpenShift Container Platform バージョン 4.2 から 4.5 にインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • registry.redhat.io にアクセスできる必要があります。
  • podman がインストールされている必要があります。
  • registry.redhat.io からファイルをダウンロードするには、ネットワークアクセスのある Linux ワークステーションが必要です。
  • Operator カタログのミラーイメージを作成する必要があります。
  • OpenShift Container Platform 4.8では、ミラーリングされたOperatorカタログからMigration Toolkit for Containers Operatorをインストールする必要があります。

手順

  1. Red Hat カスタマーポータルの認証情報を使用して registry.redhat.io にログインします。

    $ sudo podman login registry.redhat.io
  2. operator.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.1):/operator.yml ./
  3. controller.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.1):/controller.yml ./
  4. 以下のコマンドを実行して、Operator イメージマッピングを取得します。

    $ grep openshift-migration-legacy-rhel8-operator ./mapping.txt | grep rhmtc

    mapping.txt ファイルは Operator カタログのミラーリング時に作成されました。出力には、registry.redhat.io イメージとミラーレジストリーイメージ間のマッピングが表示されます。

    出力例

    registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a=<registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator

  5. ansible および operator コンテナーの image 値、および operator.yml ファイルの REGISTRY 値を更新します。

    containers:
      - name: ansible
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
    ...
      - name: operator
        image: <registry.apps.example.com>/rhmtc/openshift-migration-legacy-rhel8-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
    ...
        env:
        - name: REGISTRY
          value: <registry.apps.example.com> 3
    1 2
    ミラーレジストリーおよび Operator イメージの sha256 値を指定します。
    3
    ミラーレジストリーを指定します。
  6. OpenShift Container Platform 3 クラスターにログインします。
  7. Migration Toolkit for Containers Operator オブジェクトを作成します。

    $ oc create -f operator.yml

    出力例

    namespace/openshift-migration created
    rolebinding.rbac.authorization.k8s.io/system:deployers created
    serviceaccount/migration-operator created
    customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
    role.rbac.authorization.k8s.io/migration-operator created
    rolebinding.rbac.authorization.k8s.io/migration-operator created
    clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
    deployment.apps/migration-operator created
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
    Error from server (AlreadyExists): error when creating "./operator.yml":
    rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

    1
    Error from server (AlreadyExists) メッセージは無視できます。これらは、以降のリソースで提供される OpenShift Container Platform 3 の以前のバージョン用にリソースを作成する Migration Toolkit for Containers Operator によって生じます。
  8. MigrationController オブジェクトを作成します。

    $ oc create -f controller.yml
  9. MTC Pod が実行されていることを確認します。

    $ oc get pods -n openshift-migration

4.4. プロキシーの設定

OpenShift Container Platform 4.1 以前のバージョンでは、これらのバージョンはクラスター全体の proxy オブジェクトをサポートしないため、Migration Toolkit for Containers Operator のインストール後に、MigrationController カスタムリソース (CR) マニフェストでプロキシーを設定する必要があります。

OpenShift Container Platform 4.2 から 4.8 の場合、MTC (Migration Toolkit for Containers) はクラスター全体のプロキシー設定を継承します。クラスター全体のプロキシー設定を上書きする場合は、プロキシーパラメーターを変更できます。

プロキシーを設定して SPDY プロトコルを有効にし、Upgrade HTTP ヘッダーを API サーバーに転送する必要があります。それ以外の場合は、Upgrade request required エラーが表示されます。MigrationController CR は SPDY を使用してリモート Pod 内でコマンドを実行します。API サーバーとの Websocket 接続を開くには、Upgrade HTTP ヘッダーが必要です。

ボリュームの直接移行

プロキシーの背後にあるソースクラスターから DVM (直接ボリューム移行) を実行している場合は、Stunnel プロキシーを設定する必要があります。Stunnel は、証明書を変更せずに、TCP 接続のソースクラスターとターゲットクラスター間に透過的なトンネルを作成します。

DVM は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

手順

  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
      httpProxy: http://<username>:<password>@<ip>:<port> 2
      httpsProxy: http://<username>:<password>@<ip>:<port> 3
      noProxy: example.com 4
    1
    ボリュームの直接移行のための Stunnel プロキシー URL。
    2
    クラスター外部で HTTP 接続を作成するためのプロキシー URL。URL スキームは http である必要があります。
    3
    クラスター外部で HTTPS 接続を作成するためのプロキシー URL。これが指定されていない場合、HTTP および HTTPS 接続の両方に httpProxy が使用されます。
    4
    プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス、または他のネットワーク CIDR のカンマ区切りの一覧。

    サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。インストール設定で networking.machineNetwork[].cidr フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

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

  3. マニフェストを migration-controller.yaml として保存します。
  4. 更新したマニフェストを適用します。

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

詳細は、「Configuring the cluster-wide proxy」を参照してください。

4.5. レプリケーションリポジトリーの設定

オブジェクトストレージをレプリケーションリポジトリーとして使用するように設定する必要があります。MTC (Migration Toolkit for Containers) は、データをソースクラスターからレプリケーションリポジトリーにコピーしてから、レプリケーションリポジトリーからターゲットクラスターにコピーします。Multi-Cloud Object Gateway (MCG) は、ネットワークが制限された環境で唯一サポートされているオプションです。

MTC は、ソースクラスターからターゲットクラスターにデータを移行するために、ファイルシステムおよびスナップショットによるデータのコピー方法をサポートします。ご使用の環境に適した方法で、ストレージプロバイダーでサポートされる方法を選択できます。

4.5.1. 前提条件

  • すべてのクラスターには、レプリケーションリポジトリーへの中断されないネットワークアクセスが必要です。
  • 内部でホストされるレプリケーションリポジトリーでプロキシーサーバーを使用する場合は、プロキシーがレプリケーションリポジトリーへのアクセスを許可することを確認する必要があります。

4.5.2. Multi-Cloud Object Gateway の設定

OpenShift Container Storage Operator をインストールし、Multi-Cloud Object Gateway (MCG) ストレージバケットを MTC (Migration Toolkit for Containers) のレプリケーションリポジトリーとして設定できます。

4.5.2.1. OpenShift Container Storage Operator のインストール

OpenShift Container Storage Operator は、OperatorHub からインストールできます。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub をクリックします。
  2. Filter by keyword (この場合は、OCS) を使用し、 OpenShift Container Storage Operator を見つけます。
  3. OpenShift Container Storage Operator を選択し、Install をクリックします。
  4. Update ChannelInstallation Mode、および Approval Strategy を選択します。
  5. Install をクリックします。

    Installed Operators ページで、OpenShift Container Storage Operator は、Succeeded のステータスと共に openshift-storage プロジェクトに表示されます。

4.5.2.2. Multi-Cloud Object Gateway ストレージバケットの作成

Multi-Cloud Object Gateway (MCG) ストレージバケットのカスタムリソース (CR) を作成できます。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ oc login -u <username>
  2. NooBaa CR 設定ファイル noobaa.yml を以下の内容で作成します。

    apiVersion: noobaa.io/v1alpha1
    kind: NooBaa
    metadata:
      name: <noobaa>
      namespace: openshift-storage
    spec:
     dbResources:
       requests:
         cpu: 0.5 1
         memory: 1Gi
     coreResources:
       requests:
         cpu: 0.5 2
         memory: 1Gi
    1 2
    非常に小規模なクラスターの場合、値を 0.1 に変更できます。
  3. NooBaa オブジェクトを作成します。

    $ oc create -f noobaa.yml
  4. 以下の内容で、BackingStore CR 設定ファイル bs.yml を作成します。

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <mcg_backing_store>
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: <volume_size> 2
        storageClass: <storage_class> 3
      type: pv-pool
    1
    永続ボリュームプール内のボリューム数を指定します。
    2
    50Gi などに、ボリュームのサイズを指定します。
    3
    gp2 などに、ストレージクラスを作成します。
  5. BackingStore オブジェクトを作成します。

    $ oc create -f bs.yml
  6. 以下の内容で BucketClass CR 設定ファイル bc.yml を作成します。

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: <mcg_bucket_class>
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - <mcg_backing_store>
          placement: Spread
  7. BucketClass オブジェクトを作成します。

    $ oc create -f bc.yml
  8. 以下の内容で ObjectBucketClaim CR 設定ファイル obc.yml を作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <bucket>
      namespace: openshift-storage
    spec:
      bucketName: <bucket> 1
      storageClassName: <storage_class>
      additionalConfig:
        bucketclass: <mcg_bucket_class>
    1
    レプリケーションリポジトリーを MTC の Web コンソールに追加するために使用するバケット名を記録します。
  9. ObjectBucketClaim オブジェクトを作成します。

    $ oc create -f obc.yml
  10. リソース作成プロセスを監視し、ObjectBucketClaim ステータスが Bound であることを確認します。

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    このプロセスには、5 分から 10 分の時間がかかる場合があります。

  11. 以下の値を取得して記録します。この値は、レプリケーションリポジトリーを MTC の Web コンソールに追加する際に必要になります。

    • S3 エンドポイント:

      $ oc get route -n openshift-storage s3
    • S3 プロバイダーアクセスキー:

      $ oc get secret -n openshift-storage migstorage \
        -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode
    • S3 プロバイダーシークレットアクセスキー:

      $ oc get secret -n openshift-storage migstorage \
        -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

4.5.3. レプリケーションリポジトリーを設定するためのその他のリソース

第5章 Migration Toolkit for Containers のアップグレード

Migration Toolkit for Containers (MTC) は Operator Lifecycle Manager を使用して OpenShift Container Platform 4.8 でアップグレードできます。

レガシー Migration Toolkit for Containers Operator をインストールして、OpenShift Container Platform バージョン 4.2 の MTC を 4.5 にアップグレードできます。

重要

MTC バージョン 1.3 から 1.6 にアップグレードする場合、MigPlan カスタムリソース (CR) を更新する追加の手順を実行する必要があります。

5.1. OpenShift Container Platform 4.8 での MTC(Migration Toolkit for Containers)のアップグレード

Migration Toolkit for Containers (MTC) は Operator Lifecycle Manager を使用して OpenShift Container Platform 4.8 でアップグレードできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている必要があります。

手順

  1. OpenShift Container Platform コンソールで、OperatorsInstalled Operators に移動します。

    更新が保留中の Operator は Upgrade available のステータスを表示します。

  2. Migration Toolkit for Containers Operator をクリックします。
  3. Subscription タブをクリックします。アップグレードの承認を必要とするアップグレードは、Upgrade Status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
  4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
  5. アップグレードに利用可能なリソースとして一覧表示されているリソースを確認し、Approve をクリックします。
  6. Operators → Installed Operators ページに戻り、アップグレードの進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
  7. Migration Toolkit for Containers Operator をクリックします。
  8. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
  9. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

5.2. OpenShift Container Platform バージョン 4.2 の MTC (Migration Toolkit for Containers) 4.5 へのアップグレード

MTC (Migration Toolkit for Containers) は、レガシーの Migration Toolkit for Containers Operator を手動でインストールすることで、OpenShift Container Platform バージョン 4.2 で 4.5 にアップグレードできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている必要があります。
  • registry.redhat.io にアクセスできる必要があります。
  • podman がインストールされている必要があります。

手順

  1. Red Hat カスタマーポータルの認証情報を使用して registry.redhat.io にログインします。

    $ sudo podman login registry.redhat.io
  2. operator.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.1):/operator.yml ./
  3. Migration Toolkit for Containers Operator を置き換えます。

    $ oc replace --force -f operator.yml
  4. migration-operator デプロイメントを 0 にスケーリングし、デプロイメントを停止します。

    $ oc scale -n openshift-migration --replicas=0 deployment/migration-operator
  5. migration-operator デプロイメントを 1 にスケーリングし、デプロイメントを開始して変更を適用します。

    $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator
  6. migration-operator がアップグレードされていることを確認します。

    $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'
  7. controller.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-legacy-rhel8-operator:v1.5.1):/controller.yml ./
  8. migration-controller オブジェクトを作成します。

    $ oc create -f controller.yml
  9. MTC Pod が実行されていることを確認します。

    $ oc get pods -n openshift-migration

5.3. MTC 1.3 から 1.6 へのアップグレード

MTC (Migration Toolkit for Containers) バージョン 1.3.x を 1.6 にアップグレードする場合、MigrationController Pod が実行されているクラスターで MigPlan カスタムリソース (CR) マニフェストを更新する必要があります。

indirectImageMigration および indirectVolumeMigration パラメーターは MTC 1.3 に存在しないため、バージョン 1.4 のそれらのデフォルト値は false になります。つまり、イメージの直接移行およびボリュームの直接移行が有効にされます。直接移行の要件が満たされないため、これらのパラメーターの値が true に変更されない限り、移行計画は Ready 状態になりません。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている必要があります。

手順

  1. MigrationController Pod が実行されるクラスターにログインします。
  2. MigPlan CR マニフェストを取得します。

    $ oc get migplan <migplan> -o yaml -n openshift-migration
  3. 以下のパラメーター値を更新し、ファイルを migplan.yaml として保存します。

    ...
    spec:
      indirectImageMigration: true
      indirectVolumeMigration: true
  4. MigPlan CR マニフェストを置き換えて変更を適用します。

    $ oc replace -f migplan.yaml -n openshift-migration
  5. 更新された MigPlan CR マニフェストを取得して変更を確認します。

    $ oc get migplan <migplan> -o yaml -n openshift-migration

第6章 移行前のチェックリスト

MTC (Migration Toolkit for Containers) を使用してアプリケーションのワークロードを移行する前に、以下のチェックリストを確認してください。

6.1. クラスターヘルスチェックリスト

  • ❏ クラスターが特定のプラットフォームおよびインストール方法についての最小ハードウェア要件を満たしている (ベアメタルなど)。
  • ❏ MTC バージョンはすべてのクラスターで同一である。
  • ❏ すべての MTC の前提条件を満たしている。
  • ❏ すべてのノードに有効な OpenShift Container Platform サブスクリプションがある。
  • ノードの正常性を検証している
  • アイデンティティープロバイダーが機能している。
  • ❏ 移行ネットワークの最小スループットは 10 Gbps である。
  • ❏ クラスターには移行用に十分なリソースがある。

    注記

    クラスターには、通常のワークロードにほかに移行を実行するために、追加のメモリー、CPU、およびストレージが必要です。実際のリソース要件は、単一の移行計画で移行される Kubernetes リソースの数によって異なります。リソース要件を見積もるため、非実稼働環境で移行をテストする必要があります。

  • ❏ クラスターの etcd ディスクのパフォーマンスfio で確認されている。

6.2. ソースクラスターのチェックリスト

  • ❏ 以下のコマンドを実行して、異常な設定のある永続ボリューム(PV) が Terminating 状態のままであるかを確認している。

    $ oc get pv
  • ❏ 以下のコマンドを実行して、ステータスが Running または Completed 以外の Pod の有無について確認している。

    $ oc get pods --all-namespaces | egrep -v 'Running | Completed'
  • ❏ 以下のコマンドを実行して、再起動数の高い Pod の有無について確認している。

    $ oc get pods --all-namespaces --field-selector=status.phase=Running \
      -o json | jq '.items[]|select(any( .status.containerStatuses[]; \
      .restartCount > 3))|.metadata.name'

    Pod が Running 状態であっても、再起動数の高さが根底にある問題について示唆している可能性があります。

  • ❏ クラスター証明書が移行プロセスの期間 有効である。
  • ❏ 以下のコマンドを実行して、保留中の証明書署名要求の有無を確認している。

    $ oc get csr -A | grep pending -i
  • レジストリーが推奨されるストレージタイプを使用する
  • ❏ イメージをレジストリーを読み取り、これに書き込むことができる。
  • etcd クラスターが正常である。
  • ソースクラスターの平均の API サーバーの応答時間は 50 ミリ秒未満である。

6.3. ターゲットクラスターのチェックリスト

  • ❏ クラスターに、データベース、ソースコードリポジトリー、コンテナーイメージレジストリー、CI/CD ツールなどの外部サービスにアクセスするための正しいネットワーク設定およびパーミッションがある。
  • ❏ クラスターによって提供されるサービスを使用する外部アプリケーションおよびサービスに、クラスターにアクセスするための正しいネットワーク設定およびパーミッションがある。
  • ❏ 内部コンテナーイメージの依存関係の要件を満たしている。
  • ❏ ターゲットクラスターおよびレプリケーションリポジトリーに十分なストレージ容量がある。

第7章 アプリケーションの移行

アプリケーションの移行は、MTC(Migration Toolkit for Containers)のウェブコンソールまたはコマンドラインを使用して行うことができます。

ほとんどのクラスタースコープのリソースは MTC で処理されません。アプリケーションがクラスタースコープのリソースを必要とする場合、ターゲットクラスターでそれらを手動で作成する必要がある場合があります。

段階移行とカットオーバー移行を使用して、クラスター間でアプリケーションを移行することができます。

  • Stage 移行は、アプリケーションを停止せずにデータをソースクラスターからターゲットクラスターにコピーします。段階移行は複数回実行して、カットオーバー移行の期間を短縮できます。
  • Cutover 移行はソースクラスターのトランザクションを停止し、リソースをターゲットクラスターに移動します。

状態の移行を使用して、アプリケーションの状態を移行できます。

  • 状態の移行は、選択した永続ボリューム要求 (PVC) および Kubernetes リソースをコピーします。
  • 状態の移行を使用して、同じクラスター内の namespace を移行できます。

移行時に、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 を重複させるリスクがあります。

7.1. 移行の前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

イメージの直接移行

  • ソースクラスターのセキュアな内部レジストリーが公開されている必要があります。
  • 公開されるレジストリーへのルートを作成しておく必要があります。

ボリュームの直接移行

  • クラスターがプロキシーを使用する場合に Stunnel TCP プロキシーを設定している必要があります。

クラスター

  • ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
  • MTC のバージョンは、すべてのクラスターで同一である必要があります。

ネットワーク

  • クラスターには、レプリケーションリポジトリーに対して、また各クラスター間で無制限のネットワークアクセスが必要です。
  • move を使用して永続ボリュームをコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。
  • OpenShift Container Platform 4 クラスターで以下のポートを有効にする必要があります。

    • 6443 (API サーバー)
    • 443 (ルート)
    • 53 (DNS)
  • TLS を使用している場合は、レプリケーションリポジトリーでポート 443 を有効にする必要があります。

永続ボリューム (PV)

  • PV は有効である必要があります。
  • PV は永続ボリューム要求にバインドされる必要があります。
  • スナップショットを使用して PV をコピーする場合には、以下の前提条件が追加されます。

    • クラウドプロバイダーはスナップショットをサポートしている必要があります。
    • PV に同じクラウドプロバイダーがなければなりません。
    • PV は同じ地理的リージョンにある必要があります。
    • PV には同じストレージクラスがなければなりません。

7.2. MTC の Web コンソールを使用したアプリケーションの移行

クラスターおよびレプリケーションリポジトリーを MTC の Web コンソールを使用して設定する必要があります。次に、移行計画を作成し、これを実行できます。

7.2.1. MTC の Web コンソールの起動

ブラウザーで MTC (Migration Toolkit for Containers) Web コンソールを起動できます。

前提条件

  • MTC の Web コンソールには、OpenShift Container Platform Web コンソールにアクセスできる必要があります。
  • MTC の Web コンソールには、OAuth 認証サーバーへのネットワークアクセスが必要です。

手順

  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 の ユーザー名 および パスワード を使用してログインします。

7.2.2. MTC の Web コンソールへのクラスターの追加

クラスターを MTC (Migration Toolkit for Containers) Web コンソールに追加できます。

前提条件

  • Azure スナップショットを使用してデータをコピーする場合:

    • クラスターの Azure リソースグループ名を指定する必要があります。
    • クラスターは同じ Azure リソースグループにある必要があります。
    • クラスターは同じ地理的な場所にある必要があります。
  • イメージの直接移行を使用している場合、ルートを公開する必要があります。

手順

  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 一覧に表示されます。

7.2.3. MTC の Web コンソールへのレプリケーションリポジトリーの追加

MTC (Migration Toolkit for Containers) の Web コンソールに、オブジェクトストレージをレプリケーションリポジトリーとして追加できます。

MTC は、以下のストレージプロバイダーをサポートしています。

  • Amazon Web Services (AWS) S3
  • Multi-Cloud Object Gateway (MCG)
  • 汎用 S3 オブジェクトストレージ(例: Minio または Ceph S3)
  • Google Cloud Provider (GCP)
  • Microsoft Azure Blob

前提条件

  • オブジェクトストレージをレプリケーションリポジトリーとして設定する必要があります。

手順

  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 一覧に表示されます。

7.2.4. MTC の Web コンソールでの移行計画の作成

MTC (Migration Toolkit for Containers) Web コンソールで移行計画を作成できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • 同じ MTC バージョンがすべてのクラスターにインストールされていることを確認する必要があります。
  • クラスターおよびレプリケーションリポジトリーを MTC の Web コンソールに追加する必要があります。
  • move データコピー方法を使用して永続ボリューム (PV) を移行する場合、ソースクラスターおよびターゲットクラスターには、リモートボリュームへの中断されないネットワークアクセスが必要です。
  • イメージの直接移行を使用する必要がある場合は、ソースクラスターのイメージレジストリーに公開されたルートを指定する必要があります。これは、MTC の Web コンソールまたは MigCluster カスタムリソースマニフェストを更新して実行できます。

手順

  1. MTC Web コンソールで、Migration plans をクリックします。
  2. Add migration plan をクリックします。
  3. Plan name を入力します。

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

  4. Source clusterTarget 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 一覧に表示されます。

永続ボリュームのコピー方法に関する他のリソース

7.2.5. MTC の Web コンソールでの移行計画の実行

MTC (Migration Toolkit for Containers) の Web コンソールで作成した移行計画を使用してアプリケーションとデータを移行できます。

注記

移行時に、MTC は移行された永続ボリューム (PV) の回収ポリシーをターゲットクラスターで Retain に設定します。

Backup カスタムリソースには、元の回収ポリシーを示す PVOriginalReclaimPolicy アノテーションが含まれます。移行した PV の回収ポリシーを手動で復元できます。

前提条件

MTC の Web コンソールには以下が含まれている必要があります。

  • Ready 状態のソースクラスター
  • Ready 状態のターゲットクラスター
  • レプリケーションリポジトリー
  • 有効な移行計画

手順

  1. MTC の Web コンソールにログインし、Migration plans をクリックします。
  2. 移行計画の横にある Options メニュー kebab をクリックし、Migration で以下のいずれかのオプションを選択します。

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

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

    • State は、選択した Persistent Volume Claim (永続ボリューム要求、PVC) およびアプリケーションの状態を継続する Kubernetes リソースをコピーします。状態の移行を使用して、同じクラスター内の namespace を移行できます。

      重要

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

      • State migration ダイアログで 1 つ以上の PVC を選択し、Migrate をクリックします。
  3. 移行が完了したら、アプリケーションが OpenShift Container Platform Web コンソールで正常に移行されていることを確認します。

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

第8章 高度な移行オプション

移行を自動化し、MigPlan および MigrationController カスタムリソースを変更して大規模な移行を実行し、パフォーマンスを向上させることができます。

8.1. 用語

表8.1 MTC の用語

用語定義

ソースクラスター

アプリケーションの移行元となるクラスター。

宛先クラスター[1]

アプリケーションが移行されるクラスター。

レプリケーションリポジトリー

ボリュームとイメージの直接的な移行時の Kubernetes オブジェクトに使用するオブジェクトストレージ、または間接的な移行時にイメージ、ボリューム、Kubernetes オブジェクトのコピーに使用するオブジェクトストレージ。

レプリケーションリポジトリーはすべてのクラスターからアクセスできる必要があります。

ホストクラスター

migration-controller Pod および Web コンソールが実行されているクラスター。ホストクラスターは通常宛先クラスターですが、これは必須ではありません。

ホストクラスターには、イメージの直接移行にレジストリールートを公開する必要はありません。

リモートクラスター

通常、リモートクラスターはソースクラスターですが、これは必須ではありません。

リモートクラスターには、migration-controller サービスアカウントトークンが含まれる Secret カスタムリソースが必要です。

リモートクラスターには、直接のイメージ移行用にセキュアなレジストリールートを公開する必要があります。

間接的な移行

イメージ、ボリューム、および Kubernetes オブジェクトはソースクラスターからレプリケーションリポジトリーにコピーされ、その後にレプリケーションリポジトリーから宛先クラスターにコピーされます。

ボリュームの直接移行

永続ボリュームはソースクラスターから宛先クラスターに直接コピーされます。

イメージの直接移行

イメージはソースクラスターから宛先クラスターに直接コピーされます。

段階移行

データはアプリケーションを停止せずに、宛先クラスターにコピーされます。

段階移行を複数回実行すると、カットオーバー移行の時間が短縮されます。

カットオーバー移行

ソースクラスター上のアプリケーションが停止され、アプリケーションリソースが宛先クラスターに移行されます。

状態の移行

アプリケーションの状態は、特定の永続ボリューム要求(PVC)および Kubernetes オブジェクトを宛先クラスターにコピーして移行されます。

ロールバック移行

ロールバック移行は完了した移行をロールバックします。

1 MTC の Web コンソールの ターゲットクラスターを指します。

8.2. コマンドラインを使用したアプリケーションの移行

移行を自動化するために、コマンドラインインターフェース (CLI) を使用して MTC API でアプリケーションを移行できます。

8.2.1. 移行の前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

イメージの直接移行

  • ソースクラスターのセキュアな内部レジストリーが公開されている必要があります。
  • 公開されるレジストリーへのルートを作成しておく必要があります。

ボリュームの直接移行

  • クラスターがプロキシーを使用する場合に Stunnel TCP プロキシーを設定している必要があります。

クラスター

  • ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
  • MTC のバージョンは、すべてのクラスターで同一である必要があります。

ネットワーク

  • クラスターには、レプリケーションリポジトリーに対して、また各クラスター間で無制限のネットワークアクセスが必要です。
  • move を使用して永続ボリュームをコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。
  • OpenShift Container Platform 4 クラスターで以下のポートを有効にする必要があります。

    • 6443 (API サーバー)
    • 443 (ルート)
    • 53 (DNS)
  • TLS を使用している場合は、レプリケーションリポジトリーでポート 443 を有効にする必要があります。

永続ボリューム (PV)

  • PV は有効である必要があります。
  • PV は永続ボリューム要求にバインドされる必要があります。
  • スナップショットを使用して PV をコピーする場合には、以下の前提条件が追加されます。

    • クラウドプロバイダーはスナップショットをサポートしている必要があります。
    • PV に同じクラウドプロバイダーがなければなりません。
    • PV は同じ地理的リージョンにある必要があります。
    • PV には同じストレージクラスがなければなりません。

8.2.2. イメージの直接移行用のレジストリールートの作成

イメージの直接移行にはすべてのリモートクラスターで公開される内部レジストリーへのルートを作成する必要があります。

前提条件

  • 全リモートクラスターの外部トラフィックに対して内部レジストリーを公開する。

    デフォルトで OpenShift Container Platform 4 レジストリーを公開しておく。

手順

  • OpenShift Container Platform 4 レジストリーへのルートを作成するには、以下のコマンドを実行します。

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

8.2.3. プロキシーの設定

OpenShift Container Platform 4.1 以前のバージョンでは、これらのバージョンはクラスター全体の proxy オブジェクトをサポートしないため、Migration Toolkit for Containers Operator のインストール後に、MigrationController カスタムリソース (CR) マニフェストでプロキシーを設定する必要があります。

OpenShift Container Platform 4.2 から 4.8 の場合、MTC (Migration Toolkit for Containers) はクラスター全体のプロキシー設定を継承します。クラスター全体のプロキシー設定を上書きする場合は、プロキシーパラメーターを変更できます。

プロキシーを設定して SPDY プロトコルを有効にし、Upgrade HTTP ヘッダーを API サーバーに転送する必要があります。それ以外の場合は、Upgrade request required エラーが表示されます。MigrationController CR は SPDY を使用してリモート Pod 内でコマンドを実行します。API サーバーとの Websocket 接続を開くには、Upgrade HTTP ヘッダーが必要です。

ボリュームの直接移行

プロキシーの背後にあるソースクラスターから DVM (直接ボリューム移行) を実行している場合は、Stunnel プロキシーを設定する必要があります。Stunnel は、証明書を変更せずに、TCP 接続のソースクラスターとターゲットクラスター間に透過的なトンネルを作成します。

DVM は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

手順

  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
      httpProxy: http://<username>:<password>@<ip>:<port> 2
      httpsProxy: http://<username>:<password>@<ip>:<port> 3
      noProxy: example.com 4
    1
    ボリュームの直接移行のための Stunnel プロキシー URL。
    2
    クラスター外部で HTTP 接続を作成するためのプロキシー URL。URL スキームは http である必要があります。
    3
    クラスター外部で HTTPS 接続を作成するためのプロキシー URL。これが指定されていない場合、HTTP および HTTPS 接続の両方に httpProxy が使用されます。
    4
    プロキシーを除外するための宛先ドメイン名、ドメイン、IP アドレス、または他のネットワーク CIDR のカンマ区切りの一覧。

    サブドメインのみと一致するように、ドメインの前に . を付けます。たとえば、.y.comx.y.com に一致しますが、 y.com には一致しません。* を使用し、すべての宛先のプロキシーをバイパスします。インストール設定で networking.machineNetwork[].cidr フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。

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

  3. マニフェストを migration-controller.yaml として保存します。
  4. 更新したマニフェストを適用します。

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

8.2.4. MTC API を使用したアプリケーションの移行

MTC (Migration Toolkit for Containers) API を使用してコマンドラインからアプリケーションを移行できます。

手順

  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 CR マニフェストを作成します。

    $ 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 CR を指定します。
    5
    リモートクラスターの URL を指定します。
  4. すべてのクラスターが Ready 状態にあることを確認します。

    $ oc describe cluster <cluster>
  5. レプリケーションリポジトリーの Secret CR マニフェストを作成します。

    $ 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

8.2.5. 状態の移行

アプリケーションの状態を構成する Persistent Volume Claim(永続ボリューム要求、PVC)を移行するために MTC (Migration Toolkit for Containers)を使用して反復可能な状態のみの移行を実行できます。移行計画から他の PVC を除外して、指定された PVC を移行します。永続ボリューム (PV) データがターゲットクラスターにコピーされます。PV 参照は移動されていません。アプリケーション Pod は継続してソースクラスターで実行されます。PVC をマップし、ソースおよびターゲット PVC が同期されるようにできます。

アプリケーションの状態を継続する Kubernetes オブジェクトの 1 回限り移行を実行できます。

CI/CD パイプラインがある場合には、それらをターゲットクラスターにデプロイすることでステートレスコンポーネントを移行できます。次に、MTC を使用してステートフルコンポーネントを移行できます。

クラスター間または同じクラスター間で状態の移行を実行できます。

重要

状態の移行は、アプリケーションの状態を構成するコンポーネントのみを移行します。namespace 全体を移行する場合は、ステージまたはカットオーバー移行を使用します。

状態移行の関連情報

  • ステートマイグレーションの対象となるPVCを選択するには、「マイグレーションからPVCを除外する」を参照してください。
  • ソースPVのデータをデスティネーションクラスター上のプロビジョニングされたPVCに移行するには、PVCのマッピングを参照してください。
  • アプリケーションの状態を構成するKubernetesオブジェクトを移行するには、「Kubernetesオブジェクトの移行」を参照してください。

8.3. 移行フック

単一の移行計画に最大 4 つの移行フックを追加し、各フックを移行の異なるフェーズで実行できます。移行フックは、アプリケーションの休止状態のカスタマイズ、サポート外のデータタイプの手動の移行、および移行後のアプリケーションの更新などのタスクを実行します。

移行フックは、以下の移行手順のいずれかでソースまたはターゲットクラスターで実行されます。

  • PreBackup: リソースがソースクラスターでバックアップされる前
  • PostBackup: リソースがソースクラスターでバックアップされた後
  • PreRestore: リソースがターゲットクラスターで復元される前
  • PostRestore: リソースがターゲットクラスターで復元された後

フックを作成するには、デフォルトの Ansible イメージまたはカスタムフックコンテナーで実行される Ansible Playbook を作成します。

Ansible Playbook

Ansible Playbook はフックコンテナーに設定マップとしてマウントされます。フックコンテナーは、MigPlan カスタムリソースに指定されるクラスター、サービスアカウント、および namespace を使用してジョブとして実行されます。ジョブは、デフォルトの再試行数 6 に達するか、正常に完了するまで実行を継続します。これは、最初の Pod がエビクトされるか、または強制終了される場合でも継続されます。

デフォルトの Ansible ランタイムイメージは registry.redhat.io/rhmtc/openshift-migration-hook-runner-rhel7:1.6 です。このイメージは Ansible Runner イメージをベースとしており、Ansible Kubernetes リソースの python-openshift および更新された oc バイナリーが含まれます。

カスタムフックコンテナー

デフォルトの Ansible イメージの代わりにカスタムフックコンテナーを使用できます。

8.3.1. 移行フックの Ansible Playbook の作成

Ansible Playbook を作成して移行フックとして使用することができます。フックは、MTC Web コンソールを使用するか、MigPlan カスタムリソース (CR) マニフェストに spec.hooks パラメーターの値を指定して移行計画に追加できます。

Ansible Playbook はフックコンテナーに設定マップとしてマウントされます。フックコンテナーは、MigPlan で指定されるクラスター、サービスアカウントおよび namespace を使用してジョブとして実行されます。フックコンテナーは指定されたサービスアカウントトークンを使用して、タスクがクラスターで実行される前に認証を必要としないようにします。

8.3.1.1. Ansible モジュール

Ansible shell モジュールを使用して oc コマンドを実行できます。

shell モジュールの例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: get pod name
    shell: oc get po --all-namespaces

k8s_info などの kubernetes.core モジュールを使用して Kubernetes リソースと対話できます。

k8s_facts モジュールの例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Get pod
    k8s_info:
      kind: pods
      api: v1
      namespace: openshift-migration
      name: "{{ lookup( 'env', 'HOSTNAME') }}"
    register: pods

  - name: Print pod name
    debug:
      msg: "{{ pods.resources[0].metadata.name }}"

fail モジュールを使用して、ゼロ以外の終了ステータスが正常に生成されない場合にゼロ以外の終了ステータスを生成し、フックの成功または失敗が検出されるようにします。フックはジョブとして実行され、フックの成功または失敗のステータスはジョブコンテナーの終了ステータスに基づいて表示されます。

fail モジュールの例

- hosts: localhost
  gather_facts: false
  tasks:
  - name: Set a boolean
    set_fact:
      do_fail: true

  - name: "fail"
    fail:
      msg: "Cause a failure"
    when: do_fail

8.3.1.2. 環境変数

MigPlan CR 名および移行 namespace は環境変数としてフックコンテナーに渡されます。これらの変数は lookup プラグインを使用してアクセスされます。

環境変数の例

- hosts: localhost
  gather_facts: false
  tasks:
  - set_fact:
      namespaces: "{{ (lookup( 'env', 'migration_namespaces')).split(',') }}"

  - debug:
      msg: "{{ item }}"
    with_items: "{{ namespaces }}"

  - debug:
      msg: "{{ lookup( 'env', 'migplan_name') }}"

8.4. 移行計画のオプション

MigPlan カスタムリソース(CR)のコンポーネントを除外、編集、およびマップできます。

8.4.1. リソースの除外

移行についてのリソース負荷を減らしたり、別のツールでイメージや PV を移行するために、MTC (Migration Toolkit for Containers) からイメージストリーム、永続ボリューム (PV)、またはサブスクリプションなどのリソースを除外することができます。

デフォルトで、MTC は移行からサービスカタログリソースおよび Operator Lifecycle Manager (OLM) リソースを除外します。これらのリソースはサービスカタログ API グループおよび OLM API グループの一部ですが、現時点でこれらは移行についてサポートされません。

手順

  1. MigrationController カスタムリソースマニフェストを編集します。

    $ oc edit migrationcontroller <migration_controller> -n openshift-migration
  2. spec セクションの更新は、特定リソースを除外するためにパラメーターを追加するか、または独自の除外パラメーターがない場合はリソースを 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
      ...
      excluded_resources: 3
      - imagetags
      - templateinstances
      - clusterserviceversions
      - packagemanifests
      - subscriptions
      - servicebrokers
      - servicebindings
      - serviceclasses
      - serviceinstances
      - serviceplans
      - operatorgroups
      - events
      - events.events.k8s.io
    1
    disable_image_migration: true を追加して、移行からイメージストリームを除外します。excluded_resources パラメーターは編集しないでください。imagestreams は、 MigrationController Pod の再起動時に excluded_resources に追加されます。
    2
    disable_pv_migration: true を追加して、移行計画から PV を除外します。excluded_resources パラメーターは編集しないでください。persistentvolumes および persistentvolumeclaims は、MigrationController Pod の再起動時に excluded_resources に追加されます。PV 移行を無効にすると、移行計画の作成時に PV 検出も無効にできます。
    3
    OpenShift Container Platform リソースを 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:
          imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

8.4.2. 名前空間のマッピング

MigPlan カスタムリソース (CR) で namespace をマッピングした場合には、namespace の UID および GID の範囲が移行時にコピーされるため、namespace が移行元または移行先ホストで複製されないようにする必要があります。

同じ宛先 namespace にマッピングされた 2 つのソース namespace

spec:
  namespaces:
    - namespace_2
    - namespace_1:namespace_2

ソース namespace を同じ名前の namespace にマップする場合には、マッピングを作成する必要はありません。デフォルトでは、ソースの namespace とターゲット namespace の名前は同じです。

誤った namespace マッピング

spec:
  namespaces:
    - namespace_1:namespace_1

正しい namespace リファレンス

spec:
  namespaces:
    - namespace_1

8.4.3. Persistent Volume Claim (永続ボリューム要求、PVC) の除外

移行しない PVC を除外して、状態移行用に永続ボリューム要求(PVC)を選択します。永続ボリューム(PV)の検出後に MigPlan カスタムリソース(CR)の spec.persistentVolumes.pvc.selection.action パラメーターを設定して PVC を除外します。

前提条件

  • MigPlan CR が Ready 状態にある。

手順

  • spec.persistentVolumes.pvc.selection.action パラメーターを MigPlan CR に追加し、それを skip に設定します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
    ...
        selection:
          action: skip

8.4.4. 永続ボリューム要求 (PVC) のマッピング

永続ボリューム(PV)データをソースクラスターから、PVC をマッピングすることで、MigPlan CR の宛先クラスターですでにプロビジョニングされている永続ボリューム要求(PVC)に移行できます。このマッピングにより、移行したアプリケーションの宛先 PVC がソース PVC と同期されます。

PV の検出後に MigPlan カスタムリソース(CR)の spec.persistentVolumes.pvc.name パラメーターを更新して PVC をマップします。

前提条件

  • MigPlan CR が Ready 状態にある。

手順

  • MigPlan CR の spec.persistentVolumes.pvc.name パラメーターを更新します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
    ...
      persistentVolumes:
      - capacity: 10Gi
        name: <pv_name>
        pvc:
          name: <source_pvc>:<destination_pvc> 1
    1
    ソースクラスターに PVC を指定し、宛先クラスターで PVC を指定します。宛先 PVC が存在しない場合、これは作成されます。このマッピングを使用して、移行時に PVC 名を変更できます。

8.4.5. 永続ボリューム属性の編集

MigPlanカスタムリソース(CR)を作成すると、MigrationControllerCR はパーシステントボリューム(PV)を検出します。 MigPlanCR にspec.persistentVolumesブロックとstatus.destStorageClassesブロックが追加されました。

spec.persistentVolumes.selectionブロックの値を編集することができます。 spec.persistentVolumes.selectionブロックの外側で値を変更すると、MigPlanCR がMigrationControllerCR によってリコンサイルされたときに、値が上書きされます。

注記

spec.persistentVolumes.selection.storageClassパラメータのデフォルト値は、次のようなロジックで決定されます。

  1. ソースクラスターPVがGlusterまたはNFSの場合、デフォルトはaccessModecephfsの場合です。アクセスモードがReadWriteManyの場合はcephfs、アクセスモードがReadWriteOnceの場合はcephrbdです。ReadWriteOnceです。
  2. PVがGlusterでもNFSでもない場合、または cephfscephrbdが利用できない場合、デフォルトは同じプロビジョナーのストレージクラスです。
  3. 同じプロビジョナーのストレージクラスが利用できない場合、デフォルトはデスティネーションクラスタのデフォルトストレージクラスとなります。

MigPlanCR のstatus.destStorageClassesブロックで、storageClassの値を任意の名前のパラメータの値に変更できます。

storageClassの値が空の場合、移行後の PV にはストレージクラスが設定されません。このオプションは、PVをデスティネーションクラスター上のNFSボリュームに移動させたい場合などに適しています。

前提条件

  • MigPlan CR が Ready 状態にある。

手順

  • MigPlanCR のspec.persistentVolumes.selectionの値を編集します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migplan>
      namespace: openshift-migration
    spec:
      persistentVolumes:
      - capacity: 10Gi
        name: pvc-095a6559-b27f-11eb-b27f-021bddcaf6e4
        proposedCapacity: 10Gi
        pvc:
          accessModes:
          - ReadWriteMany
          hasReference: true
          name: mysql
          namespace: mysql-persistent
        selection:
          action: <copy> 1
          copyMethod: <filesystem> 2
          verify: true 3
          storageClass: <gp2> 4
          accessMode: <ReadWriteMany> 5
        storageClass: cephfs
    1
    許可された値は、movecopyskipです。1つのアクションしかサポートされていない場合、デフォルト値はサポートされているアクションになります。複数のアクションがサポートされている場合、デフォルト値はcopyです。
    2
    許可された値はsnapshotfilesystemです。既定値はfilesystem です。
    3
    MTCウェブコンソールでファイルシステムコピーの検証オプションを選択した場合、検証パラメータが表示されます。 falseに設定することができます。
    4
    MigPlanCR のstatus.destStorageClassesブロックで、デフォルト値を任意の名前のパラメータの値に変更できます。値が指定されていない場合、移行後のPVにはストレージクラスが設定されません。
    5
    許可される値は ReadWriteOnce および ReadWriteMany です。この値が指定されていない場合、デフォルトではソースクラスターPVCのアクセスモードが適用されます。アクセスモードの編集は、MigPlanCRでのみ可能です。MTCウェブコンソールを使って編集することはできません。
PV属性を編集するための追加リソース

8.4.6. Kubernetes オブジェクトの移行

アプリケーションの状態を継続する Kubernetes オブジェクトの 1 回限り移行を実行できます。

注記

移行後に、MigPlan CR の closed パラメーターは true に設定されます。この MigPlan CR の別の MigMigration CR を作成することはできません。

以下のいずれかのオプションを使用して、Kubernetes オブジェクトを MigPlan CR に追加します。

  • Kubernetes オブジェクトを includedResources セクションに追加します。
  • labelSelector パラメーターを使用してラベルが付けられた Kubernetes オブジェクトを参照します。
  • Kubernetes オブジェクトを includedResources セクションに追加して、labelSelectorパラメーターでフィルターします。たとえば、ラベル app: frontendSecret および ConfigMap リソースなどです。

手順

  • MigPlan CR を更新します。

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

8.5. 移行コントローラーオプション

移行計画の制限を編集したり、永続ボリュームのサイズ変更を有効にしたり、大規模な移行およびパフォーマンスを向上させる MigrationController カスタムリソース(CR)でキャッシュされた Kubernetes クライアントを有効にすることもできます。

8.5.1. 大規模な移行についての制限の引き上げ

MTC (Migration Toolkit for Containers) を使用した大規模な移行の場合には、移行オブジェクトおよびコンテナーリソースで制限を引き上げることができます。

重要

実稼働環境で移行を実行する前に、これらの変更をテストする必要があります。

手順

  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 コンソールには移行計画を保存する際に警告メッセージが表示されます。

8.5.2. ボリュームの直接移行での永続ボリュームサイズ変更の有効化

ボリュームの直接移行用に永続ボリューム (PV) のサイズ変更を有効にして、宛先クラスターでディスク領域が不足しないようにします。

PV のディスク使用量が設定されたレベルに達すると、MigrationController カスタムリソース (CR) は永続ボリューム要求 (PVC) で必要なストレージ容量と実際のプロビジョニング容量とを比較します。次に、この CR は宛先クラスターに必要な領域を計算します。

pv_resizing_threshold パラメーターは、PV のサイズ変更が使用されるタイミングを決定します。デフォルトのしきい値は 3% です。つまり、PV のディスク使用量が 97% を超える場合に PV のサイズ変更が発生します。PV のサイズ変更はディスク使用量が低いレベルで実行されるように、このしきい値を引き上げることができます。

PVC の容量は以下の基準に従って計算されます。

  • PVC の要求されるストレージ容量 (spec.resources.requests.storage) が実際のプロビジョニングされた容量 (status.capacity.storage) と等しくない場合には、より大きい値が使用されます。
  • PV が PVC 経由でプロビジョニングされ、その後に変更されて PV および PVC の容量が一致しなくなった場合に、より大きい値が使用されます。

前提条件

  • PVC は、MigrationController CR がコマンドを実行できるように実行中の Pod 1 つ以上に割り当てる必要があります。

手順

  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)

8.5.3. キャッシュされた Kubernetes クライアントの有効化

移行時にパフォーマンスを向上させるために、キャッシュされた Kubernetes クライアントを MigrationController カスタムリソース (CR) で有効にできます。パフォーマンスに関する利点は、異なるリージョンのクラスター間で移行する場合や、ネットワークレイテンシーが大きい場合の移行時に発揮されます。

注記

委譲されたタスク (例: 直接ボリューム移行または Velero バックアップおよび復元用の Rsync バックアップ) では、キャッシュされたクライアントのパフォーマンスは向上されません。

MigrationController CR は MigCluster CR との対話に必要なすべての API リソースをキャッシュするため、キャッシュされたクライアントには追加のメモリーが必要です。通常 API サーバーに送信される要求は、代わりにキャッシュに転送されます。このキャッシュは API サーバーで更新がないかを監視します。

キャッシュされたクライアントを有効にした後に OOMKilled エラーが発生すると、MigrationController CR のメモリー制限および要求を増やすことができます。

手順

  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>}]'

第9章 トラブルシューティング

このセクションでは、MTC (Migration Toolkit for Containers) のトラブルシューティングに使用するリソースについて説明します。

既知の問題については、MTC リリースノート を参照してください。

9.1. MTC ワークフロー

MTC (Migration Toolkit for Containers) の Web コンソールまたは Kubernetes API を使用して、Kubernetes リソース、永続ボリュームデータ、および内部コンテナーイメージを OpenShift Container Platform 4.8 に移行できます。

MTC は以下のリソースを移行します。

  • 移行計画に指定される namespace。
  • namespace スコープのリソース: MTC が namespace を移行する場合、サービスや Pod などのその namespace に関連付けられるすべてのオブジェクトおよびリソースを移行します。さらに、namespace に存在するものの、クラスターレベルに存在しないリソースがクラスターレベルに存在するリソースに依存する場合、MTC は両方のリソースを移行します。

    たとえば、SCC (Security Context Constraints) はクラスターレベルに存在するリソースであり、サービスアカウント (SA) は namespace レベルに存在するリソースです。SA が MTC が移行する namespace に存在する場合、MTC は SA にリンクされている SCC を自動的に識別し、それらの SCC も移行します。同様に、MTC は namespace の永続ボリュームにリンクされた永続ボリューム要求 (PVC)を移行します。

    注記

    クラスタースコープのリソースは、リソースによっては手動で移行する必要がある場合があります。

  • カスタムリソース (CR) およびカスタムリソース定義 (CRD): MTC は、namespace レベルで CR および CRD を自動的に移行します。

MTC Web コンソールを使用してアプリケーションを移行するには、以下の手順が必要です。

  1. すべてのクラスターに MTC (Migration Toolkit for Containers Operator) をインストールします。

    インターネットアクセスが制限されているか、またはインターネットアクセスのない制限された環境で Migration Toolkit for Containers Operator をインストールできます。ソースおよびターゲットクラスターは、相互に対するネットワークアクセスおよびミラーレジストリーへのネットワークアクセスがなければなりません。

  2. MTC がデータ移行に使用する中間オブジェクトストレージであるレプリケーションリポジトリーを設定します。

    ソースおよびターゲットクラスターには、移行時にレプリケーションリポジトリーへのネットワークアクセスがなければなりません。制限された環境では、Multi-Cloud Object Gateway (MCG) を使用できます。プロキシーサーバーを使用している場合は、レプリケーションリポジトリーとクラスター間のネットワークトラフィックを許可するように設定する必要があります。

  3. ソースクラスターを MTC の Web コンソールに追加します。
  4. レプリケーションリポジトリーを MTC の Web コンソールに追加します。
  5. 以下のデータ移行オプションのいずれかを使用して、移行計画を作成します。

    • Copy: MTC は、データをソースクラスターからレプリケーションリポジトリーにコピーし、レプリケーションリポジトリーからターゲットクラスターにコピーします。

      注記

      イメージの直接移行またはボリュームの直接移行を使用している場合、イメージまたはボリュームはソースクラスターからターゲットクラスターに直接コピーされます。

      migration PV copy
    • Move: MTC は、ソースクラスターからリモートボリューム (例: NFS) をアンマウントし、リモートボリュームをポイントするターゲットクラスターで PV リソースを作成し、その後にリモートボリュームをターゲットクラスターにマウントします。ターゲットクラスターで実行されているアプリケーションは、ソースクラスターが使用していたものと同じリモートボリュームを使用します。リモートボリュームは、ソースクラスターおよびターゲットクラスターからアクセスできる必要があります。

      注記

      レプリケーションリポジトリーはこの図には表示されていませんが、これは移行に必要です。

      migration PV move
  6. 以下のオプションのいずれかを使用して、移行計画を実行します。

    • 段階 移行は、アプリケーションを停止せずにデータをターゲットクラスターにコピーします。

      段階移行は複数回実行して、移行前にほとんどのデータがターゲットにコピーされるようにします。1 つ以上の段階移行を実行すると、カットオーバー移行の期間が短縮されます。

    • カットオーバー は、ソースクラスターでアプリケーションを停止し、リソースをターゲットクラスターに移動します。

      オプション:Halt transactions on the source cluster during migrationのチェックボックスのチェックを解除できます。

OCP 3 to 4 App migration

MTC カスタムリソースについて

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

migration architecture diagram

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 の使用)

9.2. MTC カスタムリソースマニフェスト

MTC (Migration Toolkit for Containers) は以下のカスタムリソース (CR) マニフェストを使用して、アプリケーションを移行します。

9.2.1. DirectImageMigration

DirectImageMigration CR はイメージをソースクラスターから宛先クラスターに直接コピーします。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  namespaces: 1
    - <source_namespace_1>
    - <source_namespace_2>:<destination_namespace_3> 2
1
移行するイメージが含まれる namespace を 1 つ以上指定します。デフォルトでは、宛先の namespace の名前はソース namespace と同じになります。
2
別の名前で宛先 namespace にマップされるソース namespace。

9.2.2. DirectImageStreamMigration

DirectImageStreamMigration CR はイメージストリーム参照をソースクラスターから宛先クラスターに直接コピーします。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_image_stream_migration>
spec:
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream>
    namespace: <source_image_stream_namespace>
  destNamespace: <destination_image_stream_namespace>

9.2.3. DirectVolumeMigration

DirectVolumeMigration CR は永続ボリューム (PV) をソースクラスターから宛先クラスターに直接コピーします。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigration
metadata:
  name: <direct_volume_migration>
  namespace: openshift-migration
spec:
  createDestinationNamespaces: false 1
  deleteProgressReportingCRs: false 2
  destMigClusterRef:
    name: <host_cluster> 3
    namespace: openshift-migration
  persistentVolumeClaims:
  - name: <pvc> 4
    namespace: <pvc_namespace>
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
1
true に設定して、宛先クラスターの PV の namespace を作成します。
2
true に設定して移行後に DirectVolumeMigrationProgress CR を削除します。デフォルト値は false です。これにより、DirectVolumeMigrationProgress CR はトラブルシューティング用に保持されます。
3
宛先クラスターがホストクラスターではない場合は、クラスター名を更新します。
4
移行する PVC を 1 つ以上指定します。

9.2.4. DirectVolumeMigrationProgress

DirectVolumeMigrationProgress CR は、DirectVolumeMigration CR の進捗を表示します。

apiVersion: migration.openshift.io/v1alpha1
kind: DirectVolumeMigrationProgress
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <direct_volume_migration_progress>
spec:
  clusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  podRef:
    name: <rsync_pod>
    namespace: openshift-migration

9.2.5. MigAnalytic

MigAnalytic CR は、関連付けられた MigPlan CR から、イメージの数、Kubernetes リソースおよび 永続ボリューム (PV) 容量を収集します。

収集するデータを設定できます。

apiVersion: migration.openshift.io/v1alpha1
kind: MigAnalytic
metadata:
  annotations:
    migplan: <migplan>
  name: <miganalytic>
  namespace: openshift-migration
  labels:
    migplan: <migplan>
spec:
  analyzeImageCount: true 1
  analyzeK8SResources: true 2
  analyzePVCapacity: true 3
  listImages: false 4
  listImagesLimit: 50 5
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
オプション: イメージの数を返します。
2
オプション: Kubernetes リソースの番号、種類、および API バージョンを返します。
3
オプション: PV 容量を返します。
4
イメージ名の一覧を返します。デフォルトは false で、出力が過剰に長くなることはありません。
5
オプション: listImagestrue の場合、返されるイメージ名の最大数を指定します。

9.2.6. MigCluster

MigCluster CR は、ホスト、ローカル、またはリモートクラスターを定義します。

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <host_cluster> 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
# The 'azureResourceGroup' parameter is relevant only for Microsoft Azure.
  azureResourceGroup: <azure_resource_group> 3
  caBundle: <ca_bundle_base64> 4
  insecure: false 5
  refresh: false 6
# The 'restartRestic' parameter is relevant for a source cluster.
  restartRestic: true 7
# The following parameters are relevant for a remote cluster.
  exposedRegistryPath: <registry_route> 8
  url: <destination_cluster_url> 9
  serviceAccountSecretRef:
    name: <source_secret> 10
    namespace: openshift-config
1
migration-controller Pod がこのクラスターで実行されていない場合には、クラスター名を更新します。
2
true の場合、migration-controller Pod がこのクラスターで実行されます。
3
Microsoft Azure のみ: リソースグループを指定します。
4
オプション: 自己署名 CA 証明書の証明書バンドルを作成しており、insecureな パラメーターの値が false の場合、base64 でエンコードされた証明書バンドルを指定します。
5
SSL 検証を無効にするには true に設定します。
6
クラスターを検証するには、true に設定します。
7
ステージ Pod の作成後に Restic Pod をソースクラスターで再起動するには、true に設定します。
8
リモートクラスターおよび直接のイメージ移行のみ: 公開されるセキュアなレジストリールートを指定します。
9
リモートクラスターのみ: URL を指定します。
10
リモートクラスターのみ: Secret CR の名前を指定します。

9.2.7. MigHook

MigHook CR は、指定の移行段階でカスタムコードを実行する移行フックを定義します。最大 4 つの移行フックを作成できます。各フックは異なる移行フェーズで実行されます。

フック名、ランタイム期間、カスタムイメージ、およびフックが実行されるクラスターを設定できます。

フックの移行フェーズおよび namespace は MigPlan CR で設定されます。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <mighook> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 1800 3
  custom: false 4
  image: <hook_image> 5
  playbook: <ansible_playbook_base64> 6
  targetCluster: source 7
1
オプション: このパラメーターの値に一意のハッシュが追加され、それぞれの移行フックに一意の名前が追加されます。name パラメーターの値を指定する必要はありません。
2
generateName パラメーターを指定しない場合は、移行フック名を指定します。
3
オプション: フックを実行できる最大秒数を指定します。デフォルトは 1800 です。
4
true の場合、フックはカスタムイメージです。カスタムイメージには Ansible を含めることも、これを別のプログラミング言語で記述することもできます。
5
カスタムイメージ (例: quay.io/konveyor/hook-runner:latest)を指定します。customtrue の場合に必要です。
6
base64 でエンコードされた Ansible Playbook。customfalse の場合に必要です。
7
フックの実行先のクラスターを指定します。有効な値は ソース または 宛先 です。

9.2.8. MigMigration

MigMigration CR は MigPlan CR を実行します。

Migmigration CR はステージまたは増分移行を実行し、進行中の移行をキャンセルしたり、完了した移行をロールバックしたりするように設定できます。

apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migmigration>
  namespace: openshift-migration
spec:
  canceled: false 1
  rollback: false 2
  stage: false 3
  quiescePods: true 4
  keepAnnotations: true 5
  verify: false 6
  migPlanRef:
    name: <migplan>
    namespace: openshift-migration
1
実行中の移行を取り消すには、true に設定します。
2
完了した移行をロールバックするには、true に設定します。
3
段階移行を実行するには、true に設定します。データが増分的にコピーされ、ソースクラスター上の Pod は停止しません。
4
移行時にアプリケーションを停止するには、true に設定します。ソースクラスターの Pod は、Backup ステージの後に 0 にスケーリングされます。
5
移行中に適用されるラベルとアノテーションは保持するには、true を設定します。
6
宛先クラスターで移行される Pod のステータスをチェックして、Running 状態にない Pod の名前を返すには、true に設定します。

9.2.9. MigPlan

MigPlan CR は移行計画のパラメーターを定義します。

宛先 namespace、フックフェーズ、および直接または間接的な移行を設定できます。

注記

デフォルトで、宛先 namespace の名前はソース namespace と同じになります。別の宛先の namespace を設定した場合には、UID および GID の範囲が移行時にコピーされるため、namespace が移行元または移行先ホストで複製されないようにする必要があります。

apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migplan>
  namespace: openshift-migration
spec:
  closed: false 1
  srcMigClusterRef:
    name: <source_cluster>
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster>
    namespace: openshift-migration
  hooks: 2
    - executionNamespace: <namespace> 3
      phase: <migration_phase> 4
      reference:
        name: <hook> 5
        namespace: <hook_namespace> 6
      serviceAccount: <service_account> 7
  indirectImageMigration: true 8
  indirectVolumeMigration: false 9
  migStorageRef:
    name: <migstorage>
    namespace: openshift-migration
  namespaces:
    - <source_namespace_1> 10
    - <source_namespace_2>
    - <source_namespace_3>:<destination_namespace_4> 11
  refresh: false  12
1
true の場合、移行が完了します。この MigPlan CR の別の MigMigration CR を作成することはできません。
2
オプション: 最大 4 つの移行フックを指定できます。各フックは異なる移行フェーズで実行される必要があります。
3
オプション: フックが実行される namespace を指定します。
4
オプション: フックが実行される移行フェーズを指定します。1 つのフックを 1 つのフェーズに割り当てることができます。有効な値は、PreBackupPostBackupPreRestore、および PostRestore です。
5
オプション: MigHook CR の名前を指定します。
6
オプション: MigHook CR の namespace を指定します。
7
オプション: cluster-admin 権限でサービスアカウントを指定します。
8
false の場合、直接的なイメージ移行が無効にされます。イメージはソースクラスターからレプリケーションリポジトリーに、レプリケーションリポジトリーから宛先クラスターにコピーされます。
9
false の場合、直接的なボリューム移行が無効にされます。PV はソースクラスターからレプリケーションリポジトリーに、レプリケーションリポジトリーから宛先クラスターにコピーされます。
10
namespace を 1 つ以上指定します。ソース namespace のみを指定する場合には、宛先 namespace は同じになります。
11
宛先 namespace が異なる場合には、宛先 namespace を指定します。
12
true の場合、MigPlan CR が検証されます。

9.2.10. MigStorage

MigStorage CR はレプリケーションリポジトリーのオブジェクトストレージを記述します。

Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Storage、Multi-Cloud Object Gateway、および汎用 S3 互換クラウドストレージがサポート対象です。

AWS およびスナップショットのコピー方法には追加のパラメーターがあります。

apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <migstorage>
  namespace: openshift-migration
spec:
  backupStorageProvider: <backup_storage_provider> 1
  volumeSnapshotProvider: <snapshot_storage_provider> 2
  backupStorageConfig:
    awsBucketName: <bucket> 3
    awsRegion: <region> 4
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 5
    awsKmsKeyId: <key_id> 6
    awsPublicUrl: <public_url> 7
    awsSignatureVersion: <signature_version> 8
  volumeSnapshotConfig:
    awsRegion: <region> 9
    credsSecretRef:
      namespace: openshift-config
      name: <storage_secret> 10
  refresh: false 11
1
ストレージプロバイダーを指定します。
2
スナップショットのコピー方法のみ: ストレージプロバイダーを指定します。
3
AWS のみ: バケット名を指定します。
4
AWS のみ: バケットリージョン (例: us-east-1) を指定します。
5
ストレージ用に作成した Secret CR の名前を指定します。
6
AWS のみ: AWS Key Management Service を使用している場合は、キーの一意の識別子を指定します。
7
AWS のみ: AWS バケットへのパブリックアクセスを付与する場合は、バケット URL を指定します。
8
AWS のみ: バケットに対する要求の認証に使用する AWS 署名バージョン (例: 4) を指定します。
9
スナップショットを使用したコピー方法のみ: クラスターの地理的なリージョンを指定します。
10
スナップショットを使用したコピー方法のみ: ストレージ用に作成した Secret CR の名前を指定します。
11
クラスターを検証するには、true に設定します。

9.3. ログおよびデバッグツール

本セクションでは、トラブルシューティングに使用できるログおよびデバッグツールについて説明します。

9.3.1. 移行計画リソースの表示

移行計画リソースを表示して、実行中の移行を監視するか、MTC の Web コンソールおよびコマンドラインインターフェース (CLI) を使用して失敗した移行のトラブルシューティングを行うことができます。

手順

  1. MTC Web コンソールで、Migration plans をクリックします。
  2. 移行計画の横にある Migrations 番号をクリックし、Migrations ページを表示します。
  3. 移行をクリックして、移行の詳細を表示します。
  4. Migration resources を展開して、移行リソースおよびそれらのステータスをツリービューで表示します。

    注記

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

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

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

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

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

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

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

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

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

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

9.3.2. 移行計画ログの表示

移行計画の集計ログを表示できます。MTC の Web コンソールを使用して、コマンドをクリップボードにコピーしてから、コマンドラインインターフェース (CLI) からコマンドを実行します。

このコマンドは、以下の Pod に関するフィルターされたログを表示します。

  • Migration Controller
  • Velero
  • Restic
  • Rsync
  • Stunnel
  • Registry

手順

  1. MTC Web コンソールで、Migration plans をクリックします。
  2. 移行計画の横にある Migrations 番号をクリックします。
  3. View logs をクリックします。
  4. コピーアイコンをクリックして、oc logs コマンドをクリップボードにコピーします。
  5. 関連するクラスターにログインし、CLI でコマンドを入力します。

    移行契約の集約ログが表示されます。

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

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

手順

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

9.3.4. パフォーマンスメトリックへのアクセス

MigrationController カスタムリソース (CR)はメトリクスを記録し、それらをクラスター上のモニタリングストレージにプルします。Prometheus Query Language (PromQL)を使用してメトリクスをクエリーし、移行のパフォーマンス問題を診断できます。すべてのメトリクスは、Migration コントローラー Pod の再起動時にリセットされます。

パフォーマンスメトリックにアクセスし、OpenShift Container Platform Web コンソールを使用してクエリーを実行できます。

手順

  1. OpenShift Container Platform Web コンソールで、MonitoringMetrics をクリックします。
  2. PromQL クエリーを入力し、表示する期間を選択し、Run Queries をクリックします。

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

9.3.4.1. 提供されるメトリクス

MigrationController カスタムリソース (CR)は、MigMigration CR 数およびその API 要求のメトリクスを提供します。

9.3.4.1.1. cam_app_workload_migrations

このメトリクスは、一定期間の MigMigration CR の数です。mtc_client_request_count および mtc_client_request_elapsed メトリックと一緒に表示して、APIリクエスト情報を移行ステータスの変更と照合するのに役立ちます。このメトリクスは Telemetry に含まれます。

表9.1 cam_app_workload_migrations メトリクス

クエリー可能なラベル名サンプルラベル値ラベルの説明

status

runningidlefailedcompleted

MigMigration CR のステータス

type

stage、final

MigMigration CR のタイプ

9.3.4.1.2. mtc_client_request_count

このメトリクスは、MigrationController が発行する Kubernetes API 要求の累積数です。これは Telemetry に含まれていません。

表9.2 mtc_client_request_count metric

クエリー可能なラベル名サンプルラベル値ラベルの説明

cluster

https://migcluster-url:443

要求が発行されたクラスター

component

MigPlanMigCluster

要求を発行したサブコントローラー API

function

(*ReconcileMigPlan).Reconcile

要求が発行された関数

kind

SecretListDeployment

要求が発行された Kubernetes の種類

9.3.4.1.3. mtc_client_request_elapsed

このメトリクスは、MigrationController が発行する Kubernetes API 要求の累積レイテンシー(ミリ秒単位)です。これは Telemetry に含まれていません。

表9.3 mtc_client_request_elapsed metric

クエリー可能なラベル名サンプルラベル値ラベルの説明

cluster

https://cluster-url.com:443

要求が発行されたクラスター

component

migplanmigcluster

要求を発行したサブコントローラー API

function

(*ReconcileMigPlan).Reconcile

要求が発行された関数

kind

SecretListDeployment

要求が発行された Kubernetes リソース

9.3.4.1.4. 有用なクエリー

この表には、パフォーマンスの監視に使用できる便利なクエリーが記載されています。

表9.4 有用なクエリー

クエリー説明

mtc_client_request_count

発行した API 要求の数。要求タイプ別でソート

sum(mtc_client_request_count)

発行された API 要求の合計数

mtc_client_request_elapsed

要求タイプ別にソートされた API 要求のレイテンシー

sum(mtc_client_request_elapsed)

API 要求の合計レイテンシー

sum(mtc_client_request_elapsed) / sum(mtc_client_request_count)

API 要求の平均レイテンシー

mtc_client_request_elapsed / mtc_client_request_count

要求タイプ別にソートされた API 要求の平均レイテンシー

cam_app_workload_migrations{status="running"} * 100

実行中の移行の数。要求数とともに簡単に表示できるように 100 で乗算されます。

9.3.5. must-gather ツールの使用

must-gather ツールを使用して、MTC カスタムリソースのログ、メトリクス、および情報を収集できます。

must-gather データはすべてのカスタマーケースに割り当てられる必要があります。

1 時間または 24 時間のデータを収集し、Prometheus コンソールでデータを表示できます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインする必要があります。
  • OpenShift CLI (oc) がインストールされている必要があります。

手順

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

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

      $ oc adm must-gather --image=registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8:v1.6

      データは /must-gather/must-gather.tar.gz として保存されます。このファイルを Red Hat カスタマーポータル で作成したサポートケースにアップロードすることができます。

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

      $ oc adm must-gather --image= \
        registry.redhat.io/rhmtc/openshift-migration-must-gather-rhel8: \
        v1.6 -- /usr/bin/gather_metrics_dump

      この操作には長時間かかる場合があります。データは /must-gather/metrics/prom_data.tar.gz として保存されます。このファイルは Prometheus コンソールで表示できます。

Prometheus コンソールでデータを表示するには、以下を実行します。

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

    $ make prometheus-run

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

    出力

    Started Prometheus on http://localhost:9090

  2. Web ブラウザーを起動して URL に移動し、Prometheus Web コンソールを使用してデータを表示します。
  3. データを確認した後に、Prometheus インスタンスおよびデータを削除します。

    $ make prometheus-cleanup

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

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

9.3.6.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 を指定できます。

9.3.6.2. Help コマンド

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

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

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

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

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

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 は、部分的に失敗した移行の原因を示します。

9.3.8. トラブルシューティング向けの MTC カスタムリソースの使用

以下の MTC (Migration Toolkit for Containers) カスタムリソース (CR) を確認し、失敗した移行のトラブルシューティングを行うことができます。

  • MigCluster
  • MigStorage
  • MigPlan
  • BackupStorageLocation

    BackupStorageLocation CR には、CR を作成した MTC インスタンスを識別するための migrationcontroller ラベルが含まれます。

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • VolumeSnapshotLocation

    VolumeSnapshotLocation CR には、CR を作成した MTC インスタンスを特定するための migrationcontroller ラベルが含まれます。

        labels:
          migrationcontroller: ebe13bee-c803-47d0-a9e9-83f380328b93
  • MigMigration
  • Backup

    MTC は、移行された永続ボリューム (PV) の回収ポリシーをターゲットクラスターで Retain に変更します。Backup CR には、元の回収ポリシーを示す openshift.io/orig-reclaim-policy アノテーションが含まれます。移行した PV の回収ポリシーを手動で復元できます。

  • Restore

手順

  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
    openshift.io/orig-reclaim-policy: delete
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

Kubernetes リソースを記述する Velero CR #2 の出力例

apiVersion: velero.io/v1
kind: Restore
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.90.187:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-36f54ca7-c925-11e9-825a-06fa9fb68c88
  creationTimestamp: "2019-08-28T00:09:49Z"
  generateName: e13a1b60-c927-11e9-9555-d129df7f3b96-
  generation: 3
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: e18252c9-c927-11e9-825a-06fa9fb68c88
    migration-final-restore: e18252c9-c927-11e9-825a-06fa9fb68c88
  name: e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  namespace: openshift-migration
  resourceVersion: "82329"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/restores/e13a1b60-c927-11e9-9555-d129df7f3b96-gb8nx
  uid: 26983ec0-c928-11e9-825a-06fa9fb68c88
spec:
  backupName: e13a1b60-c927-11e9-9555-d129df7f3b96-sz24f
  excludedNamespaces: null
  excludedResources:
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  includedNamespaces: null
  includedResources: null
  namespaceMapping: null
  restorePVs: true
status:
  errors: 0
  failureReason: ""
  phase: Completed
  validationErrors: null
  warnings: 15

9.4. 一般的な問題および懸念事項

このセクションでは、移行時の問題を引き起こす可能性のある懸念事項および一般的な問題について説明します。

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

ボリュームの直接移行が完了しない場合、ターゲットクラスターにソースクラスターと同じ 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> -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. 移行計画を再度実行します。

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

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

9.4.2.1. MTC コンソールへの初回アクセス時に CA 証明書エラーが表示されます。

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

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

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

9.4.2.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」を参照してください。

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

  • ブラウザーの Web インスペクターで MTC コンソールの Web ページを検査します。
  • Migration UI Pod ログでエラーの有無を確認します。

9.4.2.3. 不明な認証局エラーで署名された証明書

自己署名証明書を使用して MTC (Migration Toolkit for Containers) のクラスターまたはレプリケーションリポジトリーのセキュリティーを保護する場合、証明書の検証は Certificate signed by unknown authority というエラーメッセージを出して失敗する可能性があります。

カスタム CA 証明書バンドルファイルを作成し、クラスターまたはレプリケーションリポジトリーの追加時に MTC の Web コンソールでこれをアップロードできます。

手順

リモートエンドポイントから CA 証明書をダウンロードし、これを CA バンドルファイルとして保存します。

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1
  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
1
エンドポイントのホスト FQDN およびポートを指定します (例: api.my-cluster.example.com:6443)。
2
CA バンドルファイルの名前を指定します。

9.4.2.4. Velero Pod ログのバックアップストレージの場所についてのエラー

Velero Backup カスタムリソースに、存在しないバックアップストレージロケーション (BSL) が含まれる場合、Velero Pod ログには以下のエラーメッセージが表示される可能性があります。

$ oc logs <MigrationUI_Pod> -n openshift-migration

これらのエラーメッセージは無視できます。BSL がなくても、移行は失敗しません。

9.4.2.5. Velero Pod ログの Pod ボリュームバックアップのタイムアウトエラー

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

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=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 をクリックします。

9.4.2.6. MigMigration カスタムリソースの Restic 検証エラー

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

出力例

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

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

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

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

手順

  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>

9.4.2.7. root_squash を有効にして NFS ストレージから移行する場合の Restic パーミッションエラー

NFS ストレージからデータを移行していて、root_squash が有効にされている場合、Resticnfsnobody にマップされ、これには移行を実行するパーミッションがありません。Restic Pod ログには以下のエラーが表示されます。

出力例

backup=openshift-migration/<backup_id> controller=pod-volume-backup error="fork/exec /usr/bin/restic: permission denied" error.file="/go/src/github.com/vmware-tanzu/velero/pkg/controller/pod_volume_backup_controller.go:280" error.function="github.com/vmware-tanzu/velero/pkg/controller.(*podVolumeBackupController).processBackup" logSource="pkg/controller/pod_volume_backup_controller.go:280" name=<backup_id> namespace=openshift-migration

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

手順

  1. NFS ストレージで Restic の補助グループを作成します。
  2. NFS ディレクトリーに setgid ビットを設定して、グループの所有権が継承されるようにします。
  3. restic_supplemental_groups パラメーターを、ソースおよびターゲットクラスターの MigrationController CR マニフェストに追加します。

    spec:
      restic_supplemental_groups: <group_id> 1
    1
    補助グループ ID を指定します。
  4. Restic Pod が再起動し、変更が適用されるまで待機します。

9.5. 移行のロールバック

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

移行を手動でロールバックすることもできます

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

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

注記

以下のリソースは、直接的なボリューム移行 (DVM) の失敗後もデバッグ用に移行した名前空間に留まります。

  • 設定マップ (ソースおよび宛先クラスター)
  • Secret CR (ソースおよび宛先クラスター)
  • Rsync CR (ソースクラスター)

これらのリソースはロールバックには影響しません。これらは手動で削除できます。

後で同じ移行プランを正常に実行すると、失敗した移行のリソースが自動的に削除されます。

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

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

手順

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

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

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

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

9.5.2. コマンドラインインターフェースでの移行のロールバック

コマンドラインインターフェースで MigMigration カスタムリソース (CR) を作成して移行をロールバックできます。

注記

以下のリソースは、直接的なボリューム移行 (DVM) の失敗後もデバッグ用に移行した名前空間に留まります。

  • 設定マップ (ソースおよび宛先クラスター)
  • Secret CR (ソースおよび宛先クラスター)
  • Rsync 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: <migmigration>
      namespace: openshift-migration
    spec:
    ...
      rollback: true
    ...
      migPlanRef:
        name: <migplan> 1
        namespace: openshift-migration
    EOF
    1
    関連付けられた MigPlan CR の名前を指定します。
  2. MTC の Web コンソールで、移行したプロジェクトリソースがターゲットクラスターから削除されていることを確認します。
  3. 移行したプロジェクトリソースがソースクラスターにあり、アプリケーションが実行中であることを確認します。

9.5.3. 移行の手動ロールバック

stage Pod を削除して、アプリケーションの停止を解除することで、失敗した移行を手動でロールバックできます。

同じ移行プランを正常に実行すると、失敗した移行のリソースが自動的に削除されます。

注記

以下のリソースは、直接的なボリューム移行 (DVM) の失敗後も移行した名前空間に留まります。

  • 設定マップ (ソースおよび宛先クラスター)
  • Secret CR (ソースおよび宛先クラスター)
  • Rsync CR (ソースクラスター)

これらのリソースはロールバックには影響しません。これらは手動で削除できます。

手順

  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>

9.6. MTC のアンインストールおよびリソースの削除

MTC (Migration Toolkit for Containers) をアンインストールし、そのリソースを削除してクラスターをクリーンアップできます。

注記

velero CRD を削除すると、Velero がクラスターから削除されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている必要があります。

手順

  1. すべてのクラスターで MigrationController カスタムリソース (CR) を削除します。

    $ oc delete migrationcontroller <migration_controller>
  2. Operator Lifecycle Manager を使用して OpenShift Container Platform 4 の Migration Toolkit for Containers Operator をアンインストールします。
  3. 以下のコマンドを実行して、すべてのクラスターでクラスタースコープのリソースを削除します。

    • migration カスタムリソース定義 (CRDs):

      $ oc delete $(oc get crds -o name | grep 'migration.openshift.io')
    • Velero CRD:

      $ oc delete $(oc get crds -o name | grep 'velero')
    • migration クラスターロール:

      $ oc delete $(oc get clusterroles -o name | grep 'migration.openshift.io')
    • migration-operator クラスターロール:

      $ oc delete clusterrole migration-operator
    • Velero クラスターロール:

      $ oc delete $(oc get clusterroles -o name | grep 'velero')
    • migration クラスターのロールバインディング:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'migration.openshift.io')
    • migration-operator クラスターロールバインディング:

      $ oc delete clusterrolebindings migration-operator
    • Velero クラスターのロールバインディング:

      $ oc delete $(oc get clusterrolebindings -o name | grep 'velero')

MTC のアンインストールための追加のリソース