MTC (Migration Toolkit for Containers)

OpenShift Container Platform 4.5

OpenShift Container Platform 4 への移行

Red Hat OpenShift Documentation Team

概要

本書では、OpenShift Container Platform クラスターをバージョン 3 からバージョン 4 に移行する方法と、OpenShift Container Platform 4 の以前のリリースから最新バージョンへの移行方法について説明します。

第1章 OpenShift Container Platform 3 からの移行

1.1. OpenShift Container Platform 3 から 4 への移行について

OpenShift Container Platform 4 には、自己管理型の柔軟で自動化されたクラスターを実現する新規のテクノロジーおよび機能が含まれています。OpenShift Container Platform 4 クラスターがデプロイされ、管理される方法は OpenShift Container Platform 3 とは大きく異なります。

OpenShift Container Platform 3 から OpenShift Container Platform 4 に正常に移行するには、以下の情報を確認することが重要になります。

移行の計画
OpenShift Container Platform のバージョン 3 と 4 の相違点について確認します。移行の前に、ストレージ、ネットワーク、ロギング、セキュリティー、およびモニタリングに関する考慮事項について確認し、準備済みであることを確認します。
移行の実行
アプリケーションワークロードを移行するための MTC (Migration Toolkit for Containers) について確認し、これを使用します。

1.2. 移行の計画

OpenShift Container Platform 4.5 への移行を実行する前に、十分な時間を取って移行を適切に計画できるようにしてください。OpenShift Container Platform 4 ではアーキテクチャーの変更および拡張機能が導入されるため、OpenShift Container Platform 3 クラスターの管理に使用した手順は OpenShift Container Platform 4 で適用されない可能性があります。

注記

この計画ガイドでは、OpenShift Container Platform 3.11 から OpenShift Container Platform 4.5 への移行を前提としています。

本書では、最も重要な OpenShift Container Platform 3 と OpenShift Container Platform 4 の相違点 と、最も注目すべき 移行に関する考慮事項 についての概要を説明します。OpenShift Container Platform 4 クラスターの設定についての詳細は、OpenShift Container Platform ドキュメントの該当するセクションを参照してください。新規機能および他の重要な技術上の変更点についての詳細は、『OpenShift Container Platform 4.5 リリースノート』を参照してください。

既存の OpenShift Container Platform 3 クラスターを OpenShift Container Platform 4 にアップグレードすることはできません。新規の OpenShift Container Platform 4 インストールで開始する必要があります。コントロールプレーンの設定およびアプリケーションのワークロードの移行に役立つツールを使用できます。

1.2.1. OpenShift Container Platform 3 と OpenShift Container Platform 4 の比較

OpenShift Container Platform 3 では、管理者は Red Hat Enterprise Linux (RHEL) ホストを個別にデプロイし、その後に OpenShift Container Platform をこれらのホストにインストールし、クラスターを作成しました。管理者は、これらのホストを適切に設定し、更新を実行する必要があります。

OpenShift Container Platform 4 では、これまでとは大きく異なる方法で OpenShift Container Platform クラスターがデプロイされ、管理されるようになりました。OpenShift Container Platform 4 には、Operator、マシンセット、および Red Hat Enterprise Linux CoreOS (RHCOS) などの、クラスターの操作に対するコアとなる新たなテクノロジーおよび機能が含まれます。このテクノロジーの移行により、クラスターは管理者が以前に実行していた一部の機能を自己管理できるようになります。また、プラットフォームの安定性と一貫性を確保し、インストールおよびスケーリングを単純化することが可能です。

詳細は、『OpenShift Container Platform アーキテクチャー』を参照してください。

1.2.1.1. アーキテクチャーの違い

イミュータブルなインフラストラクチャー

OpenShift Container Platform 4 は、コンテナー化されたアプリケーションを実行するために設計された Red Hat Enterprise Linux CoreOS (RHCOS) を使用し、効率的なインストール、Operator ベースの管理、および単純化されたアップグレードを可能にします。RHCOS は、RHEL のようなカスタマイズ可能なオペレーティングシステムではなく、イミュータブルなコンテナーホストです。RHCOS により、OpenShift Container Platform 4 は基礎となるコンテナーホストのデプロイメントを管理し、自動化できます。RHCOS は OpenShift Container Platform の一部です。これは、すべてがコンテナー内で実行され、OpenShift Container Platform を使用してデプロイされることを意味します。

OpenShift Container Platform 4 では、コントロールプレーンノードは RHCOS を実行する必要があるため、コントロールプレーンのフルスタック自動化が維持されます。これにより、OpenShift Container Platform 3 よりも簡単に更新がロールアウトされ、アップグレードが簡単になります。

詳細は、『Red Hat Enterprise Linux CoreOS (RHCOS)』を参照してください。

Operator

Operator は、Kubernetes アプリケーションをパッケージ化し、デプロイし、管理する方法です。Operator は、ソフトウェアの他の部分を実行する際の運用上の複雑さを軽減します。Operator は環境を監視し、現在の状態を使用してリアルタイムの意思決定を行います。高度な Operator は、自動的にアップグレードし、障害に自動的に対応するように設計されています。

詳細は、「Operator について」を参照してください。

1.2.1.2. インストールおよび更新の違い

インストールプロセス

OpenShift Container Platform 3.11 をインストールするには、Red Hat Enterprise Linux (RHEL) ホストを準備し、クラスターが必要とする設定値をすべて設定してから、Ansible Playbook を実行してクラスターをインストールし、セットアップする必要がありました。

OpenShift Container Platform 4.5 では、OpenShift インストールプログラムを使用してクラスターに必要なリソースの最小セットを作成できます。クラスターの実行後に、Operator を使用してクラスターをさらに設定し、新規サービスをインストールすることができます。初回の起動後に、Red Hat Enterprise Linux CoreOS (RHCOS) システムは、OpenShift Container Platform クラスターで実行される Machine Config Operator (MCO) によって管理されます。

詳細は、「インストールプロセス」を参照してください。

Red Hat Enterprise Linux (RHEL) (RHEL) ワーカーマシンを OpenShift Container Platform 4.5 クラスターに追加する場合、Ansible Playbook を使用して、クラスターの実行後に RHEL ワーカーマシンを追加します。詳細は、「RHEL コンピュートマシンの OpenShift Container Platform クラスターへの追加」を参照してください。

インフラストラクチャーオプション

OpenShift Container Platform 3.11 では、ユーザーが準備し、維持するインフラストラクチャーにクラスターをインストールする必要があります。OpenShift Container Platform 4 では、独自のインフラストラクチャーを提供するだけでなく、OpenShift Container Platform インストールプログラムがプロビジョニングし、クラスターが維持するインフラストラクチャーにクラスターをデプロイするオプションを提供します。

詳細は、「OpenShift Container Platform インストールの概要」を参照してください。

クラスターのアップグレード

OpenShift Container Platform 3.11 では、Ansible Playbook を実行してクラスターをアップグレードします。OpenShift Container Platform 4.5 では、クラスターが、クラスターノードの Red Hat Enterprise Linux CoreOS (RHCOS) への更新を含む独自の更新を管理します。Web コンソールまたは OpenShift CLI から oc adm upgrade コマンドを使用することでクラスターを容易にアップグレードでき、Operator は自動的にアップグレードされます。OpenShift Container Platform 4.5 クラスターに RHEL ワーカーマシンがある場合、Ansible Playbook を引き続き実行してそれらのワーカーマシンをアップグレードする必要があります。

詳細は、『クラスターの更新』を参照してください。

1.2.2. 移行に関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4 への移行に影響を与える可能性のある変更やその他の考慮事項を確認します。

1.2.2.1. ストレージに関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.5 に移行する際に、以下のストレージの変更を考慮してください。

ローカルボリュームの永続ストレージ

ローカルストレージは、OpenShift Container Platform 4.5 ではローカルストレージ Operator を使用する場合にのみサポートされます。OpenShift Container Platform 3.11 のローカルプロビジョナーメソッドの使用はサポートされません。

詳細は、「ローカルボリュームを使用した永続ストレージ」を参照してください。

FlexVolume 永続ストレージ

FlexVolume プラグインの場所が OpenShift Container Platform 3.11 で変更になりました。OpenShift Container Platform 4.5 の新しい場所は /etc/kubernetes/kubelet-plugins/volume/exec です。割り当て可能な FlexVolume プラグインはサポートされなくなりました。

詳細は、「FlexVolume を使用した永続ストレージ」を参照してください。

Container Storage Interface (CSI) 永続ストレージ

Container Storage Interface (CSI) を使用した永続ストレージは OpenShift Container Platform 3.11 では テクノロジープレビューとして利用可能でした。OpenShift Container Platform 4.5 は CSI バージョン 1.1.0 を完全にサポートし、複数の CSI ドライバー に同梱されます。そのため、独自のドライバーをインストールできます。

詳細は、「Container Storage Interface (CSI) を使用した永続ストレージ」を参照してください。

Red Hat OpenShift Container Storage

OpenShift Container Platform 3.11 で使用できる Red Hat OpenShift Container Storage 3 は、バッキングストレージとして Red Hat Gluster Storage を使用します。

OpenShift Container Platform 4 で使用できる Red Hat OpenShift Container Storage 4 は、バッキングストレージとして Red Hat Ceph Storage を使用します。

詳細は、「Persistent storage using Red Hat OpenShift Container Storage」および「interoperability matrix」の記事を参照してください。

サポートされていない永続ストレージオプション

OpenShift Container Platform 3.11 の以下の永続ストレージオプションのサポートが OpenShift Container Platform 4.5 で変更になりました。

  • GlusterFS はサポート対象外になりました。
  • スタンドアロン製品としての CephFS がサポートされなくなりました。
  • スタンドアロン製品としての Ceph RBD がサポートされなくなりました。

OpenShift Container Platform 3.11 でこれらのいずれかを使用していた場合は、OpenShift Container Platform 4.5 で完全にサポートされる別の永続ストレージオプションを選択する必要があります。

詳細は、「永続ストレージについて」を参照してください。

1.2.2.2. ネットワークの考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.5 に移行する際に、考慮事項となる以下のネットワークの変更を確認してください。

ネットワーク分離モード

OpenShift Container Platform 3.11 では、ユーザーは ovn-multitenantを使用するように頻繁に切り替えましたが、デフォルトのネットワーク分離モードは ovs-subnetでした。OpenShift Container Platform 4.5 のデフォルトのネットワーク分離モードは、ネットワークポリシーによって制御されます。

OpenShift Container Platform 3.11 クラスターで ovs-subnet または ovs-multitenant モードを使用していた場合、OpenShift Container Platform 4.5 クラスターではネットワークポリシーに切り換えることが推奨されます。ネットワークポリシーはアップストリームでサポートされ、より柔軟であり、ovs-multitenant が実行する機能を提供します。OpenShift Container Platform 4.6 でネットワークポリシーを使用する際に ovs-multitenant 動作を維持する必要がある場合、ネットワークポリシーを使用したマルチテナント分離の設定手順を実行します。

詳細は、「ネットワークポリシーについて」を参照してください。

ホスト間のトラフィックの暗号化

OpenShift Container Platform 3.11 では、IPsec を使用してホスト間のトラフィックを暗号化できます。OpenShift Container Platform 4.5 は IPsec をサポートしません。サービス間で相互 TLS を有効にするために、Red Hat OpenShift Service Mesh を使用することが推奨されます。

詳細は、「Understanding Red Hat OpenShift Service Mesh」を参照してください。

1.2.2.3. ロギングについての考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.5 に移行する際に、考慮事項となる以下のロギングの変更を確認してください。

クラスターロギングのデプロイ

OpenShift Container Platform 4 は、クラスターロギングのカスタムリソース (Custom Resource) を使用してクラスターロギングの単純なデプロイメントメカニズムを提供します。

詳細は、クラスターロギングのインストールについて参照してください。

集計ロギングデータ

集計ロギングデータを OpenShift Container Platform 3.11 から新規の OpenShift Container Platform 4 クラスターに移行することはできません。

詳細は、「クラスターロギングについて」を参照してください。

サポートされないロギング設定

OpenShift Container Platform 3.11 で利用可能な一部のロギング設定は OpenShift Container Platform 4.5 でサポートされなくなりました。

明示的にサポートされていないロギングケースの詳細は、「メンテナンスとサポート」を参照してください。

1.2.2.4. セキュリティーに関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.5 へ移行する際に、考慮事項となる以下のセキュリティーの変更を確認してください。

検出エンドポイントへの認証されていないアクセス

OpenShift Container Platform 3.11 では、認証されていないユーザーは検出エンドポイント (例: /api/* および /apis/*) にアクセスできました。セキュリティー上の理由から、検出エンドポイントへの認証されていないアクセスは OpenShift Container Platform 4.5 で許可されなくなりました。認証されていないアクセスを許可する必要がある場合は、必要に応じて RBAC を設定できます。 ただし、これにより内部クラスターコンポーネントが外部ネットワークに公開される可能性があるため、セキュリティー上の影響を考慮してください。

アイデンティティープロバイダー

アイデンティティープロバイダーの設定は、以下の主な変更点を含め、 OpenShift Container Platform 4 で変更されています。

  • OpenShift Container Platform 4.5 の要求ヘッダーアイデンティティープロバイダーには相互 TLS が必要ですが、OpenShift Container Platform 3.11 ではこれは必要ではありませんでした。
  • OpenID Connect アイデンティティープロバイダーの設定は OpenShift Container Platform 4.5 で単純化されています。OpenShift Container Platform 3.11 で以前に指定される必要のあったデータが、プロバイダーの /.well-known/openid-configuration エンドポイントから取得できるようになりました。

詳細は、「アイデンティティープロバイダー設定について」を参照してください。

1.2.2.5. モニタリングに関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.5 に移行する際に、考慮事項となる以下のモニタリングの変更を確認してください。

インフラストラクチャーの可用性についてのモニタリングアラート

モニタリング構造の可用性を確保するためにトリガーするデフォルトのアラートは OpenShift Container Platform 3.11 では DeadMansSwitch と呼ばれていました。この名前は OpenShift Container Platform 4 で Watchdog に変更されています。OpenShift Container Platform 3.11 で PagerDuty 統合をこのアラートでセットアップしている場合、OpenShift Container Platform 4 では Watchdog アラートについて PagerDuty 統合をセットアップする必要があります。

詳細は、「カスタム Alertmanager 設定の適用」を参照してください。

1.3. 移行ツールおよび前提条件

アプリケーションワークロードを、MTC (Migration Toolkit for Containers) ツールを使用して OpenShift Container Platform 3.7、3.9、3.10、および 3.11 から OpenShift Container Platform 4.5 に移行できます。MTC を使用すると、移行を制御し、アプリケーションのダウンタイムを最小限に抑えることができます。

Kubernetes カスタムリソースをベースとする MTC の Web コンソールおよび API により、namespace の粒度でステートフルなアプリケーションワークロードを移行できます。

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

移行フックを使用して、移行中の特定の時点で Ansible Playbook を実行できます。フックは移行計画の作成時に追加されます。

注記

サービスカタログは OpenShift Container Platform 4 では非推奨になっています。サービスカタログでプロビジョニングされたワークロードリソースを OpenShift Container Platform 3 から 4 に移行できますが、移行後にこれらのワークロードで provisiondeprovision、または update などのサービスカタログのアクションを実行できません。

MTC の Web コンソールは、サービスカタログリソースを移行できない場合にメッセージを表示します。

重要

移行を開始する前に、移行計画 についての情報を確認してください。

1.3.1. MTC (Migration Toolkit for Containers) ワークフロー

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

(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)を移行します。

  • カスタムリソース定義 (CRD) およびカスタムリソース定義 (CRD): MTC は、namespace レベルに存在する CR およびそれらの CR にリンクされた CRB を自動的に移行します。

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

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

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

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

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

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

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

      注記

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

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

      注記

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

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

    • Stage (オプション) は、アプリケーションを停止せずにデータをターゲットクラスターにコピーします。

      ステージングは、移行前にほとんどのデータがターゲットにコピーされるように複数回実行することができます。これにより、移行時間やアプリケーションのダウンタイムが最小限に抑えられます。

    • Migrate は、ソースクラスターでアプリケーションを停止し、ターゲットクラスターでそのリソースを再作成します。オプションで、アプリケーションを停止せずにワークロードを移行できます。
OCP 3 から 4 のアプリケーション移行

1.3.2. MTC (Migration Toolkit for Containers) カスタムリソース

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

1.3.3. データのコピー方法

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

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

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

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

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

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

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

AWS、Google Cloud Provider、および Microsoft Azure は、スナップショットのコピー方法をサポートします。

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

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

1.3.4. 移行フックについて

移行フックを使用して、MTC (Migration Toolkit for Containers) を使用した移行中の特定の時点でカスタムコードを実行できます。単一の移行計画に最大 4 つの移行フックを追加し、各フックを移行の異なるフェーズで実行できます。

移行フックは、アプリケーションの休止状態のカスタマイズ、サポート外のデータタイプの手動の移行、および移行後のアプリケーションの更新などのタスクを実行します。

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

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

Ansible Playbook またはカスタムフックコンテナーを使用してフックを作成できます。

Ansible Playbook

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

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

オプション: デフォルトイメージの代わりに、追加の Ansible モジュールまたはツールを含むカスタム Ansible ランタイムイメージを使用できます。

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

Ansible Playbook またはカスタムコードを含むカスタムフックコンテナーを作成できます。

1.4. MTC (Migration Toolkit for Containers) のインストールおよびアップグレード

OpenShift Container Platform 4.5 ターゲットクラスターおよび OpenShift Container Platform 3 ソースクラスターに MTC (Migration Toolkit for Containers) をインストールすることができます。

Migration Controller Pod は、デフォルトでターゲットクラスターで実行されます。Migration コントローラー Pod を ソースクラスターまたはリモートクラスターで実行するように設定できます。

1.4.1. 接続された環境での MTC (Migration Toolkit for Containers) のインストール

接続された環境で MTC (Migration Toolkit for Containers) をインストールできます。

重要

すべてのクラスターに同じ MTC バージョンをインストールする必要があります。

1.4.1.1. Migration Toolkit for Containers の OpenShift Container Platform 4.5 ターゲットクラスターへのインストール

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4.5 ターゲットクラスターにインストールできます。

前提条件

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

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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 が実行されていることを確認します。

1.4.1.2. OpenShift Container Platform 3 ソースクラスターへの Migration Toolkit for Containers Operator のインストール

Migration Toolkit for Containers (MTC) を手動で OpenShift Container Platform 3 ソースクラスターにインストールできます。

重要

OpenShift Container Platform 3 および 4 クラスターに同じ MTC バージョンをインストールする必要があります。

OpenShift Container Platform 3 クラスターで最新バージョンを使用できるようにするには、移行計画を作成し、実行する準備ができたら operator.yml および controller-3.yml ファイルをダウンロードします。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • registry.redhat.io にアクセスできる必要があります。
  • podman がインストールされている必要があります。
  • ソースクラスターは OpenShift Container Platform 3.7、3.9、3.10、または 3.11 である必要があります。
  • ソースクラスターは、イメージを registry.redhat.io からプルするように設定されている必要があります。

    イメージをプルするには、イメージストリームのシークレットを作成し、これをクラスター内の各ノードにコピーする必要があります。

手順

  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-rhel7-operator:v1.4):/operator.yml ./
  3. controller-3.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.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-3.yml
  8. Velero および Restic Pod が実行されていることを確認します。

    $ oc get pods -n openshift-migration

1.4.2. 制限された環境での Migration Toolkit for Containers Operator のインストール

制限された環境で Migration Toolkit for Containers Operator をインストールできます。

重要

すべてのクラスターに同じ MTC バージョンをインストールする必要があります。

OpenShift Container Platform 4 のカスタム Operator カタログイメージをビルドし、これをローカルミラーイメージレジストリーにプッシュし、Operator Lifecycle Manager (OLM) をローカルレジストリーから Migration Toolkit for Containers Operator をインストールするように設定できます。

1.4.2.1. Operator カタログイメージのビルド

クラスター管理者は、Operator Lifecycle Manager (OLM) によって使用される Package Manifest Format に基づいてカスタム Operator カタログイメージをビルドできます。カタログイメージは、Docker v2-2 をサポートするコンテナーイメージレジストリーにプッシュできます。ネットワークが制限された環境のクラスターの場合、このレジストリーには、ネットワークが制限されたクラスターのインストール時に作成されたミラーレジストリーなど、クラスターにネットワークアクセスのあるレジストリーを使用できます。

重要

OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

以下の例では、お使いのネットワークとインターネットの両方にアクセスできるミラーレジストリーを使用することを前提としています。

注記

Windows および macOS のバージョンは oc adm catalog build コマンドを提供しないため、この手順では oc クライアントの Linux バージョンのみを使用できます。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • oc バージョン 4.3.5+ Linux クライアント
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • quay.io アカウントがアクセスできるプライベート namespace を使用している場合、Quay 認証トークンを設定する必要があります。quay.io 認証情報を使用してログイン API に対して要求を行うことにより、--auth-token フラグで使用できる AUTH_TOKEN 環境変数を設定します。

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

手順

  1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

    $ podman login <registry_host_name>

    また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

    $ podman login registry.redhat.io
  2. Quay.io から redhat-operators カタログをベースにカタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    App Registry インスタンスからのプルに使用する組織 (namespace)。
    2
    ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--fromose-operator-registry ベースイメージに設定します。
    3
    --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64linux/ppc64le、および linux/s390x です。
    4
    カタログイメージに名前を付け、v1 などのタグを追加します。
    5
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    6
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    7
    オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

    出力例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

    無効なマニフェストが Red Hat のカタログに誤って導入されることあります。これが実際に生じる場合には、以下のようなエラーが表示される可能性があります。

    エラーのある出力の例

    ...
    INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
    W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
    Uploading ... 244.9kB/s

    通常、これらのエラーは致命的なエラーではなく、該当する Operator パッケージにインストールする予定の Operator やその依存関係が含まれない場合、それらを無視することができます。

1.4.2.2. ネットワークが制限された環境向けの OperatorHub の設定

クラスター管理者は、カスタム Operator カタログイメージを使用し、OLM および OperatorHub をネットワークが制限された環境でローカルコンテンツを使用するように設定できます。この例では、以前にビルドされ、サポートされているレジストリーにプッシュされたカスタム redhat-operators カタログイメージを使用します。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • サポートされているレジストリーにプッシュされるカスタム Operator カタログイメージ
  • oc version 4.3.5+
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

手順

  1. oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。以下のいずれかを選択できます。

    • コマンドのデフォルト動作で、マニフェストの生成後にすべてのイメージコンテンツをミラーレジストリーに自動的にミラーリングできるようにします。または、
    • --manifests-only フラグを追加して、ミラーリングに必要なマニフェストのみを生成しますが、これにより、イメージコンテンツがレジストリーに自動的にミラーリングされる訳ではありません。これは、ミラーリングする内容を確認するのに役立ちます。また、コンテンツのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、そのファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。

    ネットワークアクセスが無制限のワークステーションで、以下のコマンドを実行します。

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v1 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' \4
        [--manifests-only] 5
    1
    Operator カタログイメージを指定します。
    2
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    3
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    4
    このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。
    5
    オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。
    警告

    --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

    出力例

    using database path mapping: /:/tmp/190214037
    wrote database to /tmp/190214037
    using database at: /tmp/190214037/bundles.db 1
    ...

    1
    コマンドで生成される一時的なデータベース。

    コマンドの実行後に、<image_name>-manifests/ ディレクトリーが現在のディレクトリーに作成され、以下のファイルが生成されます。

    • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。
    • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。
  2. 直前の手順で --manifests-only フラグを使用して、コンテンツのサブセットのみをミラーリングする場合は、以下を実行します。

    1. mapping.txt ファイルのイメージの一覧を仕様に変更します。ミラーリングするイメージのサブセットの名前とバージョンが不明な場合は、以下の手順で確認します。

      1. oc adm catalog mirror コマンドで生成された一時的なデータベースに対して sqlite3 ツールを実行し、一般的な検索クエリーに一致するイメージの一覧を取得します。出力は、後に mapping.txt ファイルを編集する方法を通知するのに役立ちます。

        たとえば、clusterlogging.4.3 の文字列のようなイメージの一覧を取得するには、以下を実行します。

        $ echo "select * from related_image \
            where operatorbundle_name like 'clusterlogging.4.3%';" \
            | sqlite3 -line /tmp/190214037/bundles.db 1
        1
        oc adm catalog mirror コマンドの直前の出力を参照し、データベースファイルのパスを見つけます。

        出力例

        image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        
        image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        ...

      2. 直前の手順で取得した結果を使用して mapping.txt ファイルを編集し、ミラーリングする必要のあるイメージのサブセットのみを追加します。

        たとえば、前述の出力例の image 値を使用して、mapping.txt ファイルに以下の一致する行が存在することを確認できます。

        mapping.txt の一致するイメージマッピング。

        registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

        この例では、これらのイメージのみをミラーリングする場合に、mapping.txt ファイルの他のすべてのエントリーを削除し、上記の 2 行のみを残します。

    2. ネットワークアクセスが無制限のワークステーション上で、変更した mapping.txt ファイルを使用し、 oc image mirror コマンドを使用してイメージをレジストリーにミラーリングします。

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt
      警告

      --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。

  3. ImageContentSourcePolicy オブジェクトを適用します。

    $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml
  4. カタログイメージを参照する CatalogSource オブジェクトを作成します。

    1. 仕様を以下のように変更し、これを catalogsource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc
      1
      Operator カタログイメージを指定します。
    2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc create -f catalogsource.yaml
  5. 以下のリソースが正常に作成されていることを確認します。

    1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

ネットワークが制限された環境の OpenShift Container Platform クラスター Web コンソールで、OperatorHub ページから Operator をインストールできます。

1.4.2.3. 制限された環境での Migration Toolkit for Containers の OpenShift Container Platform 4.5 ターゲットクラスターへのインストール

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4.5 ターゲットクラスターにインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • カスタム Operator カタログを作成し、これをミラーレジストリーにプッシュする必要があります。
  • ミラーレジストリーから Migration Toolkit for Containers Operator をインストールするように OLM を設定している必要があります。

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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 が実行されていることを確認します。

1.4.2.4. 制限された環境での Migration Toolkit for Containers Operator の OpenShift Container Platform 3 ソースクラスターへのインストール

Migration Toolkit for Containers (MTC) Operator イメージに基づいてマニフェストファイルを作成し、ローカルイメージレジストリーを参照するようにマニフェストを編集できます。次に、ローカルイメージを使用して Migration Toolkit for Containers Operator を OpenShift Container Platform 3 ソースクラスターに作成できます。

重要

OpenShift Container Platform 3 および 4 クラスターに同じ MTC バージョンをインストールする必要があります。

OpenShift Container Platform 3 クラスターで最新バージョンを使用できるようにするには、移行計画を作成し、実行する準備ができたら operator.yml および controller-3.yml ファイルをダウンロードします。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • registry.redhat.io にアクセスできる必要があります。
  • podman がインストールされている必要があります。
  • ソースクラスターは OpenShift Container Platform 3.7、3.9、3.10、または 3.11 である必要があります。
  • ネットワークアクセスが無制限の Linux ワークステーションが必要です。
  • Docker v2-2 をサポートするミラーレジストリーへのアクセスが必要です。

手順

  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-rhel7-operator:v1.4):/operator.yml ./
  3. controller-3.yml ファイルをダウンロードします。

    $ sudo podman cp $(sudo podman create \
      registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./
  4. OpenShift Container Platform 4 クラスターで oc adm catalog mirror の実行時に作成された mapping.txt ファイルから Operator イメージの値を取得します。

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

    出力には、registry.redhat.io イメージとミラーレジストリーイメージ間のマッピングが表示されます。

    出力例

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

  5. Operator 設定ファイルの image および REGISTRY の値を更新します。

    containers:
      - name: ansible
        image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
    ...
      - name: operator
        image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
    ...
        env:
        - name: REGISTRY
          value: <registry.apps.example.com> 3
    1
    ミラーレジストリー、および mapping.txt ファイルで Operator イメージの sha256 の値を指定します。
    2
    ミラーレジストリー、および mapping.txt ファイルで 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-3.yml
  9. Velero および Restic Pod が実行されていることを確認します。

    $ oc get pods -n openshift-migration

1.4.3. MTC (Migration Toolkit for Containers) のアップグレード

MTC (Migration Toolkit for Containers) は、OpenShift Container Platform Web コンソールを使用してアップグレードできます。

重要

同じ MTC バージョンがすべてのクラスターにインストールされていることを確認する必要があります。

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

1.4.3.1. OpenShift Container Platform 4 クラスターでの MTC (Migration Toolkit for Containers) のアップグレード

MTC (Migration Toolkit for Containers) は OpenShift Container Platform Web コンソールを使用して OpenShift Container Platform 4 クラスターでアップグレードできます。

前提条件

  • 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. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

1.4.3.2. OpenShift Container Platform 3 クラスターでの MTC (Migration Toolkit for Containers) のアップグレード

MTC (Migration Toolkit for Containers) を、podman を使用して OpenShift Container Platform 3 クラスターでアップグレードできます。

前提条件

  • 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-rhel7-operator:v1.4):/operator.yml ./ 1
    1
    必要な場合は z-stream リリースを指定できます。
  3. Migration Toolkit for Containers Operator を置き換えます。

    $ oc replace --force -f operator.yml
  4. 変更を適用します。

    • MTC 1.1.2 以前のバージョンの場合は、Restic Pod を削除します。

      $ oc delete pod <restic_pod>
    • MTC 1.2 以降のバージョンの場合:

      1. migration-operator デプロイメントを 0 にスケーリングし、デプロイメントを停止します。

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

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

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

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

    $ oc create -f controller-3.yml
  8. OpenShift Container Platform バージョンが 3.10 以前である場合、migration-controller サービスアカウントの SCC (Security Context Constraints) を anyuid に設定して、イメージの直接移行およびボリュームの直接移行を有効にします。

    $ oc adm policy add-scc-to-user anyuid -z migration-controller -n openshift-migration
  9. MTC Pod が実行されていることを確認します。

    $ oc get pods -n openshift-migration
  10. OpenShift Container Platform 3 クラスターを MTC Web コンソールに追加している場合、アップグレードプロセスにより openshift-migration namespace が削除され、復元されるため、Web コンソースでサービスアカウントトークンを更新する必要があります。

    1. サービスアカウントトークンを取得します。

      $ oc sa get-token migration-controller -n openshift-migration
    2. MTC の Web コンソールで、Clusters をクリックします。
    3. クラスターの横にある Options メニュー kebab をクリックし、Edit を選択します。
    4. Service account token フィールドに新規サービスアカウントトークンを入力します。
    5. Update cluster をクリックしてから、Close をクリックします。

1.4.3.3. MTC 1.3 から 1.4 へのアップグレード

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

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

前提条件

  • MTC 1.3 がインストールされている必要があります。
  • 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

1.5. レプリケーションリポジトリーのオブジェクトストレージの設定

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

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

以下のストレージプロバイダーがサポートされています。

制限された環境では、内部でホストされるレプリケーションリポジトリーを作成できます。

前提条件

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

1.5.1. Multi-Cloud Object Gateway ストレージバケットをレプリケーションリポジトリーとして設定する

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

1.5.1.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 プロジェクトに表示されます。

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

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

手順

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

    $ oc login
  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
    非常に小規模なクラスターの場合、cpu の値を 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-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    永続ボリュームプール内のボリューム数を指定します。
    2
    ボリュームのサイズを指定します。
    3
    ストレージクラスを作成します。
  5. BackingStore オブジェクトを作成します。

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

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

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

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    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

1.5.2. AWS S3 ストレージバケットをレプリケーションリポジトリーとして設定する

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_name> \ 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_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 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 を記録します。

1.5.3. 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_name> 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

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

1.6. アプリケーションの移行

MTC (Migration Toolkit for Containers) の Web コンソールまたはコマンドラインでアプリケーションを移行できます。

1.6.1. 前提条件

MTC (Migration Toolkit for Containers) には以下の要件があります。

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • MTC のバージョンは、すべてのクラスターで同一である必要があります。
  • アプリケーションが openshift namespace の内部イメージを使用する場合、イメージの必要なバージョンがターゲットクラスターに存在することを確認する必要があります。

    OpenShift Container Platform 4.5 クラスターで非推奨の OpenShift Container Platform 3 イメージを使用できるように、イメージストリームタグを手動で更新できます。

  • クラスター:

    • ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
    • migration-controller Pod が実行されているクラスターには他のクラスターへの無制限のネットワークアクセスが必要です。
    • クラスターには、相互への無制限のネットワークアクセスが必要です。
    • クラスターには、レプリケーションリポジトリーへの無制限のネットワークアクセスが必要です。
    • クラスターは、ポート 443 で OpenShift ルートを使用して通信できる必要があります。
    • クラスターには、Critical (重大) 状態があってはなりません。
    • クラスターは Ready (準備) 状態である必要があります。
  • ボリュームの移行:

    • 永続ボリューム (PV) は有効である必要があります。
    • PV は永続ボリューム要求にバインドされる必要があります。
    • move メソッドを使用して PV をコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。
    • スナップショット のコピー方法を使用して PV をコピーする場合、以下の前提条件が適用されます。

      • クラウドプロバイダーはスナップショットをサポートしている必要があります。
      • ボリュームに同じクラウドプロバイダーがなければなりません。
      • ボリュームは同じ地理的リージョンにある必要があります。
      • ボリュームには同じストレージクラスがなければなりません。
  • プロキシー環境でボリュームの直接移行を実行する場合、Stunnel の TCP プロキシーを設定する必要があります。
  • イメージの直接移行を実行する場合、ソースクラスターの内部レジストリーを外部トラフィックに公開する必要があります。

1.6.1.1. podman を使用した非推奨の内部イメージの更新

アプリケーションが openshift namespace のイメージを使用する場合、イメージの必要なバージョンがターゲットクラスターに存在する必要があります。

OpenShift Container Platform 3 イメージが OpenShift Container Platform 4.5 で非推奨になる場合、podman を使用してイメージストリームタグを手動で更新できます。

前提条件

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

手順

  1. ソースおよびターゲットクラスターで内部レジストリーを公開します。
  2. 非セキュアなレジストリーを使用している場合、レジストリーホスト値を /etc/container/registries.conf[registries.insecure] セクションの追加し、podman で TLS 検証エラーが生じないようにします。
  3. ソースクラスターレジストリーにログインします。

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <source_cluster>
  4. ターゲットクラスターレジストリーにログインします。

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <target_cluster>
  5. 非推奨のイメージをプルします。

    $ podman pull <source_cluster>/openshift/<image>
  6. ターゲットクラスターレジストリーのイメージにタグを付けます。

    $ podman tag <source_cluster>/openshift/<image> <target_cluster>/openshift/<image>
  7. イメージをターゲットクラスター 4 レジストリーにプッシュします。

    $ podman push <target_cluster>/openshift/<image>
  8. イメージにターゲットクラスターの有効なイメージストリームがあることを確認します。

    $ oc get imagestream -n openshift | grep <image>

    出力例

    <image>    <target_cluster>/openshift/<image>     <versions>
    more...      6 seconds ago

1.6.1.2. CA 証明書バンドルファイルの作成

自己署名証明書を使用して 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 バンドルファイルの名前を指定します。

1.6.1.3. ボリュームの直接移行のためのプロキシー設定

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

注記

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

前提条件

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

手順

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

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. stunnel_tcp_proxy パラメーターを追加します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    Stunnel プロキシーを指定します: http://<user_name>:<password>@<ip_address>:<port>
  4. マニフェストを migration-controller.yaml として保存します。
  5. 更新したマニフェストを適用します。

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

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

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

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

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

1.6.1.4.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') }}"

1.6.1.5. 追加リソース

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

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

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

1.6.2.2. クラスターの Migration Toolkit for Containers 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: イメージの直接移行を使用している場合、ソースクラスターのイメージレジストリーへの公開されたルートを指定します (例: www.example.apps.cluster.com)。

      ポートを指定できます。デフォルトのポートは 5000 です。

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

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

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

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

前提条件

  • データを移行するには、オブジェクトストレージバケットを設定する必要があります。

手順

  1. MTC の Web コンソールで、Replication repositories をクリックします。
  2. Add repository をクリックします。
  3. Storage provider type を選択し、以下のフィールドに入力します。

    • AWS (AWS S3、MCG、および汎用 S3 プロバイダーの場合):

      • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
      • S3 bucket name: 作成した S3 バケットの名前を指定します。
      • S3 bucket region: S3 バケットリージョンを指定します。AWS S3 の場合に必須です。Optional (他の 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 provider secret access key: AWS には <AWS_ACCESS_KEY_ID> を指定するか、または MCG には S3 プロバイダーシークレットアクセスキーを指定します。
      • Require SSL verification: 汎用 S3 プロバイダーを使用している場合は、このチェックボックスをクリアします。
      • カスタム CA バンドルを使用する場合は、Browse をクリックし、Base64 でエンコードされた CA バンドルファイルを参照します。
    • GCP:

      • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
      • GCP bucket name: GCP バケットの名前を指定します。
      • GCP credential JSON blob: credentials-velero ファイルに文字列を指定します。
    • Azure:

      • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
      • Azure resource group: Azure Blob ストレージのリソースグループを指定します。
      • Azure storage account name: Azure Blob ストレージアカウント名を指定します。
      • Azure credentials - INI file contents: credentials-velero ファイルに文字列を指定します。
  4. Add repository をクリックし、接続の検証を待機します。
  5. Close をクリックします。

    新規リポジトリーが Replication repositories 一覧に表示されます。

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

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

前提条件

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

手順

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

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

  4. Source cluster を選択します。
  5. Target clusterを選択します。
  6. Replication repository を選択します。
  7. 移行するプロジェクトを選択し、Next をクリックします。
  8. Source clusterTarget cluster、および Repository を選択し、 Next をクリックします。
  9. Namespaces ページで、移行するプロジェクトを選択し、 Next をクリックします。
  10. Persistent volumes ページで、各 PV の Migration type をクリックします。

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

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

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

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

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

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

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

  17. Next をクリックします。
  18. オプション: Hooks ページで 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 をクリックします。
  19. Finish をクリックします。

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

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

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

注記

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

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

前提条件

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

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

手順

  1. ソースクラスターにログインします。
  2. 古いイメージを削除します。

    $ oc adm prune images
  3. MTC の Web コンソールにログインし、Migration plans をクリックします。
  4. 移行計画の横にある Options メニュー kebab をクリックし、Stage を選択して、アプリケーションを停止せずにソースクラスターからターゲットクラスターにデータをコピーします。

    実際の移行時間を短縮するには、Stage を複数回実行することができます。

  5. アプリケーションのワークロードを移行する準備ができたら、移行計画の横にある Options メニュー kebab をクリックし、Migrate を選択します。
  6. オプション: Migrate ウィンドウで Do not stop applications on the source cluster during migration を選択できます。
  7. Migrate をクリックします。
  8. 移行が完了したら、アプリケーションが OpenShift Container Platform Web コンソールで正常に移行されていることを確認します。

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

1.6.3. コマンドラインでのアプリケーションの移行

MTC カスタムリソース (CR) を使用して、コマンドラインでアプリケーションを移行できます。

アプリケーションをローカルクラスターからリモートクラスター、リモートクラスターからローカルクラスター、およびリモートクラスター間で移行できます。

MTC の用語

クラスターの設定に関連して、以下の用語が使用されます。

  • host クラスター:

    • migration-controller Pod は hostクラスターで実行されます。
    • host クラスターでは、直接のイメージ移行に公開されたセキュアなレジストリールートは不要です。
  • ローカルクラスター: ローカルクラスターは host クラスターと同じである場合が多くありますが、これは必須ではありません。
  • リモートクラスター:

    • リモートクラスターには、直接のイメージ移行に公開されるセキュアなレジストリールートが必要です。
    • リモートクラスターには、migration-controller サービスアカウントトークンが含まれる Secret CR が必要です。

移行の実行に関連して、以下の用語が使用されます。

  • ソースクラスター: アプリケーションの移行元となるクラスター。
  • 宛先クラスター: アプリケーションが移行されるクラスター。

1.6.3.1. MTC (Migration Toolkit for Containers) を使用したアプリケーションの移行

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

アプリケーションをローカルクラスターからリモートクラスター、リモートクラスターからローカルクラスター、およびリモートクラスター間で移行できます。

この手順では、間接的および直接的な移行を実行する方法を説明します。

  • 間接的な移行: イメージ、ボリューム、および Kubernetes オブジェクトはソースクラスターからレプリケーションリポジトリーにコピーされ、その後にレプリケーションリポジトリーから宛先クラスターにコピーされます。
  • 直接的な移行: イメージまたはボリュームはソースクラスターから宛先クラスターに直接コピーされます。イメージとボリュームの直接的な移行には、パフォーマンス上の大きなメリットがあります。

以下のカスタムリソース (CR) を作成して移行を実行します。

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

    migration-controller Pod は hostクラスターで実行されます。

  • Secret CR: リモートクラスターまたはストレージの認証情報が含まれます。
  • MigStorage CR: レプリケーションリポジトリーを定義します。

    異なるストレージプロバイダーには、MigStorage CR マニフェストで異なるパラメーターが必要です。

  • MigPlan CR: 移行計画を定義します。
  • MigMigration CR: 関連付けられた MigPlan で定義された移行を実行します。

    以下の目的で、単一の MigPlan CR に複数の MigMigration CR を作成できます。

  • 移行を実行する前に、アプリケーションを停止せずにほとんどのデータをコピーする段階移行 (Stage migration) を実行する。段階移行により、移行のパフォーマンスが向上します。
  • 実行中の移行を取り消す。
  • 完了した移行をロールバックする

前提条件

  • すべてのクラスターで cluster-admin 権限が必要です。
  • OpenShift Container Platform CLI (oc) をインストールする必要があります。
  • すべてのクラスターに MTC (Migration Toolkit for Containers Operator) をインストールする必要があります。
  • インストールされた MTC (Migration Toolkit for Containers Operator) の version は、すべてのクラスターで同一である必要があります。
  • オブジェクトストレージをレプリケーションリポジトリーとして設定する必要があります。
  • イメージの直接的な移行を実行している場合、すべてのリモートクラスターでセキュアなレジストリールートを公開する必要があります。
  • ボリュームの直接移行を使用している場合、ソースクラスターには HTTP プロキシーを設定することはできません。

手順

  1. host-cluster.yaml という host クラスターの MigCluster CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host クラスターの MigCluster CR を作成します。

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. 各リモートクラスターに、cluster-secret.yaml という Secret CR マニフェストを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    リモートクラスターの base64 でエンコードされた migration-controller サービスアカウント (SA) トークンを指定します。

    以下のコマンドを実行して SA トークンを取得できます。

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. それぞれのリモートクラスターに Secret CR を作成します。

    $ oc create -f cluster-secret.yaml
  5. それぞれのリモートクラスターに、remote-cluster.yaml という MigCluster CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    オプション: 直接的なイメージの移行を実行する場合、公開されるレジストリールートを指定します (例: docker-registry-default.apps.example.com)。
    2
    SSL 検証は、false の場合に有効になります。CA 証明書は、true の場合は必要ではなく、チェックされません。
    3
    リモートクラスターの Secret CR を指定します。
    4
    リモートクラスターの URL を指定します。
  6. それぞれのリモートクラスターについて MigCluster CR を作成します。

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. すべてのクラスターが Ready 状態にあることを確認します。

    $ oc describe cluster <cluster_name>
  8. storage-secret.yaml というレプリケーションリポジトリーの Secret CR マニフェストを作成します。

    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
    1
    キー ID を base64 形式で指定します。
    2
    シークレットキーを base64 形式で指定します。

    AWS 認証情報はデフォルトで base64 でエンコードされます。別のストレージプロバイダーを使用している場合、それぞれのキーを使用して以下のコマンドを実行して、認証情報をエンコードする必要があります。

    $ echo -n "<key>" | base64 -w 0 1
    1
    キー ID またはシークレットキーを指定します。どちらの値も base64 でエンコードする必要があります。
  9. レプリケーションリポジトリーの Secret CR を作成します。

    $ oc create -f storage-secret.yaml
  10. migstorage.yaml というレプリケーションリポジトリーの MigStorage CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    バケット名を指定します。
    2
    オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。
    3
    ストレージプロバイダーを指定します。
    4
    オプション: スナップショットを使用してデータをコピーする場合は、オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。
    5
    オプション: スナップショットを使用してデータをコピーする場合は、ストレージプロバイダーを指定します。
  11. MigStorage CR を作成します。

    $ oc create -f migstorage.yaml -n openshift-migration
  12. MigStorage CR が Ready 状態にあることを確認します。

    $ oc describe migstorage <migstorage_name>
  13. migplan.yaml という MigPlan CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    false の場合、直接的なイメージ移行が有効にされます。
    2
    false の場合、直接的なボリューム移行が有効にされます。
    3
    MigStorage CR インスタンスの名前を指定します。
    4
    移行する namespace を 1 つ以上指定します。
    5
    ソースクラスター MigCluster インスタンスの名前を指定します。
  14. MigPlan CR を作成します。

    $ oc create -f migplan.yaml -n openshift-migration
  15. MigPlan インスタンスを表示し、そのインスタンスが Ready 状態にあることを確認します。

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. migmigration.yaml という MigMigration CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    MigPlan CR 名を指定します。
    2
    true の場合、ソースクラスターの Pod は停止します。
    3
    true の場合、アプリケーションを停止せずにほとんどのデータをコピーする段階移行が実行されます。
    4
    true の場合、完了した移行がロールバックされます。
  17. MigMigration CR を作成し、MigPlan CR に定義された移行を開始します。

    $ oc create -f migmigration.yaml -n openshift-migration
  18. MigMigration CR を監視して移行の進捗を確認します。

    $ oc watch migmigration <migmigration_name> -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:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

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

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

1.6.3.2.1. DirectImageMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
ソースクラスターの MigCluster CR 名を指定します。
2
宛先クラスターの MigCluster CR 名を指定します。
3
移行するイメージが含まれる namespace を 1 つ以上指定します。
1.6.3.2.2. DirectImageStreamMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
ソースクラスターの MigCluster CR 名を指定します。
2
宛先クラスターの MigCluster CR 名を指定します。
3
イメージストリーム名を指定します。
4
ソースクラスターにイメージストリーム namespace を指定します。
5
宛先クラスターでイメージストリーム namespace を指定します。
1.6.3.2.3. DirectVolumeMigration

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

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

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

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

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

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

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

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  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.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
オプション: migration-controller Pod がこのクラスターで実行されていない場合には、クラスター名を更新します。
2
true の場合、migration-controller Pod がこのクラスターで実行されます。
3
オプション: ストレージプロバイダーが Microsoft Azure の場合は、リソースグループを指定します。
4
オプション: 自己署名 CA 証明書の証明書バンドルを作成しており、insecureな パラメーターの値が false の場合、base64 でエンコードされた証明書バンドルを指定します。
5
SSL 検証は、false の場合に有効になります。
6
true の場合、クラスターが検証されます。
7
true の場合、ステージ Pod の作成後に restic Pod がソースクラスターで再起動します。
8
オプション: 直接的なイメージ移行を使用している場合、リモートクラスターの公開されるレジストリーパスを指定します。
9
リモートクラスターの URL を指定します。
10
リモートクラスターの Secret CR の名前を指定します。
1.6.3.2.7. MigHook

MigHook CR は、Ansible Playbook、または移行の特定の段階でタスクを実行するカスタムイメージを定義します。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 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
フックが実行されるクラスターとして source または destination を指定します。
1.6.3.2.8. MigMigration

MigMigration CR は関連付けられる MigPlan CR を実行します。

以下のシナリオについて、同じ MigPlan CR に関連付けられた複数の MigMigration CR を作成できます。

  • stage (段階) 移行または増分移行を複数回実行して、ソースクラスターで Pod を停止せずにデータをコピーすることができます。段階移行の実行により、実際の移行のパフォーマンスが向上します。
  • 進行中の移行を取り消すことができます。
  • 移行をロールバックできます。
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  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_ref> 7
    namespace: openshift-migration
1
true の場合、進行中の移行が取り消されます。
2
true の場合、完了した移行がロールバックされます。
3
true の場合、データが増分的にコピーされ、ソースクラスターは停止しません。
4
true の場合、ソースクラスターの Pod は、移行の Backup ステージの後に 0 にスケーリングされます。
5
true の場合、移行中に適用されるラベルとアノテーションは保持されます。
6
true の場合、宛先クラスターで移行される Pod のステータスはチェックされ、Running 状態にない Pod の名前が返されます。
7
migPlanRef.name: 関連付けられる MigPlan CR の名前を指定します。
1.6.3.2.9. MigPlan

MigPlan CR は移行計画のパラメーターを定義します。これには、同じパラメーターで移行される仮想マシンのグループが含まれます。

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

MigStorage CR はレプリケーションリポジトリーのオブジェクトストレージを記述します。Amazon Web Services、Microsoft Azure、Google Cloud Storage、および汎用 S3 互換クラウドストレージ (例: Minio または NooBaa) を設定できます。

プロバイダーごとに異なるパラメーターが必要です。

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

1.6.4. 追加リソース

1.6.5. 移行計画の設定

移行するオブジェクト数を増やしたり、移行からリソースを除外したりできます。

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

1.6.5.2. 移行計画からのリソースの除外

移行についてのリソース負荷を減らしたり、別のツールでイメージや 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
    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

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

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

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

注記

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

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

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

手順

  1. openshift-migration namespace の MigMigration CR を一覧表示します。

    $ oc get migmigration -n openshift-migration

    出力例

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

  2. MigMigration CR を検査します。

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

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

MigMigration の出力例

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

PV データを記述する Velero バックアップ CR #2 の出力例

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

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

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

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

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

手順

  1. mig-log-reader Pod を取得します。

    $ oc -n openshift-migration get pods | grep log
  2. 以下のコマンドを入力して、単一の移行ログを表示します。

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    -c plain オプションは、色なしでログを表示します。

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

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

手順

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

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

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

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

1.7.4. 非推奨の API の更新

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

Some namespaces contain GVKs incompatible with destination cluster

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

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

手順

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

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

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

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    MigPlan CR UID を記録します。
    2
    gvks セクションに一覧表示された非推奨の API を記録します。
  3. MigPlan UID に関連付けられた MigMigration 名を取得します。

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    MigPlan CR UID を指定します。
  4. MigMigration 名に関連付けられた MigMigration UID を取得します。

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    MigMigration 名を指定します。
  5. MigMigration UID に関連付けられた Velero バックアップ名を取得します。

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    MigMigration UID を指定します。
  6. ストレージプロバイダーのコマンドを実行して、Velero バックアップの内容をローカルマシンにダウンロードします。

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。
    • GCP

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      バックアップ名とローカルバックアップのディレクトリー名を指定します。
  7. Velero バックアップアーカイブファイルを展開します。

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 非推奨のそれぞれの API でオフラインモードで oc convert を実行します。

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

    $ oc create -f <gvk>.json

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

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

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

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

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

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

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

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

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

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

手順

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

    $ oc logs <MigrationUI_Pod> -n openshift-migration

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

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

出力例

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

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

手順

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

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

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

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

出力例

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

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

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

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

手順

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

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

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

    出力例

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

  3. PodVolumeRestore CR を表示します。

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

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

    出力例

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

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

    $ oc logs -f <restic-nr2v5>

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

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

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

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

手順

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

    $ oc describe migmigration <pod_name> -n openshift-migration

    出力には、以下のようなステータス情報が含まれます。

    出力例

    ...
    Some or all transfer pods are not running for more than 10 mins on destination cluster
    ...

  2. ソースクラスターで、移行した namespace の詳細を取得します。

    $ oc get namespace <namespace> -o yaml 1
    1
    移行した namespace を指定します。
  3. ターゲットクラスターで、移行した namespace を編集します。

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

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. 移行計画を再度実行します。

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

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

1.7.7.1. Velero コマンド構文

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

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

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

1.7.7.2. Help コマンド

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

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

1.7.7.3. describe コマンド

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

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

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

1.7.7.4. logs コマンド

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

velero <resource> logs <resource_id>

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

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

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

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

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

手順

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

    $ oc get migmigration <migmigration> -o yaml
    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings
  2. Velero describe コマンドを使用して Restore CR のステータスを確認します。

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. Velero logs コマンドを使用して Restore CR ログを確認します。

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    Restore CR のログエラーメッセージの the server could not find the requested resource は、部分的に失敗した移行の原因を示します。

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

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

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

手順

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

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

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

1.7.9. 移行のロールバック

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

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

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

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

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

手順

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

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

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

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

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

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

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

手順

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

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

1.7.10. 既知の問題

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

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

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

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

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

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

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

1.7.11. 追加リソース

第2章 OpenShift Container Platform 4.1 からの移行

2.1. 移行ツールおよび前提条件

アプリケーションワークロードを、MTC (Migration Toolkit for Containers) を使用して OpenShift Container Platform 4.1 から 4.5 に移行できます。MTC を使用すると、移行を制御し、アプリケーションのダウンタイムを最小限に抑えることができます。

注記

ソースおよびターゲットクラスターが正しく設定されている場合、同じバージョンの OpenShift Container Platform クラスター間で移行できます (4.1 から 4.1 への移行など)。

Kubernetes カスタムリソースをベースとする MTC の Web コンソールおよび API により、namespace の粒度でステートフルおよびステートレスのアプリケーションワークロードを移行できます。

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

移行フックを使用して、移行中の特定の時点で Ansible Playbook を実行できます。フックは移行計画の作成時に追加されます。

2.1.1. MTC (Migration Toolkit for Containers) ワークフロー

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

(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)を移行します。

  • カスタムリソース定義 (CRD) およびカスタムリソース定義 (CRD): MTC は、namespace レベルに存在する CR およびそれらの CR にリンクされた CRB を自動的に移行します。

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

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

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

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

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

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

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

      注記

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

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

      注記

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

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

    • Stage (オプション) は、アプリケーションを停止せずにデータをターゲットクラスターにコピーします。

      ステージングは、移行前にほとんどのデータがターゲットにコピーされるように複数回実行することができます。これにより、移行時間やアプリケーションのダウンタイムが最小限に抑えられます。

    • Migrate は、ソースクラスターでアプリケーションを停止し、ターゲットクラスターでそのリソースを再作成します。オプションで、アプリケーションを停止せずにワークロードを移行できます。
OCP 3 から 4 のアプリケーション移行

2.1.2. MTC (Migration Toolkit for Containers) カスタムリソース

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

2.1.3. データのコピー方法

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

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

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

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

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

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

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

AWS、Google Cloud Provider、および Microsoft Azure は、スナップショットのコピー方法をサポートします。

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

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

2.1.4. 移行フックについて

移行フックを使用して、MTC (Migration Toolkit for Containers) を使用した移行中の特定の時点でカスタムコードを実行できます。単一の移行計画に最大 4 つの移行フックを追加し、各フックを移行の異なるフェーズで実行できます。

移行フックは、アプリケーションの休止状態のカスタマイズ、サポート外のデータタイプの手動の移行、および移行後のアプリケーションの更新などのタスクを実行します。

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

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

Ansible Playbook またはカスタムフックコンテナーを使用してフックを作成できます。

Ansible Playbook

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

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

オプション: デフォルトイメージの代わりに、追加の Ansible モジュールまたはツールを含むカスタム Ansible ランタイムイメージを使用できます。

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

Ansible Playbook またはカスタムコードを含むカスタムフックコンテナーを作成できます。

2.2. MTC (Migration Toolkit for Containers) のインストールおよびアップグレード

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4.5 ターゲットクラスターおよび 4.1 ソースクラスターにインストールできます。

MTC はデフォルトでターゲットクラスターにインストールされます。MTC を OpenShift Container Platform 3 クラスター、またはリモートクラスターにインストールできます。

2.2.1. 接続された環境での MTC (Migration Toolkit for Containers) のインストール

接続された環境で MTC (Migration Toolkit for Containers) をインストールできます。

重要

すべてのクラスターに同じ MTC バージョンをインストールする必要があります。

2.2.1.1. Migration Toolkit for Containers の OpenShift Container Platform 4.5 ターゲットクラスターへのインストール

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4.5 ターゲットクラスターにインストールできます。

前提条件

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

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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 が実行されていることを確認します。

2.2.1.2. OpenShift Container Platform 4.1 ソースクラスターへの Migration Toolkit for Containers Operator のインストール

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

前提条件

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

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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. migration-controller カスタムリソースマニフェストで以下のパラメーターを更新します。

    spec:
    ...
      migration_controller: false
      migration_ui: false
    ...
      deprecated_cors_configuration: true 1
    1
    deprecated_cors_configuration パラメーターとその値を追加します。
  8. Create をクリックします。
  9. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

2.2.2. 制限された環境での Migration Toolkit for Containers Operator のインストール

制限された環境で Migration Toolkit for Containers Operator をインストールできます。

重要

すべてのクラスターに同じ MTC バージョンをインストールする必要があります。

OpenShift Container Platform 4 のカスタム Operator カタログイメージをビルドし、これをローカルミラーイメージレジストリーにプッシュし、Operator Lifecycle Manager (OLM) をローカルレジストリーから Migration Toolkit for Containers Operator をインストールするように設定できます。

2.2.2.1. Operator カタログイメージのビルド

クラスター管理者は、Operator Lifecycle Manager (OLM) によって使用される Package Manifest Format に基づいてカスタム Operator カタログイメージをビルドできます。カタログイメージは、Docker v2-2 をサポートするコンテナーイメージレジストリーにプッシュできます。ネットワークが制限された環境のクラスターの場合、このレジストリーには、ネットワークが制限されたクラスターのインストール時に作成されたミラーレジストリーなど、クラスターにネットワークアクセスのあるレジストリーを使用できます。

重要

OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

以下の例では、お使いのネットワークとインターネットの両方にアクセスできるミラーレジストリーを使用することを前提としています。

注記

Windows および macOS のバージョンは oc adm catalog build コマンドを提供しないため、この手順では oc クライアントの Linux バージョンのみを使用できます。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • oc バージョン 4.3.5+ Linux クライアント
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • quay.io アカウントがアクセスできるプライベート namespace を使用している場合、Quay 認証トークンを設定する必要があります。quay.io 認証情報を使用してログイン API に対して要求を行うことにより、--auth-token フラグで使用できる AUTH_TOKEN 環境変数を設定します。

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

手順

  1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

    $ podman login <registry_host_name>

    また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

    $ podman login registry.redhat.io
  2. Quay.io から redhat-operators カタログをベースにカタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    App Registry インスタンスからのプルに使用する組織 (namespace)。
    2
    ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--fromose-operator-registry ベースイメージに設定します。
    3
    --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64linux/ppc64le、および linux/s390x です。
    4
    カタログイメージに名前を付け、v1 などのタグを追加します。
    5
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    6
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    7
    オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

    出力例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

    無効なマニフェストが Red Hat のカタログに誤って導入されることあります。これが実際に生じる場合には、以下のようなエラーが表示される可能性があります。

    エラーのある出力の例

    ...
    INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
    W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
    Uploading ... 244.9kB/s

    通常、これらのエラーは致命的なエラーではなく、該当する Operator パッケージにインストールする予定の Operator やその依存関係が含まれない場合、それらを無視することができます。

2.2.2.2. ネットワークが制限された環境向けの OperatorHub の設定

クラスター管理者は、カスタム Operator カタログイメージを使用し、OLM および OperatorHub をネットワークが制限された環境でローカルコンテンツを使用するように設定できます。この例では、以前にビルドされ、サポートされているレジストリーにプッシュされたカスタム redhat-operators カタログイメージを使用します。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • サポートされているレジストリーにプッシュされるカスタム Operator カタログイメージ
  • oc version 4.3.5+
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

手順

  1. oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。以下のいずれかを選択できます。

    • コマンドのデフォルト動作で、マニフェストの生成後にすべてのイメージコンテンツをミラーレジストリーに自動的にミラーリングできるようにします。または、
    • --manifests-only フラグを追加して、ミラーリングに必要なマニフェストのみを生成しますが、これにより、イメージコンテンツがレジストリーに自動的にミラーリングされる訳ではありません。これは、ミラーリングする内容を確認するのに役立ちます。また、コンテンツのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、そのファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。

    ネットワークアクセスが無制限のワークステーションで、以下のコマンドを実行します。

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v1 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' \4
        [--manifests-only] 5
    1
    Operator カタログイメージを指定します。
    2
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    3
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    4
    このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。
    5
    オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。
    警告

    --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

    出力例

    using database path mapping: /:/tmp/190214037
    wrote database to /tmp/190214037
    using database at: /tmp/190214037/bundles.db 1
    ...

    1
    コマンドで生成される一時的なデータベース。

    コマンドの実行後に、<image_name>-manifests/ ディレクトリーが現在のディレクトリーに作成され、以下のファイルが生成されます。

    • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。
    • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。
  2. 直前の手順で --manifests-only フラグを使用して、コンテンツのサブセットのみをミラーリングする場合は、以下を実行します。

    1. mapping.txt ファイルのイメージの一覧を仕様に変更します。ミラーリングするイメージのサブセットの名前とバージョンが不明な場合は、以下の手順で確認します。

      1. oc adm catalog mirror コマンドで生成された一時的なデータベースに対して sqlite3 ツールを実行し、一般的な検索クエリーに一致するイメージの一覧を取得します。出力は、後に mapping.txt ファイルを編集する方法を通知するのに役立ちます。

        たとえば、clusterlogging.4.3 の文字列のようなイメージの一覧を取得するには、以下を実行します。

        $ echo "select * from related_image \
            where operatorbundle_name like 'clusterlogging.4.3%';" \
            | sqlite3 -line /tmp/190214037/bundles.db 1
        1
        oc adm catalog mirror コマンドの直前の出力を参照し、データベースファイルのパスを見つけます。

        出力例

        image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        
        image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        ...

      2. 直前の手順で取得した結果を使用して mapping.txt ファイルを編集し、ミラーリングする必要のあるイメージのサブセットのみを追加します。

        たとえば、前述の出力例の image 値を使用して、mapping.txt ファイルに以下の一致する行が存在することを確認できます。

        mapping.txt の一致するイメージマッピング。

        registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

        この例では、これらのイメージのみをミラーリングする場合に、mapping.txt ファイルの他のすべてのエントリーを削除し、上記の 2 行のみを残します。

    2. ネットワークアクセスが無制限のワークステーション上で、変更した mapping.txt ファイルを使用し、 oc image mirror コマンドを使用してイメージをレジストリーにミラーリングします。

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt
      警告

      --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。

  3. ImageContentSourcePolicy オブジェクトを適用します。

    $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml
  4. カタログイメージを参照する CatalogSource オブジェクトを作成します。

    1. 仕様を以下のように変更し、これを catalogsource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc
      1
      Operator カタログイメージを指定します。
    2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc create -f catalogsource.yaml
  5. 以下のリソースが正常に作成されていることを確認します。

    1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

ネットワークが制限された環境の OpenShift Container Platform クラスター Web コンソールで、OperatorHub ページから Operator をインストールできます。

2.2.2.3. 制限された環境での Migration Toolkit for Containers の OpenShift Container Platform 4.5 ターゲットクラスターへのインストール

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4.5 ターゲットクラスターにインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • カスタム Operator カタログを作成し、これをミラーレジストリーにプッシュする必要があります。
  • ミラーレジストリーから Migration Toolkit for Containers Operator をインストールするように OLM を設定している必要があります。

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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 が実行されていることを確認します。

2.2.2.4. 制限された環境での Migration Toolkit for Containers の OpenShift Container Platform 4.1 ソースクラスターへのインストール

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

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • カスタム Operator カタログを作成し、これをミラーレジストリーにプッシュする必要があります。
  • ミラーレジストリーから Migration Toolkit for Containers Operator をインストールするように OLM を設定している必要があります。

手順

  1. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。
  2. Migration Toolkit for Containers Operator を選択し、Install をクリックします。

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  3. Install をクリックします。

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

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

2.2.3. MTC (Migration Toolkit for Containers) のアップグレード

MTC (Migration Toolkit for Containers) は、OpenShift Container Platform Web コンソールを使用してアップグレードできます。

重要

同じ MTC バージョンがすべてのクラスターにインストールされていることを確認する必要があります。

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

2.2.3.1. OpenShift Container Platform 4 クラスターでの MTC (Migration Toolkit for Containers) のアップグレード

MTC (Migration Toolkit for Containers) は OpenShift Container Platform Web コンソールを使用して OpenShift Container Platform 4 クラスターでアップグレードできます。

前提条件

  • 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. MTC を ソース クラスターでアップグレードする場合は、MigrationController カスタムリソース (CR) マニフェストで以下のパラメーターを更新します。

    spec:
    ...
      migration_controller: false
      migration_ui: false
    ...
      deprecated_cors_configuration: true

    ターゲットクラスターの MigrationController CR マニフェストを更新する必要はありません。

  10. Create をクリックします。
  11. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

2.2.3.2. MTC 1.3 から 1.4 へのアップグレード

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

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

前提条件

  • MTC 1.3 がインストールされている必要があります。
  • 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

2.3. レプリケーションリポジトリーのオブジェクトストレージの設定

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

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

以下のストレージプロバイダーがサポートされています。

制限された環境では、内部でホストされるレプリケーションリポジトリーを作成できます。

前提条件

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

2.3.1. Multi-Cloud Object Gateway ストレージバケットをレプリケーションリポジトリーとして設定する

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

2.3.1.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 プロジェクトに表示されます。

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

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

手順

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

    $ oc login
  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
    非常に小規模なクラスターの場合、cpu の値を 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-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    永続ボリュームプール内のボリューム数を指定します。
    2
    ボリュームのサイズを指定します。
    3
    ストレージクラスを作成します。
  5. BackingStore オブジェクトを作成します。

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

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

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

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    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

2.3.2. AWS S3 ストレージバケットをレプリケーションリポジトリーとして設定する

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_name> \ 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_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 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 を記録します。

2.3.3. 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_name> 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

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

2.4. アプリケーションの移行

MTC (Migration Toolkit for Containers) の Web コンソールまたはコマンドラインでアプリケーションを移行できます。

2.4.1. 前提条件

MTC (Migration Toolkit for Containers) には以下の要件があります。

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • MTC のバージョンは、すべてのクラスターで同一である必要があります。
  • クラスター:

    • ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
    • migration-controller Pod が実行されているクラスターには他のクラスターへの無制限のネットワークアクセスが必要です。
    • クラスターには、相互への無制限のネットワークアクセスが必要です。
    • クラスターには、レプリケーションリポジトリーへの無制限のネットワークアクセスが必要です。
    • クラスターは、ポート 443 で OpenShift ルートを使用して通信できる必要があります。
    • クラスターには、Critical (重大) 状態があってはなりません。
    • クラスターは Ready (準備) 状態である必要があります。
  • ボリュームの移行:

    • 永続ボリューム (PV) は有効である必要があります。
    • PV は永続ボリューム要求にバインドされる必要があります。
    • move メソッドを使用して PV をコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。
    • スナップショット のコピー方法を使用して PV をコピーする場合、以下の前提条件が適用されます。

      • クラウドプロバイダーはスナップショットをサポートしている必要があります。
      • ボリュームに同じクラウドプロバイダーがなければなりません。
      • ボリュームは同じ地理的リージョンにある必要があります。
      • ボリュームには同じストレージクラスがなければなりません。
  • プロキシー環境でボリュームの直接移行を実行する場合、Stunnel の TCP プロキシーを設定する必要があります。
  • イメージの直接移行を実行する場合、ソースクラスターの内部レジストリーを外部トラフィックに公開する必要があります。

2.4.1.1. CA 証明書バンドルファイルの作成

自己署名証明書を使用して 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 バンドルファイルの名前を指定します。

2.4.1.2. ボリュームの直接移行のためのプロキシー設定

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

注記

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

前提条件

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

手順

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

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. stunnel_tcp_proxy パラメーターを追加します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    Stunnel プロキシーを指定します: http://<user_name>:<password>@<ip_address>:<port>
  4. マニフェストを migration-controller.yaml として保存します。
  5. 更新したマニフェストを適用します。

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

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

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

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

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

2.4.1.3.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') }}"

2.4.1.4. 追加リソース

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

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

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

2.4.2.2. クラスターの Migration Toolkit for Containers 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: イメージの直接移行を使用している場合、ソースクラスターのイメージレジストリーへの公開されたルートを指定します (例: www.example.apps.cluster.com)。

      ポートを指定できます。デフォルトのポートは 5000 です。

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

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

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

前提条件

  • データを移行するには、オブジェクトストレージバケットを設定する必要があります。

手順

  1. MTC の Web コンソールで、Replication repositories をクリックします。
  2. Add repository をクリックします。
  3. Storage provider type を選択し、以下のフィールドに入力します。

    • AWS (AWS S3、MCG、および汎用 S3 プロバイダーの場合):

      • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
      • S3 bucket name: 作成した S3 バケットの名前を指定します。
      • S3 bucket region: S3 バケットリージョンを指定します。AWS S3 の場合に必須です。Optional (他の 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 provider secret access key: AWS には <AWS_ACCESS_KEY_ID> を指定するか、または MCG には S3 プロバイダーシークレットアクセスキーを指定します。
      • Require SSL verification: 汎用 S3 プロバイダーを使用している場合は、このチェックボックスをクリアします。
      • カスタム CA バンドルを使用する場合は、Browse をクリックし、Base64 でエンコードされた CA バンドルファイルを参照します。
    • 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 一覧に表示されます。

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

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

前提条件

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

手順

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

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

  4. Source cluster を選択します。
  5. Target clusterを選択します。
  6. Replication repository を選択します。
  7. 移行するプロジェクトを選択し、Next をクリックします。
  8. Source clusterTarget cluster、および Repository を選択し、 Next をクリックします。
  9. Namespaces ページで、移行するプロジェクトを選択し、 Next をクリックします。
  10. Persistent volumes ページで、各 PV の Migration type をクリックします。

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

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

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

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

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

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

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

  17. Next をクリックします。
  18. オプション: Hooks ページで 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 をクリックします。
  19. Finish をクリックします。

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

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

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

注記

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

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

前提条件

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

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

手順

  1. ソースクラスターにログインします。
  2. 古いイメージを削除します。

    $ oc adm prune images
  3. MTC の Web コンソールにログインし、Migration plans をクリックします。
  4. 移行計画の横にある Options メニュー kebab をクリックし、Stage を選択して、アプリケーションを停止せずにソースクラスターからターゲットクラスターにデータをコピーします。

    実際の移行時間を短縮するには、Stage を複数回実行することができます。

  5. アプリケーションのワークロードを移行する準備ができたら、移行計画の横にある Options メニュー kebab をクリックし、Migrate を選択します。
  6. オプション: Migrate ウィンドウで Do not stop applications on the source cluster during migration を選択できます。
  7. Migrate をクリックします。
  8. 移行が完了したら、アプリケーションが OpenShift Container Platform Web コンソールで正常に移行されていることを確認します。

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

2.4.3. コマンドラインでのアプリケーションの移行

MTC カスタムリソース (CR) を使用して、コマンドラインでアプリケーションを移行できます。

アプリケーションをローカルクラスターからリモートクラスター、リモートクラスターからローカルクラスター、およびリモートクラスター間で移行できます。

MTC の用語

クラスターの設定に関連して、以下の用語が使用されます。

  • host クラスター:

    • migration-controller Pod は hostクラスターで実行されます。
    • host クラスターでは、直接のイメージ移行に公開されたセキュアなレジストリールートは不要です。
  • ローカルクラスター: ローカルクラスターは host クラスターと同じである場合が多くありますが、これは必須ではありません。
  • リモートクラスター:

    • リモートクラスターには、直接のイメージ移行に公開されるセキュアなレジストリールートが必要です。
    • リモートクラスターには、migration-controller サービスアカウントトークンが含まれる Secret CR が必要です。

移行の実行に関連して、以下の用語が使用されます。

  • ソースクラスター: アプリケーションの移行元となるクラスター。
  • 宛先クラスター: アプリケーションが移行されるクラスター。

2.4.3.1. MTC (Migration Toolkit for Containers) を使用したアプリケーションの移行

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

アプリケーションをローカルクラスターからリモートクラスター、リモートクラスターからローカルクラスター、およびリモートクラスター間で移行できます。

この手順では、間接的および直接的な移行を実行する方法を説明します。

  • 間接的な移行: イメージ、ボリューム、および Kubernetes オブジェクトはソースクラスターからレプリケーションリポジトリーにコピーされ、その後にレプリケーションリポジトリーから宛先クラスターにコピーされます。
  • 直接的な移行: イメージまたはボリュームはソースクラスターから宛先クラスターに直接コピーされます。イメージとボリュームの直接的な移行には、パフォーマンス上の大きなメリットがあります。

以下のカスタムリソース (CR) を作成して移行を実行します。

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

    migration-controller Pod は hostクラスターで実行されます。

  • Secret CR: リモートクラスターまたはストレージの認証情報が含まれます。
  • MigStorage CR: レプリケーションリポジトリーを定義します。

    異なるストレージプロバイダーには、MigStorage CR マニフェストで異なるパラメーターが必要です。

  • MigPlan CR: 移行計画を定義します。
  • MigMigration CR: 関連付けられた MigPlan で定義された移行を実行します。

    以下の目的で、単一の MigPlan CR に複数の MigMigration CR を作成できます。

  • 移行を実行する前に、アプリケーションを停止せずにほとんどのデータをコピーする段階移行 (Stage migration) を実行する。段階移行により、移行のパフォーマンスが向上します。
  • 実行中の移行を取り消す。
  • 完了した移行をロールバックする

前提条件

  • すべてのクラスターで cluster-admin 権限が必要です。
  • OpenShift Container Platform CLI (oc) をインストールする必要があります。
  • すべてのクラスターに MTC (Migration Toolkit for Containers Operator) をインストールする必要があります。
  • インストールされた MTC (Migration Toolkit for Containers Operator) の version は、すべてのクラスターで同一である必要があります。
  • オブジェクトストレージをレプリケーションリポジトリーとして設定する必要があります。
  • イメージの直接的な移行を実行している場合、すべてのリモートクラスターでセキュアなレジストリールートを公開する必要があります。
  • ボリュームの直接移行を使用している場合、ソースクラスターには HTTP プロキシーを設定することはできません。

手順

  1. host-cluster.yaml という host クラスターの MigCluster CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host クラスターの MigCluster CR を作成します。

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. 各リモートクラスターに、cluster-secret.yaml という Secret CR マニフェストを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    リモートクラスターの base64 でエンコードされた migration-controller サービスアカウント (SA) トークンを指定します。

    以下のコマンドを実行して SA トークンを取得できます。

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. それぞれのリモートクラスターに Secret CR を作成します。

    $ oc create -f cluster-secret.yaml
  5. それぞれのリモートクラスターに、remote-cluster.yaml という MigCluster CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    オプション: 直接的なイメージの移行を実行する場合、公開されるレジストリールートを指定します (例: docker-registry-default.apps.example.com)。
    2
    SSL 検証は、false の場合に有効になります。CA 証明書は、true の場合は必要ではなく、チェックされません。
    3
    リモートクラスターの Secret CR を指定します。
    4
    リモートクラスターの URL を指定します。
  6. それぞれのリモートクラスターについて MigCluster CR を作成します。

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. すべてのクラスターが Ready 状態にあることを確認します。

    $ oc describe cluster <cluster_name>
  8. storage-secret.yaml というレプリケーションリポジトリーの Secret CR マニフェストを作成します。

    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
    1
    キー ID を base64 形式で指定します。
    2
    シークレットキーを base64 形式で指定します。

    AWS 認証情報はデフォルトで base64 でエンコードされます。別のストレージプロバイダーを使用している場合、それぞれのキーを使用して以下のコマンドを実行して、認証情報をエンコードする必要があります。

    $ echo -n "<key>" | base64 -w 0 1
    1
    キー ID またはシークレットキーを指定します。どちらの値も base64 でエンコードする必要があります。
  9. レプリケーションリポジトリーの Secret CR を作成します。

    $ oc create -f storage-secret.yaml
  10. migstorage.yaml というレプリケーションリポジトリーの MigStorage CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    バケット名を指定します。
    2
    オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。
    3
    ストレージプロバイダーを指定します。
    4
    オプション: スナップショットを使用してデータをコピーする場合は、オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。
    5
    オプション: スナップショットを使用してデータをコピーする場合は、ストレージプロバイダーを指定します。
  11. MigStorage CR を作成します。

    $ oc create -f migstorage.yaml -n openshift-migration
  12. MigStorage CR が Ready 状態にあることを確認します。

    $ oc describe migstorage <migstorage_name>
  13. migplan.yaml という MigPlan CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    false の場合、直接的なイメージ移行が有効にされます。
    2
    false の場合、直接的なボリューム移行が有効にされます。
    3
    MigStorage CR インスタンスの名前を指定します。
    4
    移行する namespace を 1 つ以上指定します。
    5
    ソースクラスター MigCluster インスタンスの名前を指定します。
  14. MigPlan CR を作成します。

    $ oc create -f migplan.yaml -n openshift-migration
  15. MigPlan インスタンスを表示し、そのインスタンスが Ready 状態にあることを確認します。

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. migmigration.yaml という MigMigration CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    MigPlan CR 名を指定します。
    2
    true の場合、ソースクラスターの Pod は停止します。
    3
    true の場合、アプリケーションを停止せずにほとんどのデータをコピーする段階移行が実行されます。
    4
    true の場合、完了した移行がロールバックされます。
  17. MigMigration CR を作成し、MigPlan CR に定義された移行を開始します。

    $ oc create -f migmigration.yaml -n openshift-migration
  18. MigMigration CR を監視して移行の進捗を確認します。

    $ oc watch migmigration <migmigration_name> -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:       my_application
        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

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

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

2.4.3.2.1. DirectImageMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
ソースクラスターの MigCluster CR 名を指定します。
2
宛先クラスターの MigCluster CR 名を指定します。
3
移行するイメージが含まれる namespace を 1 つ以上指定します。
2.4.3.2.2. DirectImageStreamMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
ソースクラスターの MigCluster CR 名を指定します。
2
宛先クラスターの MigCluster CR 名を指定します。
3
イメージストリーム名を指定します。
4
ソースクラスターにイメージストリーム namespace を指定します。
5
宛先クラスターでイメージストリーム namespace を指定します。
2.4.3.2.3. DirectVolumeMigration

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

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

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

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

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

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

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

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  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.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
オプション: migration-controller Pod がこのクラスターで実行されていない場合には、クラスター名を更新します。
2
true の場合、migration-controller Pod がこのクラスターで実行されます。
3
オプション: ストレージプロバイダーが Microsoft Azure の場合は、リソースグループを指定します。
4
オプション: 自己署名 CA 証明書の証明書バンドルを作成しており、insecureな パラメーターの値が false の場合、base64 でエンコードされた証明書バンドルを指定します。
5
SSL 検証は、false の場合に有効になります。
6
true の場合、クラスターが検証されます。
7
true の場合、ステージ Pod の作成後に restic Pod がソースクラスターで再起動します。
8
オプション: 直接的なイメージ移行を使用している場合、リモートクラスターの公開されるレジストリーパスを指定します。
9
リモートクラスターの URL を指定します。
10
リモートクラスターの Secret CR の名前を指定します。
2.4.3.2.7. MigHook

MigHook CR は、Ansible Playbook、または移行の特定の段階でタスクを実行するカスタムイメージを定義します。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 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
フックが実行されるクラスターとして source または destination を指定します。
2.4.3.2.8. MigMigration

MigMigration CR は関連付けられる MigPlan CR を実行します。

以下のシナリオについて、同じ MigPlan CR に関連付けられた複数の MigMigration CR を作成できます。

  • stage (段階) 移行または増分移行を複数回実行して、ソースクラスターで Pod を停止せずにデータをコピーすることができます。段階移行の実行により、実際の移行のパフォーマンスが向上します。
  • 進行中の移行を取り消すことができます。
  • 移行をロールバックできます。
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  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_ref> 7
    namespace: openshift-migration
1
true の場合、進行中の移行が取り消されます。
2
true の場合、完了した移行がロールバックされます。
3
true の場合、データが増分的にコピーされ、ソースクラスターは停止しません。
4
true の場合、ソースクラスターの Pod は、移行の Backup ステージの後に 0 にスケーリングされます。
5
true の場合、移行中に適用されるラベルとアノテーションは保持されます。
6
true の場合、宛先クラスターで移行される Pod のステータスはチェックされ、Running 状態にない Pod の名前が返されます。
7
migPlanRef.name: 関連付けられる MigPlan CR の名前を指定します。
2.4.3.2.9. MigPlan

MigPlan CR は移行計画のパラメーターを定義します。これには、同じパラメーターで移行される仮想マシンのグループが含まれます。

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

MigStorage CR はレプリケーションリポジトリーのオブジェクトストレージを記述します。Amazon Web Services、Microsoft Azure、Google Cloud Storage、および汎用 S3 互換クラウドストレージ (例: Minio または NooBaa) を設定できます。

プロバイダーごとに異なるパラメーターが必要です。

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

2.4.4. 追加リソース

2.4.5. 移行計画の設定

移行するオブジェクト数を増やしたり、移行からリソースを除外したりできます。

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

2.4.5.2. 移行計画からのリソースの除外

移行についてのリソース負荷を減らしたり、別のツールでイメージや 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
    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

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

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

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

注記

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

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

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

手順

  1. openshift-migration namespace の MigMigration CR を一覧表示します。

    $ oc get migmigration -n openshift-migration

    出力例

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

  2. MigMigration CR を検査します。

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

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

MigMigration の出力例

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

PV データを記述する Velero バックアップ CR #2 の出力例

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

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

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

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

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

手順

  1. mig-log-reader Pod を取得します。

    $ oc -n openshift-migration get pods | grep log
  2. 以下のコマンドを入力して、単一の移行ログを表示します。

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    -c plain オプションは、色なしでログを表示します。

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

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

手順

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

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

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

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

2.5.4. 非推奨の API の更新

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

Some namespaces contain GVKs incompatible with destination cluster

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

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

手順

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

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

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

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    MigPlan CR UID を記録します。
    2
    gvks セクションに一覧表示された非推奨の API を記録します。
  3. MigPlan UID に関連付けられた MigMigration 名を取得します。

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    MigPlan CR UID を指定します。
  4. MigMigration 名に関連付けられた MigMigration UID を取得します。

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    MigMigration 名を指定します。
  5. MigMigration UID に関連付けられた Velero バックアップ名を取得します。

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    MigMigration UID を指定します。
  6. ストレージプロバイダーのコマンドを実行して、Velero バックアップの内容をローカルマシンにダウンロードします。

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。
    • GCP

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      バックアップ名とローカルバックアップのディレクトリー名を指定します。
  7. Velero バックアップアーカイブファイルを展開します。

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 非推奨のそれぞれの API でオフラインモードで oc convert を実行します。

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

    $ oc create -f <gvk>.json

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

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

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

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

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

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

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

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

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

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

手順

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

    $ oc logs <MigrationUI_Pod> -n openshift-migration

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

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

出力例

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

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

手順

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

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

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

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

出力例

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

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

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

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

手順

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

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

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

    出力例

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

  3. PodVolumeRestore CR を表示します。

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

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

    出力例

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

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

    $ oc logs -f <restic-nr2v5>

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

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

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

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

手順

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

    $ oc describe migmigration <pod_name> -n openshift-migration

    出力には、以下のようなステータス情報が含まれます。

    出力例

    ...
    Some or all transfer pods are not running for more than 10 mins on destination cluster
    ...

  2. ソースクラスターで、移行した namespace の詳細を取得します。

    $ oc get namespace <namespace> -o yaml 1
    1
    移行した namespace を指定します。
  3. ターゲットクラスターで、移行した namespace を編集します。

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

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. 移行計画を再度実行します。

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

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

2.5.7.1. Velero コマンド構文

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

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

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

2.5.7.2. Help コマンド

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

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

2.5.7.3. describe コマンド

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

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

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

2.5.7.4. logs コマンド

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

velero <resource> logs <resource_id>

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

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

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

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

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

手順

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

    $ oc get migmigration <migmigration> -o yaml
    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings
  2. Velero describe コマンドを使用して Restore CR のステータスを確認します。

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. Velero logs コマンドを使用して Restore CR ログを確認します。

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    Restore CR のログエラーメッセージの the server could not find the requested resource は、部分的に失敗した移行の原因を示します。

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

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

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

手順

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

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

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

2.5.9. 移行のロールバック

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

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

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

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

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

手順

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

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

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

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

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

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

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

手順

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

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

2.5.10. 既知の問題

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

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

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

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

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

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

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

2.5.11. 追加リソース

第3章 OpenShift Container Platform 4.2 以降からの移行

3.1. 移行ツールおよび前提条件

アプリケーションワークロードを、MTC (Migration Toolkit for Containers) を使用して OpenShift Container Platform 4.2 から 4.5 に移行できます。MTC を使用すると、移行を制御し、アプリケーションのダウンタイムを最小限に抑えることができます。

注記

ソースおよびターゲットクラスターが正しく設定されている場合、同じバージョンの OpenShift Container Platform クラスター間で移行できます (4.2 から 4.2 または 4.3 から 4.3 への移行など)。

Kubernetes カスタムリソースをベースとする MTC の Web コンソールおよび API により、namespace の粒度でステートフルおよびステートレスのアプリケーションワークロードを移行できます。

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

移行フックを使用して、移行中の特定の時点で Ansible Playbook を実行できます。フックは移行計画の作成時に追加されます。

3.1.1. MTC (Migration Toolkit for Containers) ワークフロー

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

(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)を移行します。

  • カスタムリソース定義 (CRD) およびカスタムリソース定義 (CRD): MTC は、namespace レベルに存在する CR およびそれらの CR にリンクされた CRB を自動的に移行します。

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

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

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

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

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

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

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

      注記

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

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

      注記

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

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

    • Stage (オプション) は、アプリケーションを停止せずにデータをターゲットクラスターにコピーします。

      ステージングは、移行前にほとんどのデータがターゲットにコピーされるように複数回実行することができます。これにより、移行時間やアプリケーションのダウンタイムが最小限に抑えられます。

    • Migrate は、ソースクラスターでアプリケーションを停止し、ターゲットクラスターでそのリソースを再作成します。オプションで、アプリケーションを停止せずにワークロードを移行できます。
OCP 3 から 4 のアプリケーション移行

3.1.2. MTC (Migration Toolkit for Containers) カスタムリソース

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

3.1.3. データのコピー方法

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

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

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

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

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

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

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

AWS、Google Cloud Provider、および Microsoft Azure は、スナップショットのコピー方法をサポートします。

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

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

3.1.4. 移行フックについて

移行フックを使用して、MTC (Migration Toolkit for Containers) を使用した移行中の特定の時点でカスタムコードを実行できます。単一の移行計画に最大 4 つの移行フックを追加し、各フックを移行の異なるフェーズで実行できます。

移行フックは、アプリケーションの休止状態のカスタマイズ、サポート外のデータタイプの手動の移行、および移行後のアプリケーションの更新などのタスクを実行します。

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

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

Ansible Playbook またはカスタムフックコンテナーを使用してフックを作成できます。

Ansible Playbook

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

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

オプション: デフォルトイメージの代わりに、追加の Ansible モジュールまたはツールを含むカスタム Ansible ランタイムイメージを使用できます。

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

Ansible Playbook またはカスタムコードを含むカスタムフックコンテナーを作成できます。

3.2. MTC (Migration Toolkit for Containers) のインストールおよびアップグレード

Migration Toolkit for Containers Operator を OpenShift Container Platform 4.5 ターゲットクラスターおよび 4.2 ソースクラスターにインストールできます。

MTC はデフォルトでターゲットクラスターにインストールされます。オプション: MTC を OpenShift Container Platform 3 クラスターまたはリモートクラスターにインストールできます。

重要

すべてのクラスターに同じ MTC バージョンをインストールする必要があります。

3.2.1. 接続された環境での MTC (Migration Toolkit for Containers) のインストール

接続された環境で MTC (Migration Toolkit for Containers) をインストールできます。

3.2.1.1. Migration Toolkit for Containers の OpenShift Container Platform 4.5 ターゲットクラスターへのインストール

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4.5 ターゲットクラスターにインストールできます。

前提条件

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

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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.2.1.2. OpenShift Container Platform 4.2 ソースクラスターへの Migration Toolkit for Containers Operator のインストール

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

前提条件

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

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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. migration-controller カスタムリソースマニフェストの以下のパラメーターを更新します。

    spec:
    ...
      migration_controller: false
      migration_ui: false
  8. Create をクリックします。
  9. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

3.2.2. 制限された環境での Migration Toolkit for Containers Operator のインストール

制限された環境で Migration Toolkit for Containers Operator をインストールできます。

重要

すべてのクラスターに同じ MTC バージョンをインストールする必要があります。

OpenShift Container Platform 4 のカスタム Operator カタログイメージをビルドし、これをローカルミラーイメージレジストリーにプッシュし、Operator Lifecycle Manager (OLM) をローカルレジストリーから Migration Toolkit for Containers Operator をインストールするように設定できます。

3.2.2.1. Operator カタログイメージのビルド

クラスター管理者は、Operator Lifecycle Manager (OLM) によって使用される Package Manifest Format に基づいてカスタム Operator カタログイメージをビルドできます。カタログイメージは、Docker v2-2 をサポートするコンテナーイメージレジストリーにプッシュできます。ネットワークが制限された環境のクラスターの場合、このレジストリーには、ネットワークが制限されたクラスターのインストール時に作成されたミラーレジストリーなど、クラスターにネットワークアクセスのあるレジストリーを使用できます。

重要

OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

以下の例では、お使いのネットワークとインターネットの両方にアクセスできるミラーレジストリーを使用することを前提としています。

注記

Windows および macOS のバージョンは oc adm catalog build コマンドを提供しないため、この手順では oc クライアントの Linux バージョンのみを使用できます。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • oc バージョン 4.3.5+ Linux クライアント
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • quay.io アカウントがアクセスできるプライベート namespace を使用している場合、Quay 認証トークンを設定する必要があります。quay.io 認証情報を使用してログイン API に対して要求を行うことにより、--auth-token フラグで使用できる AUTH_TOKEN 環境変数を設定します。

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

手順

  1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

    $ podman login <registry_host_name>

    また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

    $ podman login registry.redhat.io
  2. Quay.io から redhat-operators カタログをベースにカタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    App Registry インスタンスからのプルに使用する組織 (namespace)。
    2
    ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--fromose-operator-registry ベースイメージに設定します。
    3
    --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64linux/ppc64le、および linux/s390x です。
    4
    カタログイメージに名前を付け、v1 などのタグを追加します。
    5
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    6
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    7
    オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

    出力例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

    無効なマニフェストが Red Hat のカタログに誤って導入されることあります。これが実際に生じる場合には、以下のようなエラーが表示される可能性があります。

    エラーのある出力の例

    ...
    INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
    W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
    Uploading ... 244.9kB/s

    通常、これらのエラーは致命的なエラーではなく、該当する Operator パッケージにインストールする予定の Operator やその依存関係が含まれない場合、それらを無視することができます。

3.2.2.2. ネットワークが制限された環境向けの OperatorHub の設定

クラスター管理者は、カスタム Operator カタログイメージを使用し、OLM および OperatorHub をネットワークが制限された環境でローカルコンテンツを使用するように設定できます。この例では、以前にビルドされ、サポートされているレジストリーにプッシュされたカスタム redhat-operators カタログイメージを使用します。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • サポートされているレジストリーにプッシュされるカスタム Operator カタログイメージ
  • oc version 4.3.5+
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

手順

  1. oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。以下のいずれかを選択できます。

    • コマンドのデフォルト動作で、マニフェストの生成後にすべてのイメージコンテンツをミラーレジストリーに自動的にミラーリングできるようにします。または、
    • --manifests-only フラグを追加して、ミラーリングに必要なマニフェストのみを生成しますが、これにより、イメージコンテンツがレジストリーに自動的にミラーリングされる訳ではありません。これは、ミラーリングする内容を確認するのに役立ちます。また、コンテンツのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、そのファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。

    ネットワークアクセスが無制限のワークステーションで、以下のコマンドを実行します。

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v1 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' \4
        [--manifests-only] 5
    1
    Operator カタログイメージを指定します。
    2
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    3
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    4
    このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。
    5
    オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。
    警告

    --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

    出力例

    using database path mapping: /:/tmp/190214037
    wrote database to /tmp/190214037
    using database at: /tmp/190214037/bundles.db 1
    ...

    1
    コマンドで生成される一時的なデータベース。

    コマンドの実行後に、<image_name>-manifests/ ディレクトリーが現在のディレクトリーに作成され、以下のファイルが生成されます。

    • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。
    • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。
  2. 直前の手順で --manifests-only フラグを使用して、コンテンツのサブセットのみをミラーリングする場合は、以下を実行します。

    1. mapping.txt ファイルのイメージの一覧を仕様に変更します。ミラーリングするイメージのサブセットの名前とバージョンが不明な場合は、以下の手順で確認します。

      1. oc adm catalog mirror コマンドで生成された一時的なデータベースに対して sqlite3 ツールを実行し、一般的な検索クエリーに一致するイメージの一覧を取得します。出力は、後に mapping.txt ファイルを編集する方法を通知するのに役立ちます。

        たとえば、clusterlogging.4.3 の文字列のようなイメージの一覧を取得するには、以下を実行します。

        $ echo "select * from related_image \
            where operatorbundle_name like 'clusterlogging.4.3%';" \
            | sqlite3 -line /tmp/190214037/bundles.db 1
        1
        oc adm catalog mirror コマンドの直前の出力を参照し、データベースファイルのパスを見つけます。

        出力例

        image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        
        image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        ...

      2. 直前の手順で取得した結果を使用して mapping.txt ファイルを編集し、ミラーリングする必要のあるイメージのサブセットのみを追加します。

        たとえば、前述の出力例の image 値を使用して、mapping.txt ファイルに以下の一致する行が存在することを確認できます。

        mapping.txt の一致するイメージマッピング。

        registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

        この例では、これらのイメージのみをミラーリングする場合に、mapping.txt ファイルの他のすべてのエントリーを削除し、上記の 2 行のみを残します。

    2. ネットワークアクセスが無制限のワークステーション上で、変更した mapping.txt ファイルを使用し、 oc image mirror コマンドを使用してイメージをレジストリーにミラーリングします。

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt
      警告

      --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。

  3. ImageContentSourcePolicy オブジェクトを適用します。

    $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml
  4. カタログイメージを参照する CatalogSource オブジェクトを作成します。

    1. 仕様を以下のように変更し、これを catalogsource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc
      1
      Operator カタログイメージを指定します。
    2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc create -f catalogsource.yaml
  5. 以下のリソースが正常に作成されていることを確認します。

    1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

ネットワークが制限された環境の OpenShift Container Platform クラスター Web コンソールで、OperatorHub ページから Operator をインストールできます。

3.2.2.3. 制限された環境での Migration Toolkit for Containers の OpenShift Container Platform 4.5 ターゲットクラスターへのインストール

MTC (Migration Toolkit for Containers) を OpenShift Container Platform 4.5 ターゲットクラスターにインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • カスタム Operator カタログを作成し、これをミラーレジストリーにプッシュする必要があります。
  • ミラーレジストリーから Migration Toolkit for Containers Operator をインストールするように OLM を設定している必要があります。

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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.2.2.4. 制限された環境での Migration Toolkit for Containers の OpenShift Container Platform 4.2 ソースクラスターへのインストール

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

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • カスタム Operator カタログを作成し、これをミラーレジストリーにプッシュする必要があります。
  • ミラーレジストリーから Migration Toolkit for Containers Operator をインストールするように OLM を設定している必要があります。

手順

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

    注記

    サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

  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.2.3. MTC (Migration Toolkit for Containers) のアップグレード

MTC (Migration Toolkit for Containers) は、OpenShift Container Platform Web コンソールを使用してアップグレードできます。

重要

同じ MTC バージョンがすべてのクラスターにインストールされていることを確認する必要があります。

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

3.2.3.1. OpenShift Container Platform 4 クラスターでの MTC (Migration Toolkit for Containers) のアップグレード

MTC (Migration Toolkit for Containers) は OpenShift Container Platform Web コンソールを使用して OpenShift Container Platform 4 クラスターでアップグレードできます。

前提条件

  • 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. MTC を ソース クラスターでアップグレードする場合は、MigrationController カスタムリソース (CR) マニフェストで以下のパラメーターを更新します。

    spec:
    ...
      migration_controller: false
      migration_ui: false

    ターゲットクラスターの MigrationController CR マニフェストを更新する必要はありません。

  10. Create をクリックします。
  11. WorkloadsPods をクリックし、MTC Pod が実行されていることを確認します。

3.2.3.2. MTC 1.3 から 1.4 へのアップグレード

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

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

前提条件

  • MTC 1.3 がインストールされている必要があります。
  • 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

3.3. レプリケーションリポジトリーのオブジェクトストレージの設定

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

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

以下のストレージプロバイダーがサポートされています。

制限された環境では、内部でホストされるレプリケーションリポジトリーを作成できます。

前提条件

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

3.3.1. Multi-Cloud Object Gateway ストレージバケットをレプリケーションリポジトリーとして設定する

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

3.3.1.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.3.1.2. Multi-Cloud Object Gateway ストレージバケットの作成

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

手順

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

    $ oc login
  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
    非常に小規模なクラスターの場合、cpu の値を 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-pv-pool-bs
      namespace: openshift-storage
    spec:
      pvPool:
        numVolumes: 3 1
        resources:
          requests:
            storage: 50Gi 2
        storageClass: gp2 3
      type: pv-pool
    1
    永続ボリュームプール内のボリューム数を指定します。
    2
    ボリュームのサイズを指定します。
    3
    ストレージクラスを作成します。
  5. BackingStore オブジェクトを作成します。

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

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

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

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: migstorage
      namespace: openshift-storage
    spec:
      bucketName: migstorage 1
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: mcg-pv-pool-bc
    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.3.2. AWS S3 ストレージバケットをレプリケーションリポジトリーとして設定する

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_name> \ 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_name>/*" 1
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::<bucket_name>" 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.3.3. 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_name> 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.3.4. 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.4. アプリケーションの移行

MTC (Migration Toolkit for Containers) の Web コンソールまたはコマンドラインでアプリケーションを移行できます。

3.4.1. 前提条件

MTC (Migration Toolkit for Containers) には以下の要件があります。

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • MTC のバージョンは、すべてのクラスターで同一である必要があります。
  • クラスター:

    • ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
    • migration-controller Pod が実行されているクラスターには他のクラスターへの無制限のネットワークアクセスが必要です。
    • クラスターには、相互への無制限のネットワークアクセスが必要です。
    • クラスターには、レプリケーションリポジトリーへの無制限のネットワークアクセスが必要です。
    • クラスターは、ポート 443 で OpenShift ルートを使用して通信できる必要があります。
    • クラスターには、Critical (重大) 状態があってはなりません。
    • クラスターは Ready (準備) 状態である必要があります。
  • ボリュームの移行:

    • 永続ボリューム (PV) は有効である必要があります。
    • PV は永続ボリューム要求にバインドされる必要があります。
    • move メソッドを使用して PV をコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。
    • スナップショット のコピー方法を使用して PV をコピーする場合、以下の前提条件が適用されます。

      • クラウドプロバイダーはスナップショットをサポートしている必要があります。
      • ボリュームに同じクラウドプロバイダーがなければなりません。
      • ボリュームは同じ地理的リージョンにある必要があります。
      • ボリュームには同じストレージクラスがなければなりません。
  • プロキシー環境でボリュームの直接移行を実行する場合、Stunnel の TCP プロキシーを設定する必要があります。
  • イメージの直接移行を実行する場合、ソースクラスターの内部レジストリーを外部トラフィックに公開する必要があります。

3.4.1.1. CA 証明書バンドルファイルの作成

自己署名証明書を使用して 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 バンドルファイルの名前を指定します。

3.4.1.2. ボリュームの直接移行のためのプロキシー設定

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

注記

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

前提条件

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

手順

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

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
  3. stunnel_tcp_proxy パラメーターを追加します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigrationController
    metadata:
      name: migration-controller
      namespace: openshift-migration
    ...
    spec:
      stunnel_tcp_proxy: <stunnel_proxy> 1
    1
    Stunnel プロキシーを指定します: http://<user_name>:<password>@<ip_address>:<port>
  4. マニフェストを migration-controller.yaml として保存します。
  5. 更新したマニフェストを適用します。

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

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

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

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

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

3.4.1.3.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') }}"

3.4.1.4. 追加リソース

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

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

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

3.4.2.2. クラスターの Migration Toolkit for Containers 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: イメージの直接移行を使用している場合、ソースクラスターのイメージレジストリーへの公開されたルートを指定します (例: www.example.apps.cluster.com)。

      ポートを指定できます。デフォルトのポートは 5000 です。

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

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

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

前提条件

  • データを移行するには、オブジェクトストレージバケットを設定する必要があります。

手順

  1. MTC の Web コンソールで、Replication repositories をクリックします。
  2. Add repository をクリックします。
  3. Storage provider type を選択し、以下のフィールドに入力します。

    • AWS (AWS S3、MCG、および汎用 S3 プロバイダーの場合):

      • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
      • S3 bucket name: 作成した S3 バケットの名前を指定します。
      • S3 bucket region: S3 バケットリージョンを指定します。AWS S3 の場合に必須です。Optional (他の 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 provider secret access key: AWS には <AWS_ACCESS_KEY_ID> を指定するか、または MCG には S3 プロバイダーシークレットアクセスキーを指定します。
      • Require SSL verification: 汎用 S3 プロバイダーを使用している場合は、このチェックボックスをクリアします。
      • カスタム CA バンドルを使用する場合は、Browse をクリックし、Base64 でエンコードされた CA バンドルファイルを参照します。
    • 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 一覧に表示されます。

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

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

前提条件

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

手順

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

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

  4. Source cluster を選択します。
  5. Target clusterを選択します。
  6. Replication repository を選択します。
  7. 移行するプロジェクトを選択し、Next をクリックします。
  8. Source clusterTarget cluster、および Repository を選択し、 Next をクリックします。
  9. Namespaces ページで、移行するプロジェクトを選択し、 Next をクリックします。
  10. Persistent volumes ページで、各 PV の Migration type をクリックします。

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

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

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

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

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

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

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

  17. Next をクリックします。
  18. オプション: Hooks ページで 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 をクリックします。
  19. Finish をクリックします。

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

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

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

注記

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

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

前提条件

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

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

手順

  1. ソースクラスターにログインします。
  2. 古いイメージを削除します。

    $ oc adm prune images
  3. MTC の Web コンソールにログインし、Migration plans をクリックします。
  4. 移行計画の横にある Options メニュー kebab をクリックし、Stage を選択して、アプリケーションを停止せずにソースクラスターからターゲットクラスターにデータをコピーします。

    実際の移行時間を短縮するには、Stage を複数回実行することができます。

  5. アプリケーションのワークロードを移行する準備ができたら、移行計画の横にある Options メニュー kebab をクリックし、Migrate を選択します。
  6. オプション: Migrate ウィンドウで Do not stop applications on the source cluster during migration を選択できます。
  7. Migrate をクリックします。
  8. 移行が完了したら、アプリケーションが OpenShift Container Platform Web コンソールで正常に移行されていることを確認します。

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

3.4.3. コマンドラインでのアプリケーションの移行

MTC カスタムリソース (CR) を使用して、コマンドラインでアプリケーションを移行できます。

アプリケーションをローカルクラスターからリモートクラスター、リモートクラスターからローカルクラスター、およびリモートクラスター間で移行できます。

MTC の用語

クラスターの設定に関連して、以下の用語が使用されます。

  • host クラスター:

    • migration-controller Pod は hostクラスターで実行されます。
    • host クラスターでは、直接のイメージ移行に公開されたセキュアなレジストリールートは不要です。
  • ローカルクラスター: ローカルクラスターは host クラスターと同じである場合が多くありますが、これは必須ではありません。
  • リモートクラスター:

    • リモートクラスターには、直接のイメージ移行に公開されるセキュアなレジストリールートが必要です。
    • リモートクラスターには、migration-controller サービスアカウントトークンが含まれる Secret CR が必要です。

移行の実行に関連して、以下の用語が使用されます。

  • ソースクラスター: アプリケーションの移行元となるクラスター。
  • 宛先クラスター: アプリケーションが移行されるクラスター。

3.4.3.1. MTC (Migration Toolkit for Containers) を使用したアプリケーションの移行

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

アプリケーションをローカルクラスターからリモートクラスター、リモートクラスターからローカルクラスター、およびリモートクラスター間で移行できます。

この手順では、間接的および直接的な移行を実行する方法を説明します。

  • 間接的な移行: イメージ、ボリューム、および Kubernetes オブジェクトはソースクラスターからレプリケーションリポジトリーにコピーされ、その後にレプリケーションリポジトリーから宛先クラスターにコピーされます。
  • 直接的な移行: イメージまたはボリュームはソースクラスターから宛先クラスターに直接コピーされます。イメージとボリュームの直接的な移行には、パフォーマンス上の大きなメリットがあります。

以下のカスタムリソース (CR) を作成して移行を実行します。

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

    migration-controller Pod は hostクラスターで実行されます。

  • Secret CR: リモートクラスターまたはストレージの認証情報が含まれます。
  • MigStorage CR: レプリケーションリポジトリーを定義します。

    異なるストレージプロバイダーには、MigStorage CR マニフェストで異なるパラメーターが必要です。

  • MigPlan CR: 移行計画を定義します。
  • MigMigration CR: 関連付けられた MigPlan で定義された移行を実行します。

    以下の目的で、単一の MigPlan CR に複数の MigMigration CR を作成できます。

  • 移行を実行する前に、アプリケーションを停止せずにほとんどのデータをコピーする段階移行 (Stage migration) を実行する。段階移行により、移行のパフォーマンスが向上します。
  • 実行中の移行を取り消す。
  • 完了した移行をロールバックする

前提条件

  • すべてのクラスターで cluster-admin 権限が必要です。
  • OpenShift Container Platform CLI (oc) をインストールする必要があります。
  • すべてのクラスターに MTC (Migration Toolkit for Containers Operator) をインストールする必要があります。
  • インストールされた MTC (Migration Toolkit for Containers Operator) の version は、すべてのクラスターで同一である必要があります。
  • オブジェクトストレージをレプリケーションリポジトリーとして設定する必要があります。
  • イメージの直接的な移行を実行している場合、すべてのリモートクラスターでセキュアなレジストリールートを公開する必要があります。
  • ボリュームの直接移行を使用している場合、ソースクラスターには HTTP プロキシーを設定することはできません。

手順

  1. host-cluster.yaml という host クラスターの MigCluster CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: host
      namespace: openshift-migration
    spec:
      isHostCluster: true
  2. host クラスターの MigCluster CR を作成します。

    $ oc create -f host-cluster.yaml -n openshift-migration
  3. 各リモートクラスターに、cluster-secret.yaml という Secret CR マニフェストを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <cluster_secret>
      namespace: openshift-config
    type: Opaque
    data:
      saToken: <sa_token> 1
    1
    リモートクラスターの base64 でエンコードされた migration-controller サービスアカウント (SA) トークンを指定します。

    以下のコマンドを実行して SA トークンを取得できます。

    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
  4. それぞれのリモートクラスターに Secret CR を作成します。

    $ oc create -f cluster-secret.yaml
  5. それぞれのリモートクラスターに、remote-cluster.yaml という MigCluster CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigCluster
    metadata:
      name: <remote_cluster>
      namespace: openshift-migration
    spec:
      exposedRegistryPath: <exposed_registry_route> 1
      insecure: false 2
      isHostCluster: false
      serviceAccountSecretRef:
        name: <remote_cluster_secret> 3
        namespace: openshift-config
      url: <remote_cluster_url> 4
    1
    オプション: 直接的なイメージの移行を実行する場合、公開されるレジストリールートを指定します (例: docker-registry-default.apps.example.com)。
    2
    SSL 検証は、false の場合に有効になります。CA 証明書は、true の場合は必要ではなく、チェックされません。
    3
    リモートクラスターの Secret CR を指定します。
    4
    リモートクラスターの URL を指定します。
  6. それぞれのリモートクラスターについて MigCluster CR を作成します。

    $ oc create -f remote-cluster.yaml -n openshift-migration
  7. すべてのクラスターが Ready 状態にあることを確認します。

    $ oc describe cluster <cluster_name>
  8. storage-secret.yaml というレプリケーションリポジトリーの Secret CR マニフェストを作成します。

    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
    1
    キー ID を base64 形式で指定します。
    2
    シークレットキーを base64 形式で指定します。

    AWS 認証情報はデフォルトで base64 でエンコードされます。別のストレージプロバイダーを使用している場合、それぞれのキーを使用して以下のコマンドを実行して、認証情報をエンコードする必要があります。

    $ echo -n "<key>" | base64 -w 0 1
    1
    キー ID またはシークレットキーを指定します。どちらの値も base64 でエンコードする必要があります。
  9. レプリケーションリポジトリーの Secret CR を作成します。

    $ oc create -f storage-secret.yaml
  10. migstorage.yaml というレプリケーションリポジトリーの MigStorage CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5
    1
    バケット名を指定します。
    2
    オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。
    3
    ストレージプロバイダーを指定します。
    4
    オプション: スナップショットを使用してデータをコピーする場合は、オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。
    5
    オプション: スナップショットを使用してデータをコピーする場合は、ストレージプロバイダーを指定します。
  11. MigStorage CR を作成します。

    $ oc create -f migstorage.yaml -n openshift-migration
  12. MigStorage CR が Ready 状態にあることを確認します。

    $ oc describe migstorage <migstorage_name>
  13. migplan.yaml という MigPlan CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration
    1
    false の場合、直接的なイメージ移行が有効にされます。
    2
    false の場合、直接的なボリューム移行が有効にされます。
    3
    MigStorage CR インスタンスの名前を指定します。
    4
    移行する namespace を 1 つ以上指定します。
    5
    ソースクラスター MigCluster インスタンスの名前を指定します。
  14. MigPlan CR を作成します。

    $ oc create -f migplan.yaml -n openshift-migration
  15. MigPlan インスタンスを表示し、そのインスタンスが Ready 状態にあることを確認します。

    $ oc describe migplan <migplan_name> -n openshift-migration
  16. migmigration.yaml という MigMigration CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4
    1
    MigPlan CR 名を指定します。
    2
    true の場合、ソースクラスターの Pod は停止します。
    3
    true の場合、アプリケーションを停止せずにほとんどのデータをコピーする段階移行が実行されます。
    4
    true の場合、完了した移行がロールバックされます。
  17. MigMigration CR を作成し、MigPlan CR に定義された移行を開始します。

    $ oc create -f migmigration.yaml -n openshift-migration
  18. MigMigration CR を監視して移行の進捗を確認します。

    $ oc watch migmigration <migmigration_name> -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:       my_application
        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

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

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

3.4.3.2.1. DirectImageMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: <directimagemigration_name>
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  namespaces:
  - <namespace> 3
1
ソースクラスターの MigCluster CR 名を指定します。
2
宛先クラスターの MigCluster CR 名を指定します。
3
移行するイメージが含まれる namespace を 1 つ以上指定します。
3.4.3.2.2. DirectImageStreamMigration

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

apiVersion: migration.openshift.io/v1alpha1
kind: DirectImageStreamMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: directimagestreammigration_name
spec:
  srcMigClusterRef:
    name: <source_cluster_ref> 1
    namespace: openshift-migration
  destMigClusterRef:
    name: <destination_cluster_ref> 2
    namespace: openshift-migration
  imageStreamRef:
    name: <image_stream_name> 3
    namespace: <source_image_stream_namespace> 4
  destNamespace: <destination_image_stream_namespace> 5
1
ソースクラスターの MigCluster CR 名を指定します。
2
宛先クラスターの MigCluster CR 名を指定します。
3
イメージストリーム名を指定します。
4
ソースクラスターにイメージストリーム namespace を指定します。
5
宛先クラスターでイメージストリーム namespace を指定します。
3.4.3.2.3. DirectVolumeMigration

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

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

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

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

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

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

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

apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: host 1
  namespace: openshift-migration
spec:
  isHostCluster: true 2
  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.
# isHostCluster: false
# exposedRegistryPath: 8
# url: <destination_cluster_url> 9
# serviceAccountSecretRef:
#   name: <source_secret_ref> 10
#   namespace: openshift-config
1
オプション: migration-controller Pod がこのクラスターで実行されていない場合には、クラスター名を更新します。
2
true の場合、migration-controller Pod がこのクラスターで実行されます。
3
オプション: ストレージプロバイダーが Microsoft Azure の場合は、リソースグループを指定します。
4
オプション: 自己署名 CA 証明書の証明書バンドルを作成しており、insecureな パラメーターの値が false の場合、base64 でエンコードされた証明書バンドルを指定します。
5
SSL 検証は、false の場合に有効になります。
6
true の場合、クラスターが検証されます。
7
true の場合、ステージ Pod の作成後に restic Pod がソースクラスターで再起動します。
8
オプション: 直接的なイメージ移行を使用している場合、リモートクラスターの公開されるレジストリーパスを指定します。
9
リモートクラスターの URL を指定します。
10
リモートクラスターの Secret CR の名前を指定します。
3.4.3.2.7. MigHook

MigHook CR は、Ansible Playbook、または移行の特定の段階でタスクを実行するカスタムイメージを定義します。

apiVersion: migration.openshift.io/v1alpha1
kind: MigHook
metadata:
  generateName: <hook_name_prefix> 1
  name: <hook_name> 2
  namespace: openshift-migration
spec:
  activeDeadlineSeconds: 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
フックが実行されるクラスターとして source または destination を指定します。
3.4.3.2.8. MigMigration

MigMigration CR は関連付けられる MigPlan CR を実行します。

以下のシナリオについて、同じ MigPlan CR に関連付けられた複数の MigMigration CR を作成できます。

  • stage (段階) 移行または増分移行を複数回実行して、ソースクラスターで Pod を停止せずにデータをコピーすることができます。段階移行の実行により、実際の移行のパフォーマンスが向上します。
  • 進行中の移行を取り消すことができます。
  • 移行をロールバックできます。
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: migmigration_name
  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_ref> 7
    namespace: openshift-migration
1
true の場合、進行中の移行が取り消されます。
2
true の場合、完了した移行がロールバックされます。
3
true の場合、データが増分的にコピーされ、ソースクラスターは停止しません。
4
true の場合、ソースクラスターの Pod は、移行の Backup ステージの後に 0 にスケーリングされます。
5
true の場合、移行中に適用されるラベルとアノテーションは保持されます。
6
true の場合、宛先クラスターで移行される Pod のステータスはチェックされ、Running 状態にない Pod の名前が返されます。
7
migPlanRef.name: 関連付けられる MigPlan CR の名前を指定します。
3.4.3.2.9. MigPlan

MigPlan CR は移行計画のパラメーターを定義します。これには、同じパラメーターで移行される仮想マシンのグループが含まれます。

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

MigStorage CR はレプリケーションリポジトリーのオブジェクトストレージを記述します。Amazon Web Services、Microsoft Azure、Google Cloud Storage、および汎用 S3 互換クラウドストレージ (例: Minio または NooBaa) を設定できます。

プロバイダーごとに異なるパラメーターが必要です。

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

3.4.3.3. 追加リソース

3.4.4. 移行計画の設定

移行するオブジェクト数を増やしたり、移行からリソースを除外したりできます。

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

3.4.4.2. 移行計画からのリソースの除外

移行についてのリソース負荷を減らしたり、別のツールでイメージや 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
    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

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

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

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

注記

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

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

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

手順

  1. openshift-migration namespace の MigMigration CR を一覧表示します。

    $ oc get migmigration -n openshift-migration

    出力例

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

  2. MigMigration CR を検査します。

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

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

MigMigration の出力例

name:         88435fe0-c9f8-11e9-85e6-5d593ce65e10
namespace:    openshift-migration
labels:       <none>
annotations:  touch: 3b48b543-b53e-4e44-9d34-33563f0f8147
apiVersion:  migration.openshift.io/v1alpha1
kind:         MigMigration
metadata:
  creationTimestamp:  2019-08-29T01:01:29Z
  generation:          20
  resourceVersion:    88179
  selfLink:           /apis/migration.openshift.io/v1alpha1/namespaces/openshift-migration/migmigrations/88435fe0-c9f8-11e9-85e6-5d593ce65e10
  uid:                 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
spec:
  migPlanRef:
    name:        socks-shop-mig-plan
    namespace:   openshift-migration
  quiescePods:  true
  stage:         false
status:
  conditions:
    category:              Advisory
    durable:               True
    lastTransitionTime:  2019-08-29T01:03:40Z
    message:               The migration has completed successfully.
    reason:                Completed
    status:                True
    type:                  Succeeded
  phase:                   Completed
  startTimestamp:         2019-08-29T01:01:29Z
events:                    <none>

PV データを記述する Velero バックアップ CR #2 の出力例

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    openshift.io/migrate-copy-phase: final
    openshift.io/migrate-quiesce-pods: "true"
    openshift.io/migration-registry: 172.30.105.179:5000
    openshift.io/migration-registry-dir: /socks-shop-mig-plan-registry-44dd3bd5-c9f8-11e9-95ad-0205fe66cbb6
  creationTimestamp: "2019-08-29T01:03:15Z"
  generateName: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-
  generation: 1
  labels:
    app.kubernetes.io/part-of: migration
    migmigration: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    migration-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
    velero.io/storage-location: myrepo-vpzq9
  name: 88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  namespace: openshift-migration
  resourceVersion: "87313"
  selfLink: /apis/velero.io/v1/namespaces/openshift-migration/backups/88435fe0-c9f8-11e9-85e6-5d593ce65e10-59gb7
  uid: c80dbbc0-c9f8-11e9-95ad-0205fe66cbb6
spec:
  excludedNamespaces: []
  excludedResources: []
  hooks:
    resources: []
  includeClusterResources: null
  includedNamespaces:
  - sock-shop
  includedResources:
  - persistentvolumes
  - persistentvolumeclaims
  - namespaces
  - imagestreams
  - imagestreamtags
  - secrets
  - configmaps
  - pods
  labelSelector:
    matchLabels:
      migration-included-stage-backup: 8886de4c-c9f8-11e9-95ad-0205fe66cbb6
  storageLocation: myrepo-vpzq9
  ttl: 720h0m0s
  volumeSnapshotLocations:
  - myrepo-wv6fx
status:
  completionTimestamp: "2019-08-29T01:02:36Z"
  errors: 0
  expiration: "2019-09-28T01:02:35Z"
  phase: Completed
  startTimestamp: "2019-08-29T01:02:35Z"
  validationErrors: null
  version: 1
  volumeSnapshotsAttempted: 0
  volumeSnapshotsCompleted: 0
  warnings: 0

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

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

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

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

手順

  1. mig-log-reader Pod を取得します。

    $ oc -n openshift-migration get pods | grep log
  2. 以下のコマンドを入力して、単一の移行ログを表示します。

    $ oc -n openshift-migration logs -f <mig-log-reader-pod> -c color 1
    1
    -c plain オプションは、色なしでログを表示します。

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

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

手順

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

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

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

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

3.5.4. 非推奨の API の更新

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

Some namespaces contain GVKs incompatible with destination cluster

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

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

手順

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

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

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

    metadata:
      ...
      uid: 79509e05-61d6-11e9-bc55-02ce4781844a 1
    status:
      ...
      conditions:
      - category: Warn
        lastTransitionTime: 2020-04-30T17:16:23Z
        message: 'Some namespaces contain GVKs incompatible with destination cluster.
          See: `incompatibleNamespaces` for details'
        status: "True"
        type: GVKsIncompatible
      incompatibleNamespaces:
      - gvks: 2
        - group: batch
          kind: cronjobs
          version: v2alpha1
        - group: batch
          kind: scheduledjobs
          version: v2alpha1
    1
    MigPlan CR UID を記録します。
    2
    gvks セクションに一覧表示された非推奨の API を記録します。
  3. MigPlan UID に関連付けられた MigMigration 名を取得します。

    $ oc get migmigration -o json | jq -r '.items[] | select(.metadata.ownerReferences[].uid=="<migplan_uid>") | .metadata.name' 1
    1
    MigPlan CR UID を指定します。
  4. MigMigration 名に関連付けられた MigMigration UID を取得します。

    $ oc get migmigration <migmigration_name> -o jsonpath='{.metadata.uid}' 1
    1
    MigMigration 名を指定します。
  5. MigMigration UID に関連付けられた Velero バックアップ名を取得します。

    $ oc get backup.velero.io --selector migration-initial-backup="<migmigration_uid>" -o jsonpath={.items[*].metadata.name} 1
    1
    MigMigration UID を指定します。
  6. ストレージプロバイダーのコマンドを実行して、Velero バックアップの内容をローカルマシンにダウンロードします。

    • AWS S3:

      $ aws s3 cp s3://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。
    • GCP

      $ gsutil cp gs://<bucket_name>/velero/backups/<backup_name> <backup_local_dir> --recursive 1
      1
      バケット、バックアップ名、およびローカルバックアップのディレクトリー名を指定します。
    • Azure:

      $ azcopy copy 'https://velerobackups.blob.core.windows.net/velero/backups/<backup_name>' '<backup_local_dir>' --recursive 1
      1
      バックアップ名とローカルバックアップのディレクトリー名を指定します。
  7. Velero バックアップアーカイブファイルを展開します。

    $ tar -xfv <backup_local_dir>/<backup_name>.tar.gz -C <backup_local_dir>
  8. 非推奨のそれぞれの API でオフラインモードで oc convert を実行します。

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

    $ oc create -f <gvk>.json

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

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

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

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

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

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

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

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

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

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

手順

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

    $ oc logs <MigrationUI_Pod> -n openshift-migration

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

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

出力例

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

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

手順

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

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

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

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

出力例

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

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

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

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

手順

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

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

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

    出力例

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

  3. PodVolumeRestore CR を表示します。

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

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

    出力例

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

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

    $ oc logs -f <restic-nr2v5>

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

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

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

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

手順

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

    $ oc describe migmigration <pod_name> -n openshift-migration

    出力には、以下のようなステータス情報が含まれます。

    出力例

    ...
    Some or all transfer pods are not running for more than 10 mins on destination cluster
    ...

  2. ソースクラスターで、移行した namespace の詳細を取得します。

    $ oc get namespace <namespace> -o yaml 1
    1
    移行した namespace を指定します。
  3. ターゲットクラスターで、移行した namespace を編集します。

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

    apiVersion: v1
    kind: Namespace
    metadata:
      annotations:
        openshift.io/node-selector: "region=east"
    ...
  5. 移行計画を再度実行します。

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

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

3.5.7.1. Velero コマンド構文

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

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

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

3.5.7.2. Help コマンド

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

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

3.5.7.3. describe コマンド

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

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

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

3.5.7.4. logs コマンド

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

velero <resource> logs <resource_id>

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

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

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

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

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

手順

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

    $ oc get migmigration <migmigration> -o yaml
    status:
      conditions:
      - category: Warn
        durable: true
        lastTransitionTime: "2021-01-26T20:48:40Z"
        message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
        status: "True"
        type: VeleroFinalRestorePartiallyFailed
      - category: Advisory
        durable: true
        lastTransitionTime: "2021-01-26T20:48:42Z"
        message: The migration has completed with warnings, please look at `Warn` conditions.
        reason: Completed
        status: "True"
        type: SucceededWithWarnings
  2. Velero describe コマンドを使用して Restore CR のステータスを確認します。

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>
    Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
    
    Errors:
      Velero:     <none>
      Cluster:    <none>
      Namespaces:
        migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource
  3. Velero logs コマンドを使用して Restore CR ログを確認します。

    $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>
    time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
    time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

    Restore CR のログエラーメッセージの the server could not find the requested resource は、部分的に失敗した移行の原因を示します。

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

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

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

手順

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

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

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

3.5.9. 移行のロールバック

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

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

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

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

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

手順

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

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

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

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

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

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

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

手順

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

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

3.5.10. 既知の問題

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

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

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

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

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

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

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

3.5.11. 追加リソース

法律上の通知

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.