すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Dec 11, 2024

ストレージ・オペレータ・コンポーネントは、ディスク・ボリュームとゾーン間ポッド拡散を使用するステートフル・アプリケーションのゾーン間移行を自動化できます。 事前チェック機能とロールバック機能の助けを借りて、ストレージオペレーターコンポーネントは、移行中に例外が発生したときにビジネスの可用性を確保するために、ソースゾーンのアプリケーションを復元できます。 このトピックでは、ディスクボリュームを使用するステートフルアプリケーションをゾーン間で移行する方法について説明します。

シナリオ

  • 展開計画の変更や現在のゾーンのリソースが不足している場合に、ステートフルアプリケーションをゾーン間で移行することができます。

  • File Storage NAS (NAS) ボリュームとObject Storage Service (OSS) ボリュームは、ゾーン間マウントとマルチポッドマウントをサポートしています。 ディスクはゾーン間で移行できないため、ディスクボリュームの永続ボリューム (PV) と永続ボリュームクレーム (PVC) は異なるゾーンで再利用できません。 したがって、ステートフルアプリケーションがディスクボリュームを使用している場合は、アプリケーションを移行先ゾーンに移行する必要があります。

仕組みと移行手順

ディスクボリュームを使用するアプリケーションをゾーン間で移行するには、ディスクスナップショット機能が必要です。 この機能では、ディスクスナップショットの保存期間を指定することもできます。 ディスクスナップショットの詳細については、「スナップショットの概要」をご参照ください。 スナップショットの課金ルールの詳細については、「スナップショット」をご参照ください。

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

  1. 事前チェックを実行します。 たとえば、アプリケーションが期待どおりに実行されるかどうか、および移行する必要のあるディスクがアプリケーションにあるかどうかを確認します。 事前チェックに失敗した場合、アプリケーションは移行されません。

  2. アプリケーションのポッドをゼロにスケーリングします。 スケールインアクティビティの後、アプリケーションは一時停止されます。

  3. アプリケーションによって使用されるディスクのスナップショットを作成します。 スナップショットはゾーン間で使用できます。

  4. スナップショットが有効であることを確認した後、スナップショットを使用してターゲットゾーンにディスクを作成します。 新しく作成されたディスクは、元のディスクと同じデータを格納します。

  5. 同じ名前のPVとPVCを作成し、PVとPVCをディスクにバインドします。

  6. アプリケーションのポッドを元の番号にスケーリングし、ディスクボリュームをポッドにマウントします。

    重要

    コンポーネントは、事前チェック後にアプリケーションを移行します。 移行のステップごとにロールバックポリシーが用意されています。 移行後のデータ損失を回避するには、コンポーネントが元のディスクを削除する前に、アプリケーションが期待どおりに実行されるようにします。

  7. (オプション) アプリケーションが期待どおりに実行されることを確認した後、元のPVとディスクを削除します。 ディスクの課金ルールの詳細については、「EBSデバイス」をご参照ください。

使用上の注意

  • 移行するアプリケーションが拡張SSD (ESSD) のみを使用していることを確認します。

    また、IAスナップショットを選択することもできます。 詳細については、「インスタントアクセス機能の有効化または無効化」をご参照ください。 IAスナップショットはESSDに対してのみ作成できます。 アプリケーションでESSD以外のディスクを使用する場合は、次のいずれかの方法を使用します。

  • 移行先ゾーンがESSDをサポートしていることと、クラスターに移行先ゾーンのアプリケーションのポッドをホストするアイドルノードが含まれていることを確認します。

  • アプリケーションが提供するサービスが中断できることを確認してください。 ステートフルアプリケーションに複数のポッドがある場合は、移行を開始する前にポッドをゼロにスケールして、データの一貫性を確保します。 移行が完了したら、ポッドを元の番号にスケーリングします。

重要

ステートフルアプリケーションがゾーン間で移行されると、業務中断が発生する場合があります。 中断時間は、ポッドの数、コンテナの起動速度、およびディスク容量によって異なります。

前提条件

  • Kubernetes 1.20以降を実行するACKクラスターが作成されます。 Container Storage Interface (CSI) プラグインがボリュームプラグインとして使用されます。 詳細については、「ACK管理クラスターの作成」をご参照ください。

  • ACK専用クラスターを使用する場合は、ワーカーロールとマスターロールに次の権限を付与する必要があります。 詳細については、「カスタムポリシーの作成」をご参照ください。

    ワーカーロールとマスターロールにアタッチされた権限ポリシーのコンテンツの表示

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

    ACK Proクラスターを使用する場合、上記のRAM権限を付与する必要はありません。

  • storage-operatorコンポーネントのバージョンはv1.26.2-1de13b6-aliyun以降です。 storage-operatorの更新方法の詳細については、「コンポーネントの管理」をご参照ください。

storage-operatorコンポーネントを使用したステートフルアプリケーションの移行

  1. 次のコマンドを実行して、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\"}"}}'
  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

    ステートフルアプリケーションの名前。 指定できるアプリケーションは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を使用するステートフルアプリケーションの作成

  1. 次のコマンドを実行して、nginxという名前のステートフルアプリケーションをクラスターにデプロイします。

    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: nginx:1.14.2
              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. 次のコマンドを実行して、アプリケーションのポッドの配置を照会します。

    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: ステートフルなアプリケーション移行タスクの作成

  1. 次のコマンドを実行して、ステートフルなアプリケーション移行タスクを作成します。

    次の移行タスクでは、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
  2. 次のコマンドを実行して、移行タスクのステータスを照会します。

    kubectl describe cso migrate-to-k | grep Status

    期待される出力:

      Status:  SUCCESS

    出力にSUCCESSが表示された場合、移行タスクは期待どおりに実行されます。 出力にFAILEDが表示された場合、移行タスクの作成に失敗しました。 問題のトラブルシューティング方法の詳細については、「 (オプション) 移行タスクの作成失敗のトラブルシューティング」をご参照ください。

  3. 次のコマンドを実行して、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ゾーンのノードに移行されたことを示します。

  4. ECSコンソールにログインします。

    次の情報を確認します。

    • 新しく作成されたIAスナップショットが永久に保持されるかどうか。

    • 新しく作成されたディスクがcn-beijing-kゾーンにあるかどうか。

    • 移行タスクのretainSourcePVパラメーターがtrueに設定されているため、cn-beijing-iおよびcn-beijing-jゾーンのディスクとPVが保持されているかどうか。

(オプション) 移行タスクの作成失敗のトラブルシューティング

ステップ2の出力で、移行タスクがFAILED状態であることが示されている場合は、次の手順を実行して問題を解決し、再試行します。

  1. 次のコマンドを実行して、アプリケーションがロールバックされたことを確認します。

    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. 次のコマンドを実行して、障害の原因を照会します。

    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ゾーンに広げることができます。 これを行うには、次の手順を実行します。

  1. 次のコマンドを実行して、ステートフルなアプリケーション移行タスクを作成します。

    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
  2. 次のコマンドを実行して、移行タスクのステータスを照会します。

    kubectl describe cso migrate-to-i-and-j | grep Status

    期待される出力:

      Status:  SUCCESS
  3. 次のコマンドを実行して、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ゾーンに広がっていることを示します。

  4. ECSコンソールにログインします。

    次の情報を確認します。

    • 新しく作成されたIAスナップショットが永久に保持されるかどうか。

    • 新しく作成されたディスクがcn-beijing-iゾーンとcn-beijing-jゾーンにあるかどうか。

    • 移行タスクのretainSourcePVパラメーターがtrueに設定されているため、cn-beijing-kゾーンのディスクとPVが保持されているかどうか。