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