すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:ディスクボリュームを使用するステートフルアプリケーションをゾーン間で移行する

    ドキュメントセンター

    Container Service for Kubernetes:ディスクボリュームを使用するステートフルアプリケーションをゾーン間で移行する

    最終更新日:Nov 09, 2025

    storage-operator コンポーネントは、ディスクボリュームを使用するステートフルアプリケーション (StatefulSet) のクロスゾーン移行およびマルチゾーンへの分散機能を提供し、自動化されたクロスゾーン移行を可能にします。移行中に例外が発生した場合、storage-operator コンポーネントは事前チェックおよびロールバックメカニズムを通じて元のゾーンでアプリケーションを復元し、ビジネスの可用性を確保します。このトピックでは、ディスクボリュームを使用するステートフルアプリケーションをゾーン間で移行する方法について説明します。

    シナリオ

    • 計画の変更、マルチゾーンデプロイメントを必要とするアプリケーション規模の拡大、または現在のゾーンのリソースが不足している場合に、デプロイ済みのステートフルアプリケーションを他のゾーンに移行する必要がある場合があります。

    • NAS および OSS ストレージは、クロスゾーンおよびマルチマウントでの使用をサポートしています。ただし、ディスク自体にはゾーンをまたいでフローティングする機能がなく、ストレージ要求とボリュームを再利用できません。この場合、ディスクボリュームを使用するステートフルアプリケーションを新しいゾーンに移行する必要があります。

    • ビジネスの中断を受け入れることができるアプリケーション。複数のレプリカを持つステートフルアプリケーションの場合、データ整合性を確保するために、移行前にアプリケーションを 0 レプリカにスケールダウンし、ディスク移行が完了した後に一度に元のレプリカ数に復元します。ローリング移行は使用しません。

      重要

      ステートフルアプリケーションのクロスゾーン移行中にビジネスの中断が発生する可能性があります。中断時間は、レプリカ数、コンテナーの起動速度、使用されるディスク容量などの要因によって異なります。

    仕組みと移行手順

    ディスクを使用するアプリケーションのクロスゾーン移行は、ディスクスナップショット機能に依存しており、新しく作成されたスナップショットの保持期間の設定をサポートしています。ディスクスナップショットの詳細については、「スナップショットの概要」をご参照ください。スナップショットの課金の詳細については、「スナップショットの課金」をご参照ください。

    storage-operator コンポーネントは、ディスクボリュームを使用するステートフルアプリケーションに対して、次の移行プロセスを提供します。

    1. 移行対象のアプリケーションが正常に実行されているか、移行が必要なディスクがあるかなどの関連する事前チェックを実行します。チェックに失敗した場合、移行は続行されません。

    2. ディスクタイプのステートフルアプリケーションを 0 レプリカにスケールダウンします。この時点で、アプリケーションは一時停止状態になります。

    3. 移行対象のステートフルアプリケーションにマウントされているディスクのスナップショットを作成します。スナップショットはクロスゾーンでの使用をサポートしています。

    4. スナップショットが利用可能であることを確認した後、それらを使用してターゲットゾーンに新しいディスクを作成します。新しいディスクは元のディスクと同じデータを持っています。

    5. 同じ名前のストレージ要求とそれに対応する新しいボリュームを再構築し、新しいディスクにバインドします。

    6. ディスクタイプのステートフルアプリケーションのレプリカを元の数に復元し、再構築されたストレージ要求に自動的に関連付け、実際に新しいディスクをマウントします。

      重要

      事前チェックが完了し、移行が開始されると、各ステップは異なる失敗時のロールバック戦略に対応します。ロールバック後にアプリケーションが元のディスクをマウントでき、データ損失を回避できるように、ディスクを削除する前に、移行後にステートフルアプリケーションが正常に実行されていることを確認してください。

    7. (オプション) ステートフルアプリケーションが正常に実行されていることを確認した後、元のボリュームと対応するディスクを削除します。ディスクの課金の詳細については、「ブロックストレージの課金」をご参照ください。

    使用上の注意

    • 移行対象のステートフルアプリケーションが使用するすべてのストレージは、ESSD ディスクである必要があります。

      スナップショットの作成時間を改善するために、この機能は移行中に高速スナップショットを使用します。具体的な操作については、「スナップショットの高速アクセス」をご参照ください。現在、高速スナップショットは ESSD ディスクのみをサポートしています。アプリケーションが ESSD 以外のタイプのディスクを使用している場合は、次の方法で対処できます。

    • ターゲットゾーンは ESSD ディスクをサポートしている必要があり、クラスターにはターゲットゾーンに ESSD ディスクをサポートするスケジューリング可能なノードが必要です。

    前提条件

    • クラスターが Kubernetes 1.20 以降を使用しており、Container Storage Interface (CSI) プラグインがインストールされていること。

      クラスターをアップグレードするには、「クラスターの手動アップグレード」をご参照ください。

    • storage-operator コンポーネントが、バージョン v1.26.2-1de13b6-aliyun 以降でクラスターにインストールされていること。詳細については、「storage-operator コンポーネントの管理」をご参照ください。

    • csi-plugin および csi-provisioner コンポーネントがクラスターにインストールされており、インストールされている csi-provisioner は非マネージドバージョンであること。

      説明

      現在インストールされているコンポーネントが csi-provisioner のマネージドバージョンである場合、マネージドバージョンをアンインストールして非マネージドバージョンを再インストールできます。CSI コンポーネントを切り替えた後、kubectl delete pod -n kube-system <storage-controller-pod-name> を実行してストレージコントローラを再起動できます。

    • クラスターが ACK 専用クラスターである場合、クラスターのワーカーの Resource Access Management (RAM) ロールとマスターの RAM ロールに ModifyDiskSpec 操作を呼び出す権限があることを確認する必要があります。詳細については、「カスタムポリシーの作成」をご参照ください。

      この権限付与は ACK マネージドクラスターには必要ありません。

      クリックしてポリシーの内容を表示

      {
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:CreateSnapshot",
                "ecs:DescribeSnapshot",
                "ecs:DeleteSnapshot",
                "ecs:ModifyDiskSpec",
                "ecs:DescribeTaskAttribute"
            ],
            "Resource": "*"
        }
    ]
}

    使用方法

    1. クラスター内の 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\"}"}}'

    2. クラスターでステートフルアプリケーション移行タスクを作成します。

      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

      必須

      ステートフルアプリケーションの名前。現在、単一のステートフルアプリケーションの指定のみをサポートしています。

      説明

      複数のステートフルアプリケーションの移行タスクをデプロイする場合、コンポーネントはデプロイ時間の順に順次移行します。

      stsNamespace

      必須

      ステートフルアプリケーションが配置されている名前空間。

      targetZone

      必須

      移行先のターゲットゾーンのリスト。複数のターゲットゾーンがある場合は、コンマ (,) で区切ります。例: cn-beijing-h,cn-beijing-j。

      • アプリケーションによってマウントされたディスクがすでにリストにある場合、アプリケーションは移行されません。

      • ターゲットゾーンが複数ある場合、残りのディスクはリストに表示される順序で各ターゲットゾーンに移行されます。

      stsType

      オプション

      指定されたステートフルアプリケーションのタイプ。デフォルトは kube です。有効な値:

      • kube: ネイティブの StatefulSet。

      • kruise: OpenKruise コンポーネントによって提供される高度な StatefulSet。

      checkWaitingMinutes

      オプション

      移行後にステートフルアプリケーションがターゲットゾーンで起動するときのステータスチェックのポーリング間隔 (分単位)。

      デフォルトは "1" で、利用可能なレプリカの数が期待される数と一致するまで、または複数回のチェック試行が失敗した後に元のゾーンにロールバックするまで、1 分に 1 回チェックすることを意味します。

      重要

      レプリカ数が多かったり、イメージのプル時間が長かったり、ビジネスの起動時間が長かったりするアプリケーションの場合は、リトライ試行が多すぎることによるアプリケーションのロールバックを避けるために、ポーリング間隔を適切に長くする必要があります。

      healthDurationMinutes

      オプション

      2 次チェックの間隔 (分単位)。ステートフルアプリケーションの移行が完了し、利用可能なレプリカの数が期待される数と一致した後に 2 次チェックが実行されます。システムは、データに敏感なビジネスの移行の信頼性を高めるために、2 次チェックを実行する前に指定された時間待機します。

      デフォルトは "0" で、2 次チェックは実行されないことを意味します。

      snapshotRetentionDays

      オプション

      移行中に新しく作成された高速スナップショットの保持期間 (日数)。有効な値:

      • "1": デフォルト値。1 日間保持されます。

      • "-1": 高速スナップショットを永続的に保持します。

      retainSourcePV

      オプション

      元のディスクとそれに対応するクラスター内のボリュームリソースを保持するかどうか。有効な値:

      • "false": デフォルト値。保持しません。

      • "true": 保持します。ECS コンソールにログインして元のディスクインスタンスを見つけることができ、クラスター内の対応するボリュームリソースは削除されません。ボリュームは Released 状態になります。

    例

    テストクラスターは、以下に示すように、異なるゾーンの複数のノードを含む 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 ディスクを使用するステートフルアプリケーションを作成する

    後続のテストのために、クラスターに ESSD ディスクを使用する StatefulSet を作成します。すでに関連するテストリソースがある場合は、このステップをスキップできます。

    1. StatefulSet を作成し、ESSD ディスクをマウントします。

      Nginx ステートフルアプリケーションをデプロイするための YAML ファイルを表示

      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

    2. StatefulSet 内の Pod のデプロイメントステータスを確認します。

      kubectl get pod -o wide -l app=nginx

      以下の応答例は、Node フィールドによると、両方の 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: クロスゾーン移行

    1. ステートフルアプリケーション移行タスクを作成します。

      次の移行タスクの例では、StatefulSet の 2 つの Pod すべてが cn-shanghai-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

    2. 移行タスクのステータスをクエリします。

      kubectl describe cso migrate-to-b | grep Status

      期待される応答は次のとおりです。SUCCESS が返された場合、移行タスクのステータスが正常であることを示します。

        Status:
    Status:   SUCCESS
      説明

      FAILED が返された場合、移行タスクが失敗したことを示します。トラブルシューティングについては、「よくある質問」をご参照ください。

    3. 移行後、StatefulSet 内の 2 つの Pod のデプロイメントステータスをクエリします。

      kubectl get pod -o wide -l app=nginx

      以下の応答例は、両方の Pod が cn-shanghai.192.168.5.245 ノード (ゾーン B に対応) に移行されたことを示しています。

      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>

    4. ECS コンソールで移行タスクが期待どおりに完了したことを確認します。

      • [スナップショット] ページで、2 つの新しいスナップショットが作成され、永続的に保持されていることを確認します。

      • [ブロックストレージ] ページで、移行後にゾーン B に 2 つの新しいディスクが作成され、元のゾーン M の 2 つのディスクが削除されていないことを確認します (移行タスクの retainSourcePV 構成が true に設定されているため)。

    例 2: マルチゾーンへの分散

    アプリケーションの可用性を向上させるために、Pod とディスクを異なるゾーンに分散させる必要があります。

    1. ステートフルアプリケーション移行タスクを作成します。

      次の移行タスクの例では、StatefulSet の 2 つの Pod がゾーン 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   # 移行先のターゲットゾーン。複数のゾーンが構成されている場合、Pod は自動的に分散されます。
    healthDurationMinutes: "1"                # 移行後 1 分間待機して、アプリケーションが正常に実行されていることを確認します。
    snapshotRetentionDays: "-1"               # 新しく作成されたスナップショットは、コンソールで削除されるまで長期間保持されます。
    retainSourcePV: "true"                    # 元のゾーンのディスクと対応する PV を保持します。
EOF

    2. 移行タスクのステータスをクエリします。

      kubectl describe cso migrate | grep Status

      期待される応答は次のとおりです。SUCCESS が返された場合、移行タスクのステータスが正常であることを示します。

        Status:
    Status:   SUCCESS
      説明

      FAILED が返された場合、移行タスクが失敗したことを示します。トラブルシューティングについては、「よくある質問」をご参照ください。

    3. 移行後、StatefulSet 内の 2 つの Pod のデプロイメントステータスをクエリします。

      kubectl get pod -o wide -l app=nginx

      以下の応答例は、2 つの Pod が cn-shanghai.192.168.5.245 ノード (ゾーン B) と cn-shanghai.192.168.2.214 ノード (ゾーン G) に分散されたことを示しています。

      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>

    4. ECS コンソールで移行タスクが期待どおりに完了したことを確認します。

      • [スナップショット] ページで、2 つの新しいスナップショットが作成され、永続的に保持されていることを確認します。

      • [ブロックストレージ] ページで、移行後にゾーン B とゾーン G に 2 つの新しいディスクが作成され、元のゾーン M の 2 つのディスクが削除されていないことを確認します (移行タスクの retainSourcePV 構成が true に設定されているため)。

    よくある質問

    移行タスクのステータスが 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