storage-operator コンポーネントは、ディスクボリュームを使用する StatefulSet のゾーン間移行およびマルチゾーン分散を自動化します。例外が発生した場合、事前チェックおよびロールバック機構により、元のゾーンでアプリケーションを復元します。本トピックでは、ディスクボリュームを使用するステートフルアプリケーションをゾーン間で移行する方法について説明します。
適用範囲
| シナリオ | 説明 |
|---|---|
| ゾーン計画の変更 | インフラストラクチャまたは容量の更新に伴い、ワークロードを別のゾーンに移動します。 |
| マルチゾーン分散 | 可用性の向上を目的として、レプリカおよびそのディスクを複数のゾーンに分散させます。 |
| リソース制約 | 現在のゾーンには、継続的な運用またはスケールアウトをサポートする十分な容量がありません。 |
NAS および OSS はゾーン間およびマルチマウント利用をサポートしています。一方、ディスクはゾーンにバインドされており、ゾーン間で浮動したり、既存の永続ボリューム要求 (PVC) や永続ボリューム (PV) を再利用することはできません。StatefulSet がディスクボリュームを使用している場合、スナップショットからターゲットゾーンに新しいディスクを作成する必要があります。
制限事項
開始前に、以下の制限事項をご確認ください。
業務停止が必要: ゾーン間移行では、移行前に StatefulSet を 0 レプリカにスケールダウンし、ディスク移行完了後にすべてのレプリカを一度に復元します(ローリングアップデートではありません)。ダウンタイムを計画してください。その持続時間は、レプリカ数、コンテナの起動時間、および使用中のディスク容量によって異なります。
ESSD ディスクのみ対応: StatefulSet で使用されるすべてのストレージは ESSD ディスクである必要があります。この移行機能では、スナップショット作成時間を最小限に抑えるための即時アクセススナップショットが使用されますが、これは ESSD ディスクのみをサポートします。詳細については、「スナップショットの即時アクセス」をご参照ください。
ターゲットゾーンの要件: ターゲットゾーンは ESSD ディスクをサポートしている必要があり、また、クラスターにはそのゾーン内でスケジューリング可能なノードが存在している必要があります。
アプリケーションが非 ESSD ディスクを使用している場合は、移行前に以下のいずれかの操作を行ってください。
手動で 単一のディスクボリュームのスナップショットを作成し、ゾーン間でディスクを再構築します。
仕組み
ゾーン間移行はディスクスナップショットに依存しており、スナップショット作成時間を最小限に抑えるためにインスタントアクセススナップショットを使用します。詳細については、「スナップショットの概要」および「スナップショットの課金」をご参照ください。
storage-operator コンポーネントは、以下の手順を実行します。
事前チェック: アプリケーションが正常に実行されていることを検証し、移行対象のディスクを特定します。事前チェックに失敗した場合、移行は中止されます。
ゼロスケール: StatefulSet を 0 レプリカにスケールダウンし、アプリケーションを一時停止します。
スナップショットの作成: マウント済みのすべてのディスクに対して即時アクセススナップショットを作成します。スナップショットはゾーン非依存であり、任意のゾーンで使用できます。
新規ディスクのプロビジョニング: スナップショットが利用可能であることを確認後、同じデータでターゲットゾーンに新規ディスクを作成します。
PVC および PV の再構築: 同じ名前の PVC およびそれに対応する PV を再構築し、新規ディスクにバインドします。
レプリカの復元: StatefulSet を元のレプリカ数に復元します。レプリカは自動的に再構築された PVC にバインドされ、新規ディスクをマウントします。
(任意)元のリソースの削除: アプリケーションが正常に動作していることを確認後、元の PV およびディスクを削除します。ディスクの課金に関する詳細は、「ブロックストレージの課金」をご参照ください。
事前チェック以降の各ステップには、それぞれ専用のロールバック戦略があります。元のディスクを削除する前に、移行後の StatefulSet が正しく実行されていることを確認してください。これにより、ロールバックが必要になった場合にアプリケーションが元のディスクを再マウントできるようになります。
前提条件
開始する前に、以下の条件を満たしていることをご確認ください。
Kubernetes 1.20 以降を実行するクラスター(Container Storage Interface (CSI) ドライバーがインストール済み)
クラスター内に storage-operator v1.26.2-1de13b6-aliyun 以降がインストール済みであること。インストール手順については、「storage-operator コンポーネントの管理」をご参照ください。
csi-plugin および csi-provisioner コンポーネントがインストール済みであること。また、csi-provisioner は 非マネージド バージョンを使用している必要があります。
現在マネージド版の csi-provisioner がインストールされている場合は、アンインストールして非マネージド版をインストールしてください。切り替え後、ストレージコントローラを再起動します:
kubectl delete pod -n kube-system <storage-controller-pod-name>(ACK 専用クラスターのみ) クラスターのワーカー RAM ロールとマスター RAM ロールには、Elastic Compute Service (ECS) API の
ModifyDiskSpec操作を呼び出す権限が必要です。詳細については、「カスタムポリシーを作成する」をご参照ください。 <details> <summary>必要な RAM ポリシーの表示</summary>ACK マネージドクラスターでは、
ModifyDiskSpec権限は必要ありません。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:CreateSnapshot", "ecs:DescribeSnapshot", "ecs:DeleteSnapshot", "ecs:ModifyDiskSpec", "ecs:DescribeTaskAttribute" ], "Resource": "*" } ] }</details>
StatefulSet のゾーン間移行
ステップ 2:移行タスクの作成
移行タスクを定義する ContainerStorageOperator リソースを作成します。
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 | 必須 | — | 移行対象の StatefulSet の名前です。単一の StatefulSet のみ指定可能です。複数の移行タスクをデプロイした場合、コンポーネントはデプロイ順に順次移行します。 |
stsNamespace | 必須 | — | StatefulSet の名前空間です。 |
targetZone | 必須 | — | ターゲットゾーンのカンマ区切りリスト(例:cn-beijing-h,cn-beijing-j)。リストに含まれるゾーンにすでにディスクが存在する場合、そのディスクは移行されません。複数のゾーンがリストされている場合、残りのディスクはリスト順にゾーン間で分散されます。 |
stsType | 任意 | kube | StatefulSet の種別です。有効な値は、kube(ネイティブ StatefulSet)および kruise(OpenKruise が提供する Advanced StatefulSet)です。 |
checkWaitingMinutes | 任意 | "1" | 移行後のレプリカ可用性を確認するためのポーリング間隔(分単位)です。レプリカ数が多い StatefulSet や、イメージのプルが遅い、または起動時間が長い場合、早期ロールバックを回避するためにこの値を増加させてください。 |
healthDurationMinutes | 任意 | "0" | 可用レプリカ数が期待値と一致した後、二次ヘルスチェックを実行する前に待機する時間(分単位)です。"0" を指定すると、二次チェックはスキップされます。 |
snapshotRetentionDays | 任意 | "1" | 移行中に作成される即時アクセススナップショットの保持期間です。有効な値は、"1"(1 日間)および "-1"(永久保持)です。 |
retainSourcePV | 任意 | "false" | 移行後に元のディスクおよび PV を保持するかどうかを指定します。"false" の場合、両方とも削除されます。"true" の場合、両方とも保持されます — ディスクは ECS コンソール 上で引き続き表示され、PV は Released 状態になります。 |
例
以下の例では、3 つのゾーンにノードを持つ ACK Pro マネージドクラスターを使用します。
ゾーン B: cn-shanghai.192.168.5.245
ゾーン G: cn-shanghai.192.168.2.214
ゾーン M: cn-shanghai.192.168.3.236、cn-shanghai.192.168.3.237

ステップ 1:ESSD ディスクを用いた StatefulSet の作成
ESSD ディスクを用いたテスト用 StatefulSet を作成します。すでに移行対象の StatefulSet をお持ちの場合は、このステップはスキップしてください。
StatefulSet をデプロイします: <details> <summary>Nginx StatefulSet の YAML を表示</summary>
cat << EOF | kubectl apply -f - apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx serviceName: "nginx" replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www labels: app: nginx spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "alicloud-disk-essd" resources: requests: storage: 20Gi EOF</details>
両方の Pod が実行中であることを確認します。
kubectl get pod -o wide -l app=nginx出力結果では、両方の Pod がゾーン M にスケジュールされています(実際の配置はスケジューラに依存)。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 2m 192.168.3.243 cn-shanghai.192.168.3.237 <none> <none> web-1 1/1 Running 0 2m 192.168.3.246 cn-shanghai.192.168.3.236 <none> <none>
ステップ 2:移行タスクの作成
例 1:ゾーン間移行
すべての Pod を単一のターゲットゾーン(本例ではゾーン B)に移行します。
移行前に、ターゲットゾーンに十分なノードリソースが確保されており、ノードスペックが ESSD ディスクをサポートしていることを確認してください。
移行タスクを作成します。
cat <<EOF | kubectl apply -f - apiVersion: storage.alibabacloud.com/v1beta1 kind: ContainerStorageOperator metadata: name: migrate-to-b spec: operationType: APPMIGRATE operationParams: stsName: web stsNamespace: default stsType: kube targetZone: cn-shanghai-b # 移行先のゾーン。 healthDurationMinutes: "1" # 移行後にアプリケーションが正常に実行されていることを確認するため、1 分間待機します。 snapshotRetentionDays: "-1" # スナップショットを手動で削除するまで永久保持します。 retainSourcePV: "true" # 元のディスクおよび PV を保持します。 EOF移行ステータスを確認します。
ステータスが
FAILEDの場合、「よくある質問」を参照してトラブルシューティングを行ってください。kubectl describe cso migrate-to-b | grep StatusSUCCESSステータスは、移行が正常に完了したことを示します。Status: Status: SUCCESS移行後の Pod 配置を確認します。
kubectl get pod -o wide -l app=nginx両方の Pod が、ゾーン B の
cn-shanghai.192.168.5.245ノード上に配置されています。NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 2m36s 192.168.5.250 cn-shanghai.192.168.5.245 <none> <none> web-1 1/1 Running 0 2m14s 192.168.5.2 cn-shanghai.192.168.5.245 <none> <none>ECS コンソール で結果を確認します。
スナップショット ページ:永久保持設定で 2 つの新規スナップショットが作成されました。
ブロックストレージ ページ:ゾーン B に 2 つの新規ディスクが作成されています。ゾーン M の 2 つの元のディスクは保持されています(
retainSourcePVが"true"のため)。
例 2:マルチゾーン分散
可用性の向上を目的として、Pod を 2 つのゾーン(ゾーン B およびゾーン G)に分散します。
移行タスクを作成します。
cat <<EOF | kubectl apply -f - apiVersion: storage.alibabacloud.com/v1beta1 kind: ContainerStorageOperator metadata: name: migrate spec: operationType: APPMIGRATE operationParams: stsName: web stsNamespace: default stsType: kube targetZone: cn-shanghai-b,cn-shanghai-g # ターゲットゾーン。複数のゾーンを指定すると、自動分散がトリガーされます。 healthDurationMinutes: "1" # 移行後にアプリケーションが正常に実行されていることを確認するため、1 分間待機します。 snapshotRetentionDays: "-1" # スナップショットを手動で削除するまで永久保持します。 retainSourcePV: "true" # 元のディスクおよび PV を保持します。 EOF移行ステータスを確認します。
ステータスが
FAILEDの場合、「よくある質問」を参照してトラブルシューティングを行ってください。kubectl describe cso migrate | grep StatusSUCCESSステータスは、移行が正常に完了したことを示します。Status: Status: SUCCESS移行後の Pod 配置を確認します。
kubectl get pod -o wide -l app=nginxPod は、ゾーン B(
cn-shanghai.192.168.5.245)およびゾーン G(cn-shanghai.192.168.2.214)に分散されています。NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-0 1/1 Running 0 4m59s 192.168.2.215 cn-shanghai.192.168.2.214 <none> <none> web-1 1/1 Running 0 4m38s 192.168.5.250 cn-shanghai.192.168.5.245 <none> <none>ECS コンソール で結果を確認します。
スナップショット ページ:永久保持設定で 2 つの新規スナップショットが作成されました。
ブロックストレージ ページ:ゾーン B およびゾーン G に合計 2 つの新規ディスクが作成されています。ゾーン M の 2 つの元のディスクは保持されています。
よくある質問
移行タスクのステータスが FAILED となった場合、以下のコマンドを実行してエラーメッセージを取得します。
kubectl describe cso <ContainerStorageOperator-name> | grep Message -A 1出力例:
Message:
Consume: failed to get target pvc, err: no pvc mounted in statefulset or no pvc need to migrated webこのエラーは、コンポーネントが移行対象の PVC を検出できなかったことを意味します。主な原因は以下のとおりです。
StatefulSet にマウントされたストレージがありません。
すべてのディスクがすでにターゲットゾーンに存在しており、移行の必要がありません。
コンポーネントが PVC 情報を取得できませんでした。
エラーメッセージに基づいて問題を解決し、再度移行タスクを適用してください。