11.6. 移行コントローラーオプション
移行計画の制限を編集したり、永続ボリュームのサイズ変更を有効にしたり、大規模な移行およびパフォーマンスを向上させる MigrationController
カスタムリソース (CR) でキャッシュされた Kubernetes クライアントを有効にすることもできます。
11.6.1. 大規模な移行に関する制限の引き上げ
Migration Toolkit for Containers (MTC) を使用した大規模な移行の場合には、移行オブジェクトおよびコンテナーリソースで制限を引き上げることができます。
実稼働環境で移行を実行する前に、これらの変更をテストする必要があります。
手順
MigrationController
カスタムリソース (CR) マニフェストを編集します。$ oc edit migrationcontroller -n openshift-migration
以下のパラメーターを更新します。
... 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 の数を指定します。
更新されたパラメーターを使用して変更を検証する移行計画を作成します。
移行計画が
MigrationController
CR の制限を超える場合、MTC コンソールには移行計画を保存する際に警告メッセージが表示されます。
11.6.2. ボリュームの直接移行での永続ボリュームサイズ変更の有効化
ボリュームの直接移行用に永続ボリューム (PV) のサイズ変更を有効にして、宛先クラスターでディスク領域が不足しないようにします。
PV のディスク使用量が設定されたレベルに達すると、MigrationController
カスタムリソース (CR) は永続ボリューム要求 (PVC) で必要なストレージ容量と実際のプロビジョニング容量とを比較します。次に、この CR は宛先クラスターに必要な領域を計算します。
pv_resizing_threshold
パラメーターは、PV のサイズ変更が使用されるタイミングを決定します。デフォルトのしきい値は 3%
です。つまり、PV のディスク使用量が 97%
を超える場合に PV のサイズ変更が発生します。PV のサイズ変更はディスク使用量が低いレベルで実行されるように、このしきい値を引き上げることができます。
PVC の容量は以下の基準に従って計算されます。
-
PVC の要求されるストレージ容量 (
spec.resources.requests.storage
) が実際のプロビジョニングされた容量 (status.capacity.storage
) と等しくない場合には、より大きい値が使用されます。 - PV が PVC 経由でプロビジョニングされ、その後に変更されて PV および PVC の容量が一致しなくなった場合に、より大きい値が使用されます。
前提条件
-
PVC は、
MigrationController
CR がコマンドを実行できるように実行中の Pod 1 つ以上に割り当てる必要があります。
手順
- ホストクラスターにログインします。
MigrationController
CR のパッチを適用して PV のサイズ変更を有効にします。$ oc patch migrationcontroller migration-controller -p '{"spec":{"enable_dvm_pv_resizing":true}}' \ 1 --type='merge' -n openshift-migration
- 1
- PV のサイズ変更を無効にするには、値を
false
に設定します。
必要に応じて、
pv_resizing_threshold
パラメーターを更新して、しきい値を増やします。$ oc patch migrationcontroller migration-controller -p '{"spec":{"pv_resizing_threshold":41}}' \ 1 --type='merge' -n openshift-migration
- 1
- デフォルト値は
3
です。
しきい値を超えると、以下のステータスメッセージが
MigPlan
CR ステータスに表示されます。status: conditions: ... - category: Warn durable: true lastTransitionTime: "2021-06-17T08:57:01Z" message: 'Capacity of the following volumes will be automatically adjusted to avoid disk capacity issues in the target cluster: [pvc-b800eb7b-cf3b-11eb-a3f7-0eae3e0555f3]' reason: Done status: "False" type: PvCapacityAdjustmentRequired
注記AWS gp2 ストレージの場合に、gp2 がボリューム使用量とサイズを計算する方法が原因で、
pv_resizing_threshold
が 42% 以上でない限り、このメッセージが表示されます。(BZ#1973148)
11.6.3. キャッシュされた Kubernetes クライアントの有効化
移行時にパフォーマンスを向上させるために、キャッシュされた Kubernetes クライアントを MigrationController
カスタムリソース (CR) で有効にできます。パフォーマンスに関する利点は、異なるリージョンのクラスター間で移行する場合や、ネットワークレイテンシーが大きい場合の移行時に発揮されます。
委譲されたタスク (例: 直接ボリューム移行または Velero バックアップおよび復元用の Rsync バックアップ) では、キャッシュされたクライアントのパフォーマンスは向上されません。
MigrationController
CR は MigCluster
CR との対話に必要なすべての API リソースをキャッシュするため、キャッシュされたクライアントには追加のメモリーが必要です。通常 API サーバーに送信される要求は、代わりにキャッシュに転送されます。このキャッシュは API サーバーで更新がないかを監視します。
キャッシュされたクライアントを有効にした後に OOMKilled
エラーが発生すると、MigrationController
CR のメモリー制限および要求を増やすことができます。
手順
以下のコマンドを実行して、キャッシュされたクライアントを有効化します。
$ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \ '[{ "op": "replace", "path": "/spec/mig_controller_enable_cache", "value": true}]'
オプション: 以下のコマンドを実行して
MigrationController
CR メモリーの制限を増やします。$ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \ '[{ "op": "replace", "path": "/spec/mig_controller_limits_memory", "value": <10Gi>}]'
オプション: 以下のコマンドを実行して
MigrationController
CR メモリー要求を増やします。$ oc -n openshift-migration patch migrationcontroller migration-controller --type=json --patch \ '[{ "op": "replace", "path": "/spec/mig_controller_requests_memory", "value": <350Mi>}]'