9.2. コマンドラインを使用したアプリケーションの移行
移行を自動化するために、コマンドラインインターフェイス (CLI) を使用して MTC API でアプリケーションを移行できます。
9.2.1. 移行の前提条件
-
cluster-admin
権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
イメージの直接移行
- ソースクラスターのセキュアな内部レジストリーが公開されている必要があります。
- 公開されるレジストリーへのルートを作成しておく必要があります。
ボリュームの直接移行
- クラスターがプロキシーを使用する場合に Stunnel TCP プロキシーを設定している必要があります。
クラスター
- ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
- MTC のバージョンは、すべてのクラスターで同一である必要があります。
ネットワーク
- クラスターには、レプリケーションリポジトリーに対して、また各クラスター間で無制限のネットワークアクセスが必要です。
-
move
を使用して永続ボリュームをコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。 OpenShift Container Platform 4 クラスターで以下のポートを有効にする必要があります。
-
6443
(API サーバー) -
443
(ルート) -
53
(DNS)
-
-
TLS を使用している場合は、レプリケーションリポジトリーでポート
443
を有効にする必要があります。
永続ボリューム (PV)
- PV は有効である必要があります。
- PV は永続ボリューム要求にバインドされる必要があります。
スナップショットを使用して PV をコピーする場合には、以下の前提条件が追加されます。
- クラウドプロバイダーはスナップショットをサポートしている必要があります。
- PV に同じクラウドプロバイダーがなければなりません。
- PV は同じ地理的リージョンにある必要があります。
- PV には同じストレージクラスがなければなりません。
9.2.2. イメージの直接移行用のレジストリールートの作成
イメージの直接移行にはすべてのリモートクラスターで公開される内部レジストリーへのルートを作成する必要があります。
前提条件
全リモートクラスターの外部トラフィックに対して内部レジストリーを公開する。
デフォルトで OpenShift Container Platform 4 レジストリーを公開しておく。
手順
OpenShift Container Platform 4 レジストリーへのルートを作成するには、以下のコマンドを実行します。
$ oc create route passthrough --service=image-registry -n openshift-image-registry
9.2.3. プロキシー設定
OpenShift Container Platform 4.1 以前のバージョンでは、これらのバージョンはクラスター全体の proxy
オブジェクトをサポートしないため、Migration Toolkit for Containers Operator のインストール後に、MigrationController
カスタムリソース (CR) マニフェストでプロキシーを設定する必要があります。
OpenShift Container Platform 4.2 から 4.9 の場合、MTC (Migration Toolkit for Containers) はクラスター全体のプロキシー設定を継承します。クラスター全体のプロキシー設定を上書きする場合は、プロキシーパラメーターを変更できます。
9.2.3.1. ボリュームの直接移行
MTC 1.4.2 で、ボリュームの直接移行 (DVM) が導入されました。DVM は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。
プロキシーの背後にあるソースクラスターから DVM を実行する場合には、トランスポート層で機能する TCP プロキシーを設定して、SSL 接続を独自の SSL 証明書で復号化および再暗号化せずに透過的に転送する必要があります。Stunnel プロキシーは、このようなプロキシーの例です。
9.2.3.1.1. DVM の TCP プロキシー設定
TCP プロキシー経由でソースとターゲットクラスターの間に直接接続を設定し、プロキシーを使用できるように MigrationController
CR の stunnel_tcp_proxy
変数を設定できます。
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: migration-controller namespace: openshift-migration spec: [...] stunnel_tcp_proxy: http://username:password@ip:port
ボリュームの直接移行 (DVM) は、プロキシーの Basic 認証のみをサポートします。さらに、DVM は、TCP 接続を透過的にトンネルできるプロキシーの背後でのみ機能します。中間者モードの HTTP/HTTPS プロキシーは機能しません。既存のクラスター全体にわたるプロキシーはこの動作をサポートしない可能性があります。その結果、DVM のプロキシー設定は、MTC の通常のプロキシー設定とは異なる状態に保たれます。
9.2.3.1.2. HTTP/HTTPS プロキシーの代わりに TCP プロキシーを使用する理由
DVM を有効にするには、OpenShift ルートを介してソースおよびターゲットクラスター間で Rsync を実行します。トラフィックは、TCP プロキシーである Stunnel を使用して暗号化されます。ソースクラスターで実行している Stunnel は、ターゲット Stunnel との TLS 接続を開始し、暗号化されたチャネルでデータを転送します。
OpenShift のクラスター全体の HTTP/HTTPS プロキシーは通常、外部サーバーで独自の TLS セッションをネゴシエートする中間者モードで設定されます。ただし、これは Stunnel では機能しません。Stunnel では、プロキシーによって TLS セッションが変更されないようにする必要があります。基本的には、プロキシーを透過的なトンネルにし、単純に TCP 接続をそのまま転送する必要があります。したがって、TCP プロキシーを使用する必要があります。
9.2.3.1.3. 既知の問題
移行が Upgrade request required
エラーで失敗する
移行コントローラーは SPDY プロトコルを使用してリモート Pod 内でコマンドを実行します。リモートクラスターがプロキシーまたは、SPDY プロトコルをサポートしないファイアウォールの背後にある場合には、移行コントローラーはリモートコマンドの実行に失敗します。移行に失敗し、Upgrade request required
というエラーメッセージが表示されます。回避策: SPDY プロトコルをサポートするプロキシーを使用します。
SPDY プロトコルのサポートに加えて、このプロキシーまたはファイアウォールでは、Upgrade
HTTP ヘッダーを API サーバーに渡す必要もあります。クライアントはこのヘッダーを使用して API サーバーと Websocket 接続を開きます。Upgrade
ヘッダーがプロキシーまたはファイアウォールでブロックされると、移行に失敗し、Upgrade request required
というエラーメッセージが表示されます。回避策: プロキシーで Upgrade
ヘッダーが転送されるようにしてください。
9.2.3.2. 移行用のネットワークポリシーのチューニング
OpenShift は、クラスターで使用されるネットワークプラグインに基づいて NetworkPolicy または EgressFirewalls を使用した Pod との間のトラフィックの制限をサポートします。移行に関連するソース namespace のいずれかがこのようなメカニズムを使用して Pod へのネットワークトラフィックを制限する場合には、この制限により移行時に Rsync Pod へのトラフィックが誤って停止される可能性があります。
ソースおよびターゲットクラスターの両方で実行される Rsync Pod は OpenShift Route 経由で相互に接続する必要があります。既存の NetworkPolicy または EgressNetworkPolicy オブジェクトは、これらのトラフィックの制限が課されないように Rsync Pod を自動的に取り除くように設定できます。
9.2.3.2.1. NetworkPolicy の設定
9.2.3.2.1.1. Rsync Pod からの egress トラフィック
Rsync Pod の一意のラベルを使用し、同期元または同期先 namespace の NetworkPolicy
設定がこのタイプのトラフィックをブロックする場合に egress トラフィックがそれらを通過することを許可できます。以下のポリシーは、namespace の Rsync Pod からの 全 egress トラフィックを許可します。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress-from-rsync-pods spec: podSelector: matchLabels: owner: directvolumemigration app: directvolumemigration-rsync-transfer egress: - {} policyTypes: - Egress
9.2.3.2.1.2. Rsync Pod への ingress トラフィック
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress-from-rsync-pods spec: podSelector: matchLabels: owner: directvolumemigration app: directvolumemigration-rsync-transfer ingress: - {} policyTypes: - Ingress
9.2.3.2.2. EgressNetworkPolicy 設定
EgressNetworkPolicy
オブジェクトまたは Egress ファイアウォール は、egress トラフィックをクラスターからブロックするために設計された OpenShift コンストラクトです。
NetworkPolicy
オブジェクトとは異なり、Egress ファイアウォールは namespace のすべての Pod に適用されるためにプロジェクトレベルで機能します。そのため、Rsync Pod の一意のラベルを使用すると、この制限から除外するのは Rsync Pod だけではありません。ただし、ソースおよびターゲットクラスターの CIDR 範囲をポリシーの Allow ルールに追加して、2 つのクラスター間で直接接続を設定できます。
Egress ファイアウォールが存在するクラスターに基づいて、他のクラスターの CIDR 範囲を追加して、2 つの間の egress トラフィックを許可できます。
apiVersion: network.openshift.io/v1 kind: EgressNetworkPolicy metadata: name: test-egress-policy namespace: <namespace> spec: egress: - to: cidrSelector: <cidr_of_source_or_target_cluster> type: Deny
9.2.3.2.3. データ転送用の代替エンドポイントの選択
デフォルトでは、DVM は OpenShift Container Platform ルートをエンドポイントとして使用して、PV データを宛先クラスターに転送します。クラスタートポロジーで許可されている場合は、サポートされている別の種類のエンドポイントを選択できます。
クラスターごとに、MigrationController
CR で適切な 宛先 クラスターに rsync_endpoint_type
変数を設定することで、エンドポイントを設定できます。
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: migration-controller namespace: openshift-migration spec: [...] rsync_endpoint_type: [NodePort|ClusterIP|Route]
9.2.3.2.4. RsyncPod の補足グループの設定
PVC が共有ストレージを使用する場合、Pod がアクセスを許可するように RsyncPod 定義に補足グループを追加して、そのストレージへのアクセスを設定できます。
変数 | タイプ | デフォルト | 説明 |
---|---|---|---|
| 文字列 | 設定されていません | ソース Rsync Pod の補足グループのコンマ区切りリスト |
| 文字列 | 設定されていません | ターゲット Rsync Pod の補足グループのコンマ区切りリスト |
使用例
MigrationController
CR を更新して、これらの補足グループの値を設定できます。
spec: src_supplemental_groups: "1000,2000" target_supplemental_groups: "2000,3000"
9.2.3.3. プロキシーの設定
前提条件
-
cluster-admin
権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
手順
MigrationController
CR マニフェストを取得します。$ oc get migrationcontroller <migration_controller> -n openshift-migration
プロキシーパラメーターを更新します。
apiVersion: migration.openshift.io/v1alpha1 kind: MigrationController metadata: name: <migration_controller> namespace: openshift-migration ... spec: stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 1 noProxy: example.com 2
サブドメインのみと一致するように、ドメインの前に
.
を付けます。たとえば、.y.com
はx.y.com
に一致しますが、y.com
には一致しません。*
を使用し、すべての宛先のプロキシーをバイパスします。インストール設定でnetworking.machineNetwork[].cidr
フィールドで定義されるネットワークに含まれていないワーカーをスケールアップする場合、それらをこの一覧に追加し、接続の問題を防ぐ必要があります。httpProxy
またはhttpsProxy
フィールドのいずれも設定されていない場合、このフィールドは無視されます。-
マニフェストを
migration-controller.yaml
として保存します。 更新したマニフェストを適用します。
$ oc replace -f migration-controller.yaml -n openshift-migration
9.2.4. MTC API を使用したアプリケーションの移行
MTC (Migration Toolkit for Containers) API を使用してコマンドラインからアプリケーションを移行できます。
手順
host クラスターの
MigCluster
CR マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: migration.openshift.io/v1alpha1 kind: MigCluster metadata: name: <host_cluster> namespace: openshift-migration spec: isHostCluster: true EOF
リモートクラスターごとに
Secret
オブジェクトマニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: v1 kind: Secret metadata: name: <cluster_secret> namespace: openshift-config type: Opaque data: saToken: <sa_token> 1 EOF
- 1
- リモートクラスターの base64 でエンコードされた
migration-controller
サービスアカウント (SA) トークンを指定します。以下のコマンドを実行してトークンを取得できます。
$ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
それぞれのリモートクラスターについて
MigCluster
CR マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: migration.openshift.io/v1alpha1 kind: MigCluster metadata: name: <remote_cluster> 1 namespace: openshift-migration spec: exposedRegistryPath: <exposed_registry_route> 2 insecure: false 3 isHostCluster: false serviceAccountSecretRef: name: <remote_cluster_secret> 4 namespace: openshift-config url: <remote_cluster_url> 5 EOF
すべてのクラスターが
Ready
状態にあることを確認します。$ oc describe cluster <cluster>
レプリケーションリポジトリーの
Secret
オブジェクトマニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: v1 kind: Secret metadata: namespace: openshift-config name: <migstorage_creds> type: Opaque data: aws-access-key-id: <key_id_base64> 1 aws-secret-access-key: <secret_key_base64> 2 EOF
AWS 認証情報はデフォルトで base64 でエンコードされます。それぞれのキーを使用して以下のコマンドを実行して、認証情報をエンコードする必要があります。
$ echo -n "<key>" | base64 -w 0 1
- 1
- キー ID またはシークレットキーを指定します。どちらの値も base64 でエンコードする必要があります。
レプリケーションリポジトリーの
MigStorage
CR マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: migration.openshift.io/v1alpha1 kind: MigStorage metadata: name: <migstorage> namespace: openshift-migration spec: backupStorageConfig: awsBucketName: <bucket> 1 credsSecretRef: name: <storage_secret> 2 namespace: openshift-config backupStorageProvider: <storage_provider> 3 volumeSnapshotConfig: credsSecretRef: name: <storage_secret> 4 namespace: openshift-config volumeSnapshotProvider: <storage_provider> 5 EOF
MigStorage
CR がReady
状態にあることを確認します。$ oc describe migstorage <migstorage>
MigPlan
CR マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: migration.openshift.io/v1alpha1 kind: MigPlan metadata: name: <migplan> namespace: openshift-migration spec: destMigClusterRef: name: <host_cluster> namespace: openshift-migration indirectImageMigration: true 1 indirectVolumeMigration: true 2 migStorageRef: name: <migstorage> 3 namespace: openshift-migration namespaces: - <source_namespace_1> 4 - <source_namespace_2> - <source_namespace_3>:<destination_namespace> 5 srcMigClusterRef: name: <remote_cluster> 6 namespace: openshift-migration EOF
MigPlan
インスタンスがReady
状態にあることを確認します。$ oc describe migplan <migplan> -n openshift-migration
MigMigration
CR マニフェストを作成し、MigPlan
インスタンスに定義された移行を開始します。$ cat << EOF | oc apply -f - apiVersion: migration.openshift.io/v1alpha1 kind: MigMigration metadata: name: <migmigration> namespace: openshift-migration spec: migPlanRef: name: <migplan> 1 namespace: openshift-migration quiescePods: true 2 stage: false 3 rollback: false 4 EOF
MigMigration
CR の進捗を監視して移行を確認します。$ oc watch migmigration <migmigration> -n openshift-migration
出力は以下のようになります。
出力例
Name: c8b034c0-6567-11eb-9a4f-0bc004db0fbc Namespace: openshift-migration Labels: migration.openshift.io/migplan-name=django Annotations: openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c API Version: migration.openshift.io/v1alpha1 Kind: MigMigration ... Spec: Mig Plan Ref: Name: migplan Namespace: openshift-migration Stage: false Status: Conditions: Category: Advisory Last Transition Time: 2021-02-02T15:04:09Z Message: Step: 19/47 Reason: InitialBackupCreated Status: True Type: Running Category: Required Last Transition Time: 2021-02-02T15:03:19Z Message: The migration is ready. Status: True Type: Ready Category: Required Durable: true Last Transition Time: 2021-02-02T15:04:05Z Message: The migration registries are healthy. Status: True Type: RegistriesHealthy Itinerary: Final Observed Digest: 7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5 Phase: InitialBackupCreated Pipeline: Completed: 2021-02-02T15:04:07Z Message: Completed Name: Prepare Started: 2021-02-02T15:03:18Z Message: Waiting for initial Velero backup to complete. Name: Backup Phase: InitialBackupCreated Progress: Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s) Started: 2021-02-02T15:04:07Z Message: Not started Name: StageBackup Message: Not started Name: StageRestore Message: Not started Name: DirectImage Message: Not started Name: DirectVolume Message: Not started Name: Restore Message: Not started Name: Cleanup Start Timestamp: 2021-02-02T15:03:18Z Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Running 57s migmigration_controller Step: 2/47 Normal Running 57s migmigration_controller Step: 3/47 Normal Running 57s (x3 over 57s) migmigration_controller Step: 4/47 Normal Running 54s migmigration_controller Step: 5/47 Normal Running 54s migmigration_controller Step: 6/47 Normal Running 52s (x2 over 53s) migmigration_controller Step: 7/47 Normal Running 51s (x2 over 51s) migmigration_controller Step: 8/47 Normal Ready 50s (x12 over 57s) migmigration_controller The migration is ready. Normal Running 50s migmigration_controller Step: 9/47 Normal Running 50s migmigration_controller Step: 10/47
9.2.5. 状態の移行
アプリケーションの状態を設定する Persistent Volume Claim(永続ボリューム要求、PVC) を移行するために MTC (Migration Toolkit for Containers) を使用して反復可能な状態のみの移行を実行できます。移行計画から他の PVC を除外して、指定された PVC を移行します。PVC をマップし、ソースおよびターゲット PVC が同期されるようにできます。永続ボリューム (PV) データがターゲットクラスターにコピーされます。PV 参照は移動されず、アプリケーション Pod はソースクラスターでの実行を継続します。
状態の移行は、OpenShift Gitops などの外部 CD メカニズムと併用されるように特別に設計されています。MTC を使用して状態を移行する間に GitOps を使用してアプリケーションマニフェストを移行できます。
CI/CD パイプラインがある場合には、それらをターゲットクラスターにデプロイすることでステートレスコンポーネントを移行できます。次に、MTC を使用してステートフルコンポーネントを移行できます。
クラスター間または同じクラスター間で状態の移行を実行できます。
状態の移行は、アプリケーションの状態を設定するコンポーネントのみを移行します。namespace 全体を移行する場合は、ステージまたはカットオーバー移行を使用します。
前提条件
-
ソースクラスターのアプリケーションの状態は、
PersistentVolumeClaims
でプロビジョニングされたPersistentVolume
で永続化されます。 - アプリケーションのマニフェストは、ソースクラスターとターゲットクラスターの両方からアクセスできる中央リポジトリーで利用できます。
手順
永続ボリュームデータをソースからターゲットクラスターに移行します。
この手順は、必要に応じて何度でも実行することができます。ソースアプリケーションは実行を継続します。
ソースアプリケーションを休止します。
これは、ワークロードリソースのレプリカを、ソースクラスターに直接設定するか、GitHub でマニフェストを更新して Argo CD アプリケーションを再同期することで、
0
に設定できます。アプリケーションマニフェストのクローンをターゲットクラスターに作成します。
Argo CD を使用して、アプリケーションマニフェストのクローンをターゲットクラスターに作成できます。
残りのボリュームデータをソースからターゲットクラスターに移行します。
最終的なデータ移行を実行して、状態移行プロセス中にアプリケーションによって作成された新しいデータを移行します。
- クローンを作成したアプリケーションが休止状態の場合は、停止を解除します。
- DNS レコードをターゲットクラスターに切り替えて、ユーザートラフィックを移行されたアプリケーションにリダイレクトします。
MTC 1.6 は、状態移行の実行時にアプリケーションを自動的に停止できません。PV データのみ移行できます。したがって、アプリケーションの停止や停止解除に CD メカニズムを使用する必要があります。
MTC 1.7 では、明示的なステージおよびカットオーバーフローが導入されました。ステージングを使用して、必要なだけデータ転送を行うことができます。その後、カットオーバーを実行すると、ソースアプリケーションが自動的に停止します。
前提条件
-
ソースクラスターのアプリケーションの状態は、
PersistentVolumeClaims
でプロビジョニングされたPersistentVolume
で永続化されます。 - アプリケーションのマニフェストは、ソースクラスターとターゲットクラスターの両方からアクセスできる中央リポジトリーで利用できます。
手順
永続ボリュームデータをソースからターゲットクラスターに移行します。
この手順は、必要に応じて何度でも実行することができます。ソースアプリケーションは実行を継続します。
ソースアプリケーションを休止します。
これは、ワークロードリソースのレプリカを、ソースクラスターに直接設定するか、GitHub でマニフェストを更新して Argo CD アプリケーションを再同期することで、
0
に設定できます。アプリケーションマニフェストのクローンをターゲットクラスターに作成します。
Argo CD を使用して、アプリケーションマニフェストのクローンをターゲットクラスターに作成できます。
残りのボリュームデータをソースからターゲットクラスターに移行します。
最終的なデータ移行を実行して、状態移行プロセス中にアプリケーションによって作成された新しいデータを移行します。
- クローンを作成したアプリケーションが休止状態の場合は、停止を解除します。
- DNS レコードをターゲットクラスターに切り替えて、ユーザートラフィックを移行されたアプリケーションにリダイレクトします。
MTC 1.6 は、状態移行の実行時にアプリケーションを自動的に停止できません。PV データのみ移行できます。したがって、アプリケーションの停止や停止解除に CD メカニズムを使用する必要があります。
MTC 1.7 では、明示的なステージおよびカットオーバーフローが導入されました。ステージングを使用して、必要なだけデータ転送を行うことができます。その後、カットオーバーを実行すると、ソースアプリケーションが自動的に停止します。
関連情報
- 状態移行用の PVC を選択するには、移行からの PVC の除外 を参照してください。
- ソース PV データを宛先クラスターのプロビジョニングされた PVC に移行する PVC のマッピング を参照してください。
- アプリケーションの状態を設定する Kubernetes オブジェクトを移行するには、Kubernetes オブジェクトの移行 を参照してください。