ストレージ・オペレータ・コンポーネントは、ディスク・ボリュームとゾーン間ポッド拡散を使用するステートフル・アプリケーションのゾーン間移行を自動化できます。 事前チェック機能とロールバック機能の助けを借りて、ストレージオペレーターコンポーネントは、移行中に例外が発生したときにビジネスの可用性を確保するために、ソースゾーンのアプリケーションを復元できます。 このトピックでは、ディスクボリュームを使用するステートフルアプリケーションをゾーン間で移行する方法について説明します。
シナリオ
展開計画の変更や現在のゾーンのリソースが不足している場合に、ステートフルアプリケーションをゾーン間で移行することができます。
File Storage NAS (NAS) ボリュームとObject Storage Service (OSS) ボリュームは、ゾーン間マウントとマルチポッドマウントをサポートしています。 ディスクはゾーン間で移行できないため、ディスクボリュームの永続ボリューム (PV) と永続ボリュームクレーム (PVC) は異なるゾーンで再利用できません。 したがって、ステートフルアプリケーションがディスクボリュームを使用している場合は、アプリケーションを移行先ゾーンに移行する必要があります。
仕組みと移行手順
ディスクボリュームを使用するアプリケーションをゾーン間で移行するには、ディスクスナップショット機能が必要です。 この機能では、ディスクスナップショットの保存期間を指定することもできます。 ディスクスナップショットの詳細については、「スナップショットの概要」をご参照ください。 スナップショットの課金ルールの詳細については、「スナップショット」をご参照ください。
storage-operatorコンポーネントは、次の手順を実行して、ディスクボリュームを使用するステートフルアプリケーションを移行します。
事前チェックを実行します。 たとえば、アプリケーションが期待どおりに実行されるかどうか、および移行する必要のあるディスクがアプリケーションにあるかどうかを確認します。 事前チェックに失敗した場合、アプリケーションは移行されません。
アプリケーションのポッドをゼロにスケーリングします。 スケールインアクティビティの後、アプリケーションは一時停止されます。
アプリケーションによって使用されるディスクのスナップショットを作成します。 スナップショットはゾーン間で使用できます。
スナップショットが有効であることを確認した後、スナップショットを使用してターゲットゾーンにディスクを作成します。 新しく作成されたディスクは、元のディスクと同じデータを格納します。
同じ名前のPVとPVCを作成し、PVとPVCをディスクにバインドします。
アプリケーションのポッドを元の番号にスケーリングし、ディスクボリュームをポッドにマウントします。
重要コンポーネントは、事前チェック後にアプリケーションを移行します。 移行のステップごとにロールバックポリシーが用意されています。 移行後のデータ損失を回避するには、コンポーネントが元のディスクを削除する前に、アプリケーションが期待どおりに実行されるようにします。
(オプション) アプリケーションが期待どおりに実行されることを確認した後、元のPVとディスクを削除します。 ディスクの課金ルールの詳細については、「EBSデバイス」をご参照ください。
使用上の注意
移行するアプリケーションが拡張SSD (ESSD) のみを使用していることを確認します。
また、IAスナップショットを選択することもできます。 詳細については、「インスタントアクセス機能の有効化または無効化」をご参照ください。 IAスナップショットはESSDに対してのみ作成できます。 アプリケーションでESSD以外のディスクを使用する場合は、次のいずれかの方法を使用します。
アプリケーションを移行する前に、ディスクのタイプをESSDに変更します。 詳細については、「クラウドディスクのタイプの変更」をご参照ください。
[ディスクから作成したボリュームスナップショットの使用] トピックの手順に従って、ターゲットゾーンのディスクを手動で再作成します。
移行先ゾーンがESSDをサポートしていることと、クラスターに移行先ゾーンのアプリケーションのポッドをホストするアイドルノードが含まれていることを確認します。
アプリケーションが提供するサービスが中断できることを確認してください。 ステートフルアプリケーションに複数のポッドがある場合は、移行を開始する前にポッドをゼロにスケールして、データの一貫性を確保します。 移行が完了したら、ポッドを元の番号にスケーリングします。
ステートフルアプリケーションがゾーン間で移行されると、業務中断が発生する場合があります。 中断時間は、ポッドの数、コンテナの起動速度、およびディスク容量によって異なります。
前提条件
Kubernetes 1.20以降を実行するACKクラスターが作成されます。 Container Storage Interface (CSI) プラグインがボリュームプラグインとして使用されます。 詳細については、「ACK管理クラスターの作成」をご参照ください。
ACK専用クラスターを使用する場合は、ワーカーロールとマスターロールに次の権限を付与する必要があります。 詳細については、「カスタムポリシーの作成」をご参照ください。
説明ACK Proクラスターを使用する場合、上記のRAM権限を付与する必要はありません。
storage-operatorコンポーネントのバージョンはv1.26.2-1de13b6-aliyun以降です。 storage-operatorの更新方法の詳細については、「コンポーネントの管理」をご参照ください。
storage-operatorコンポーネントを使用したステートフルアプリケーションの移行
次のコマンドを実行して、storage-operatorのConfigMapを変更します。
kubectl patch configmap/storage-operator \ -n kube-system \ --type merge \ -p '{"data":{"storage-controller":"{\"imageRep\":\"acs/storage-controller\",\"imageTag\":\"\",\"install\":\"true\",\"template\":\"/acs/templates/storage-controller/install.yaml\",\"type\":\"deployment\"}"}}'
次のコマンドを実行して、ステートフルなアプリケーション移行タスクを作成します。
cat <<EOF | kubectl apply -f - apiVersion: storage.alibabacloud.com/v1beta1 kind: ContainerStorageOperator metadata: name: default spec: operationType: APPMIGRATE operationParams: stsName: web stsNamespace: default stsType: kube targetZone: cn-beijing-h,cn-beijing-j checkWaitingMinutes: "1" healthDurationMinutes: "1" snapshotRetentionDays: "2" retainSourcePV: "true" EOF
パラメーター
必須 / 任意
説明
operationType
可
この値をAPPMIGRATEに設定します。これは、ステートフルアプリケーションを移行する操作を実行することを指定します。
stsName
可
ステートフルアプリケーションの名前。 指定できるアプリケーションは1つだけです。
説明複数のステートフルなアプリケーション移行タスクを作成する場合、コンポーネントはタスク作成時の順にタスクを実行します。
stsNamespace
可
アプリケーションが属する名前空間。
targetZone
可
アプリケーションの移行先ゾーン。 複数のゾーンはコンマ (,) で区切ります。 例:
cn-beijing-h,cn-beijing-j
アプリケーションによって使用されるディスクがリスト内のゾーンに既に存在する場合、ディスクは移行されません。
複数の宛先ゾーンが指定されている場合、残りのディスクはリスト内のゾーンの順序でゾーンに分散されます。
stsType
不可
ステートフルアプリケーションのタイプ。 デフォルト値: kube。 有効な値:
kube: Kubernetes StatefulSet。
kruise: OpenKruiseコンポーネントによって提供される高度なStatefulSet。
checkWaitingMinutes
不可
コンポーネントがターゲットゾーン内のアプリケーションのステータスをチェックする間隔。 単位:分
デフォルト値:
"1"
コンポーネントは、アプリケーションのポッドが元の数に達するか、アプリケーションが連続してステータスチェックに合格しなかった場合にアプリケーションがソースゾーンにロールバックされるまで、1分間隔でアプリケーションのステータスをチェックします。重要アプリケーションのポッド数が多すぎる場合、イメージの取得に時間がかかる場合、またはアプリケーションの起動に長い時間がかかる場合は、間隔を長くすることができます。 そうしないと、アプリケーションがステータスチェックに複数回合格しなかった後、アプリケーションがロールバックされる可能性があります。
healthDurationMinutes
不可
コンポーネントがアプリケーションのステータスをダブルチェックするまでの待機時間。 単位:分 コンポーネントは、アプリケーションのポッドが予想される数に達した後、スケジュールされた時間にアプリケーションのステータスを二重にチェックします。 これにより、データに敏感なビジネスの信頼性が向上します。
デフォルト値:
"0"
。これは、コンポーネントがアプリケーションをダブルチェックしないことを示します。snapshotRetentionDays
不可
IAスナップショットの保持期間。 単位:日 有効な値:
"1"
: 1日。 デフォルト値です。"-1"
: IAスナップショットを永久に保持します。
retainSourcePV
不可
元のディスクとPVを保持するかどうかを指定します。 有効な値:
"false"
: 元のディスクとPVを保持しません。 デフォルト値です。"true"
: 元のディスクとPVを保持します。 元のディスクはElastic Compute Service (ECS) コンソールで確認できます。 元のディスクボリュームのステータスがリリースに変わります。
例
次の例では、テストクラスターはcn-beijingリージョンにデプロイされたACK Proクラスターです。 クラスターには、cn-beijing-i、cn-beijing-j、cn-beijing-kゾーンにそれぞれデプロイされたnode-zone-i、node-zone-j、node-zone-kノードが含まれます。
例1: ゾーン間でのディスクの移行
手順1: ESSDを使用するステートフルアプリケーションの作成
次のコマンドを実行して、nginxという名前のステートフルアプリケーションをクラスターにデプロイします。
次のコマンドを実行して、アプリケーションのポッドの配置を照会します。
kubectl get pod -owide | grep web-
期待される出力:
NAME READY STATUS RESTARTS AGE IP ZONE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 44s 172.29.XX.XX node-zone-i <none> <none> web-1 1/1 Running 0 3s 172.29.XX.XX node-zone-j <none> <none>
出力は、cn-beijing-iゾーンとcn-beijing-jゾーンのノードにそれぞれ2つのポッドがデプロイされていることを示します。 実際の展開はスケジューラによって異なります。
手順2: ステートフルなアプリケーション移行タスクの作成
次のコマンドを実行して、ステートフルなアプリケーション移行タスクを作成します。
次の移行タスクでは、2つのポッドをcn-beijing-kゾーンに移行します。 移行を開始する前に、cn-beijing-kゾーンのノードに十分なリソースがあり、ゾーンとノードがESSDをサポートしていることを確認してください。
cat <<EOF | kubectl apply -f - apiVersion: storage.alibabacloud.com/v1beta1 kind: ContainerStorageOperator metadata: name: migrate-to-k spec: operationType: APPMIGRATE operationParams: stsName: web stsNamespace: default stsType: kube targetZone: cn-beijing-k # # Specify cn-beijing-k as the destination zone. healthDurationMinutes: "1" # Wait 1 minute and then check the status of the application after the migration is complete. snapshotRetentionDays: "-1" # Permanently retain the snapshots. You can manually delete the snapshots in the console. retainSourcePV: "true" # Retain the original disks and PVs. EOF
次のコマンドを実行して、移行タスクのステータスを照会します。
kubectl describe cso migrate-to-k | grep Status
期待される出力:
Status: SUCCESS
出力に
SUCCESS
が表示された場合、移行タスクは期待どおりに実行されます。 出力にFAILED
が表示された場合、移行タスクの作成に失敗しました。 問題のトラブルシューティング方法の詳細については、「 (オプション) 移行タスクの作成失敗のトラブルシューティング」をご参照ください。次のコマンドを実行して、2つのポッドのデプロイを照会します。
kubectl get pod -owide | grep web-
期待される出力:
NAME READY STATUS RESTARTS AGE IP ZONE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 25m 172.29.XX.XX node-zone-k <none> <none> web-1 1/1 Running 0 25m 172.29.XX.XX node-zone-k <none> <none>
出力は、ポッドがcn-beijing-kゾーンのノードに移行されたことを示します。
ECSコンソールにログインします。
次の情報を確認します。
新しく作成されたIAスナップショットが永久に保持されるかどうか。
新しく作成されたディスクがcn-beijing-kゾーンにあるかどうか。
移行タスクの
retainSourcePV
パラメーターがtrue
に設定されているため、cn-beijing-iおよびcn-beijing-jゾーンのディスクとPVが保持されているかどうか。
(オプション) 移行タスクの作成失敗のトラブルシューティング
ステップ2の出力で、移行タスクがFAILED状態であることが示されている場合は、次の手順を実行して問題を解決し、再試行します。
次のコマンドを実行して、アプリケーションがロールバックされたことを確認します。
kubectl get pod -owide | grep web-
期待される出力:
NAME READY STATUS RESTARTS AGE IP ZONE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 12m 172.29.XX.XX node-zone-i <none> <none> web-1 1/1 Running 0 12m 172.29.XX.XX node-zone-j <none> <none>
次のコマンドを実行して、障害の原因を照会します。
kubectl describe cso migrate-to-k | grep Message -A 1
期待される出力:
Message: Consume: no pvc mounted in statefulset or no pvc need to migrated web
出力は、移行するディスクボリュームのPVCが存在しないため、移行タスクの作成に失敗したことを示しています。 この問題は、ボリュームがアプリケーションにマウントされていない場合、ボリュームが既にターゲットゾーンに存在する場合、またはシステムがPVC情報の取得に失敗した場合に発生します。 原因に基づいて設定を変更し、もう一度お試しください。
例2: ゾーン間でディスクを広げる
この例では、ステートフルアプリケーションに、cn-beijing-kゾーンのnode-beijing-kノードにデプロイされた2つのポッドがあります。 アプリケーションの可用性を向上させるために、ポッドをcn-beijing-iゾーンとcn-beijing-jゾーンに広げることができます。 これを行うには、次の手順を実行します。
次のコマンドを実行して、ステートフルなアプリケーション移行タスクを作成します。
cat <<EOF | kubectl apply -f - apiVersion: storage.alibabacloud.com/v1beta1 kind: ContainerStorageOperator metadata: name: migrate-to-i-and-j spec: operationType: APPMIGRATE operationParams: stsName: web stsNamespace: default stsType: kube targetZone: cn-beijing-i,cn-beijing-j # Specify cn-beijing-i and cn-beijing-j as the destination zones. healthDurationMinutes: "1" # Wait 1 minute and then check the status of the application after the migration is complete. snapshotRetentionDays: "-1" # Permanently retain the snapshots. You can manually delete the snapshots in the console. retainSourcePV: "true" # Retain the original disks and PVs. EOF
次のコマンドを実行して、移行タスクのステータスを照会します。
kubectl describe cso migrate-to-i-and-j | grep Status
期待される出力:
Status: SUCCESS
次のコマンドを実行して、2つのポッドのデプロイを照会します。
kubectl get pod -owide | grep web-
期待される出力:
NAME READY STATUS RESTARTS AGE IP ZONE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 12m 172.29.XX.XX node-zone-i <none> <none> web-1 1/1 Running 0 12m 172.29.XX.XX node-zone-j <none> <none>
出力は、2つのポッドがcn-beijing-iゾーンとcn-beijing-jゾーンに広がっていることを示します。
ECSコンソールにログインします。
次の情報を確認します。
新しく作成されたIAスナップショットが永久に保持されるかどうか。
新しく作成されたディスクがcn-beijing-iゾーンとcn-beijing-jゾーンにあるかどうか。
移行タスクの
retainSourcePV
パラメーターがtrue
に設定されているため、cn-beijing-kゾーンのディスクとPVが保持されているかどうか。