Container Service for Kubernetes:永続ストレージのための動的プロビジョニングされたディスクボリュームの使用

仕組み

StatefulSet を使用した動的ディスクプロビジョニングは、次の 3 つのステップで行われます。

1. テンプレートの定義。 新しい StorageClass を作成するか、デフォルトの StorageClass を使用します。テンプレートでは、ディスクタイプ、パフォーマンスレベル、リクレイムポリシーなどのパラメーターを定義します。

2. ストレージ要件の宣言。 StatefulSet で volumeClaimTemplates を定義し、StorageClass を参照します。これにより、各 Pod が使用するストレージ容量やアクセスモードなどの PVC 仕様を宣言します。

3. ボリュームの自動作成とマウント。 StatefulSet が Pod を作成すると、システムはテンプレートに基づいて Pod ごとに一意の PVC を生成します。Container Storage Interface (CSI) コンポーネントは、StorageClass のルールに基づいて永続ボリューム (PV) を作成し、PV を PVC にバインドして、ディスクを Pod にマウントします。

適用範囲と制限事項

• ゾーンの制限： リージョン ESSD (エンタープライズ SSD) を除くすべてのディスクタイプは、ゾーンをまたいでマウントすることはできません。同じゾーン内の Pod にのみマウントできます。

• インスタンスファミリーの制約：一部のディスクタイプは、特定のインスタンスファミリーにのみアタッチできます。

• CSI コンポーネントの要件: csi-plugin および csi-provisioner コンポーネントがインストールされている必要があります。 > 注: CSI コンポーネントはデフォルトでインストールされています。 手動でアンインストールしていないことを確認してください。 インストールステータスは [アドオン] ページで確認してください。 最適なエクスペリエンスを得るには、CSI コンポーネントをアップグレードして最新バージョンにしてください。

• 仮想ノードの要件： 仮想ノードでディスクを使用するには、クラスターと kube-scheduler のバージョンが次の要件を満たす必要があります。

  クラスターバージョン	kube-scheduler バージョン
  1.28 以降	6.9.3 以降
  1.26	6.8.7
  1.24	6.4.7
  1.22	6.4.5

StorageClass の選択

Container Service for Kubernetes (ACK) は、複数のデフォルト StorageClass を提供します。StorageClass は作成後に変更できません。デフォルトの StorageClass が要件を満たさない場合は、新しい StorageClass を作成してください。詳細については、「手動での StorageClass の作成」をご参照ください。

StatefulSet へのディスクのマウント

各 Pod レプリカが独自の独立したディスクを必要とする場合は、StatefulSet を使用します。

1. statefulset.yaml という名前のファイルを作成します。次の例では、2 つの Pod を持つ StatefulSet を作成します。volumeClaimTemplates を使用して、各 Pod に独立した永続ストレージを自動的に作成し、バインドします。> 重要： Pod で securityContext.fsGroup を設定すると、ボリュームのマウント時に kubelet がファイルの権限を再帰的に変更 (chmod/chown) します。ボリュームに多数のファイルが含まれている場合、これによりマウント時間が大幅に増加します。> > Kubernetes 1.20 以降を実行しているクラスターでは、fsGroupChangePolicy を OnRootMismatch に設定します。これにより、ボリュームのルートディレクトリの権限が必要な権限と一致しない場合にのみ、最初のマウント時に再帰的な権限変更が実行されます。さらなるパフォーマンスチューニングや、より詳細な権限制御が必要な場合は、initContainer を使用して、メインのアプリケーションコンテナーが開始する前に権限調整コマンドを実行します。

      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: web
      spec:
        serviceName: "nginx"
        replicas: 2
        selector:
          matchLabels:
            app: nginx
        template:
          metadata:
            labels:
              app: nginx
          spec:
            # マウントパフォーマンスを最適化するために、次の securityContext を設定します
            securityContext:
              fsGroup: 1000
              fsGroupChangePolicy: "OnRootMismatch"
            containers:
            - name: nginx
              image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
              ports:
              - containerPort: 80
              volumeMounts:
              # データボリュームをコンテナーの /data ディレクトリにマウントします
              # 名前は volumeClaimTemplates で定義された metadata.name と同じでなければなりません
              - name: pvc-disk
                mountPath: /data
        # PVC テンプレートを定義します
        volumeClaimTemplates:
        - metadata:
            name: pvc-disk
          spec:
            # アクセスモード
            accessModes: [ "ReadWriteOnce" ]
            # 事前に作成した StorageClass を関連付けます
            storageClassName: "alicloud-disk-wait-for-first-consumer"
            resources:
              requests:
                # 要求されたストレージ容量、つまりディスクサイズ
                storage: 20Gi

2. StatefulSet を作成します。

      kubectl create -f statefulset.yaml

3. Pod が Running 状態であることを確認します。

      kubectl get pod -l app=nginx

4. マウントパスをチェックし、ディスクがマウントされていることを確認します。> 注意： この例では、Pod 名は web-1 です。実際の Pod 名に置き換えてください。期待される出力：

      kubectl exec web-1 -- df -h /data

      Filesystem      Size  Used Avail Use% Mounted on
      /dev/vdb         20G   24K   20G   1% /data

永続ストレージの検証

Pod が再作成された後もデータが永続化されることを確認するには、Pod にデータを書き込み、Pod を削除してから、データが残っているかどうかを確認します。

1. Pod にテストデータを書き込みます。Pod web-1 の場合、マウントされたディスクパス /data に test ファイルを作成します。期待される出力：

      kubectl exec web-1 -- touch /data/test
      kubectl exec web-1 -- ls /data

      lost+found
      test

2. Pod を削除して Pod の障害をシミュレートします。kubectl get pod -l app=nginx を再度実行します。web-1 という名前の新しい Pod が自動的に作成されます。

      kubectl delete pod web-1

3. 新しい Pod のデータを確認します。新しい Pod web-1 の /data フォルダをチェックします。test ファイルがまだ存在しており、Pod が削除されて再作成された後もデータが永続化されることが確認できます。

      kubectl exec web-1 -- ls /data

      lost+found
      test

単一 Pod または単一レプリカ Deployment へのディスクのマウント

マルチレプリカのスケーリングや安定したネットワーク ID を必要としないアプリケーションの場合は、手動で PVC を作成し、Pod または Deployment にマウントします。

プロセス：StorageClass を選択し、PVC を作成し、アプリケーションで PVC をマウントします。

1. StorageClass を準備します。

2. PVC を作成してストレージリソースを要求します。

   kubectl

   1. disk-pvc.yaml という名前のファイルを作成します。

         apiVersion: v1
         kind: PersistentVolumeClaim
         metadata:
           name: disk-pvc
         spec:
           # アクセスモード
           accessModes:
           - ReadWriteOnce
           volumeMode: Filesystem
           resources:
             requests:
               # 要求されたストレージ容量、つまりディスクサイズ
               storage: 20Gi
           # 事前に作成した StorageClass に関連付けます
           storageClassName: alicloud-disk-topology-alltype

      次の表にパラメーターを説明します。

      パラメーター	説明
      accessModes	ボリュームのアクセスモード。有効な値: ReadWriteOnce、ReadOnlyMany、ReadWriteMany。サポートされる値は、StorageClass の multiAttach 設定および PVC の volumeMode 設定によって異なります。multiAttach は、ディスクのマルチアタッチを有効にするかどうかを指定します。デフォルト: false。 multiAttach が false で、volumeMode が任意の値に設定されている場合、ReadWriteOnce のみがサポートされます。 multiAttach が true で、volumeMode が Filesystem の場合、ReadWriteOnce と ReadOnlyMany のみがサポートされます。 multiAttach が true で、volumeMode が Block の場合、3 つすべてのアクセスモードがサポートされます。 重要： このシナリオでは、アクセスモードは通常 ReadWriteOnce (RWO) であり、ボリュームは一度に 1 つの Pod によってのみマウントできることを意味します。Deployment のレプリカ数は 1 を超えることはできません。Deployment をスケールアウトすると、新しい Pod は既に使用中のディスクをマウントできないため、Pending 状態のままになります。
      volumeMode	永続ボリュームのモード。有効な値： Filesystem (デフォルト)：ボリュームはフォーマットされ、ディレクトリとしてマウントされます。 Block：ボリュームはフォーマットされていないブロックデバイスとして Pod に提供されます。
      storage	リクエストされたストレージ容量です。容量範囲はディスクタイプによって異なります。ディスク作成の失敗を防ぐため、storage の値が、参照される StorageClass に対応するディスクタイプの容量制限に準拠していることを確認してください。
      storageClassName	バインドする StorageClass。

   2. PVC を作成します。

         kubectl create -f disk-pvc.yaml

   3. PVC を表示します。

         kubectl get pvc

      StorageClass は WaitForFirstConsumer モードを使用しているため、PVC はそれを使用する最初の Pod が正常にスケジュールされるまで Pending 状態になります。

         NAME       STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS                            VOLUMEATTRIBUTESCLASS   AGE
         disk-pvc   Pending                                      alicloud-disk-topology-alltype           <unset>                 14s

   コンソール

   1. クラスター管理ページの左側にあるナビゲーションウィンドウで、[ストレージ] > [永続ボリューム要求] を選択します。

   2. [永続ボリューム要求] ページで、[作成] をクリックします。[PVC タイプ] を [クラウドディスク] に設定し、プロンプトに従ってパラメーターを設定します。

      パラメーター	説明
      割り当てモード	[StorageClass を使用]を選択します。
      既存の StorageClass	デフォルトまたは手動で作成された StorageClass。
      容量	リクエストされたストレージ容量です。容量範囲はディスクタイプによって異なります。ディスクの作成が失敗しないように、storage の値が、参照される StorageClass に対応するディスクタイプの容量制限に準拠していることを確認してください。
      アクセスモード	[ReadWriteOnce] のみがサポートされています。これは、ボリュームを単一の Pod によって読み書きモードでマウントできることを意味します。

      PVC が作成されると、[永続ボリューム要求] ページで表示できます。

3. アプリケーションで PVC をマウントします。

   1. disk-deployment.yaml という名前のファイルを作成します。

         apiVersion: apps/v1
         kind: Deployment
         metadata:
           name: single-pod-app
         spec:
           # レプリカ数が 1 であることを確認します
           replicas: 1
           selector:
             matchLabels:
               app: nginx-single
           template:
             metadata:
               labels:
                 app: nginx-single
             spec:
               containers:
               - name: nginx
                 image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
                 ports:
                 - containerPort: 80
                 # コンテナー内のマウントポイントを定義します
                 volumeMounts:
                 - name: my-persistent-storage  # 下の volumes で定義された名前と一致する必要があります
                   mountPath: /data  # コンテナーの /data ディレクトリにマウントします
               # Pod レベルで PVC を宣言し、参照します
               volumes:
               - name: my-persistent-storage # コンテナーによって参照されるボリューム
                 persistentVolumeClaim:
                   claimName: disk-pvc # 事前に作成した PVC を参照します

   2. Deployment をデプロイします。

         kubectl create -f disk-deployment.yaml

4. マウント結果を確認します。

   1. Pod が実行中であることを確認します。

         kubectl get pods -l app=nginx-single

   2. Pod にログインし、ディスクが /data ディレクトリにマウントされているかどうかを確認します。

         # Pod 名を取得します
         POD_NAME=$(kubectl get pods -l app=nginx-single -o jsonpath='{.items[0].metadata.name}')
         # df -h コマンドを実行します
         kubectl exec $POD_NAME -- df -h /data

      次の出力は、20 GiB のディスクが正常にマウントされたことを示しています。

         Filesystem      Size  Used Avail Use% Mounted on
         /dev/vdb         20G   24K   20G   1% /data

本番環境に適用

課金

StorageClass を使用して動的に作成されたディスクは、従量課金で課金されます。詳細については、「Elastic Block Storage の課金」および「Elastic Block Storage の価格」をご参照ください。

よくある質問

参考

• ディスクボリュームを使用する際に問題が発生した場合は、「ディスクボリュームに関するよくある質問」をご参照ください。

• マルチゾーンディスクデプロイメントの最適化に関する推奨事項については、「ディスクボリュームの高可用性に関する推奨構成」をご参照ください。

• クラスターでまだ非推奨のFlexVolume コンポーネントを使用している場合は、FlexVolume を CSI に移行する。

• ワークロードの作成方法の詳細については、「StatefulSet を作成する」および「Deployment を作成する」をご参照ください。

• ディスクの使用を中止し、その課金を停止したい場合は、ディスクをリリースしてください。ディスクをリリースすると、ディスクとそのデータが削除され、課金が停止されます。