Container Service for Kubernetes:ディスクボリュームの高可用性のための推奨構成

要件

• NAS ファイルシステムではなくディスクを使用してデータを永続化します。 NAS ファイルシステムと比較して、ディスクはより安定しており、データ転送のためのより高い帯域幅を提供します。

• 十分なノードとストレージリソースを確保するために、3 つのゾーンにクラスタをデプロイします。

• クラスタ内のすべてのノードが使用できなくなった場合にノードを追加できるように、ノードの自動スケーリングを有効にします。

• マウントの失敗を回避するために、使用する StorageClass に複数のディスクカテゴリを指定することをお勧めします。

• アプリケーションのポッドを異なるゾーンのノードに均等に分散できるようにします。

推奨されるノードプール構成

• 各ノードプールを単一のゾーンにのみデプロイします。

  • 新しいゾーンのノードをクラスタに追加する場合は、新しいゾーンに新しいノードプールを作成することをお勧めします。詳細については、「ノードプールの作成と管理」をご参照ください。

  • クラスタにノードプールを作成する場合は、各ノードプールが別々のゾーンにデプロイされていることを確認してください。ノードプールのゾーンを識別しやすくするために、ノードプール名にゾーン ID を指定することをお勧めします。

• ノードプールの自動スケーリングを有効にします。詳細については、「ノードの自動スケーリングを有効にする」をご参照ください。

  ノードプールの自動スケーリングを有効にすると、ノードプール内のすべてのノードがポッドのスケジューリングに使用できなくなった場合、システムは自動的にノードプールにノードを追加します。次の図は、ノードの自動スケーリングの例を示しています。

• 同じタイプの Elastic Compute Service (ECS) インスタンスを使用して異なるゾーンにノードプールをデプロイするか、同じタイプのブロックストレージをサポートする ECS インスタンスを使用して異なるゾーンにノードプールをデプロイします。

  クラウドディスクをアタッチできる ECS インスタンスタイプは、ディスクのカテゴリによって異なります。そのため、ディスクと ECS インスタンスが同じゾーンにある場合でも、ポッドにマウントされたディスクのカテゴリがポッドをホストする ECS インスタンスでサポートされていないために、ポッドの起動に失敗することがあります。

• 無関係なアプリケーションがノードにスケジュールされないように、ノードプール内のすべてのノードに taint を追加します。

推奨されるクラスタ構成

• クラスタの Kubernetes バージョンが 1.20 以降であることを確認します。

• クラスタにインストールされている Container Storage Interface (CSI) プラグインのバージョンが 1.22 以降であることを確認します。詳細については、「CSI プラグインの管理」をご参照ください。

• 使用する StorageClass に複数のディスクカテゴリを指定します。

  YAML テンプレートの例:

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: alicloud-disk-topology-alltype
  parameters:
    type: cloud_essd,cloud_ssd,cloud_efficiency
  provisioner: diskplugin.csi.alibabacloud.com
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer
  allowVolumeExpansion: true
  allowedTopologies:
  - matchLabelExpressions:
    - key: topology.diskplugin.csi.alibabacloud.com/zone
      values:
      - cn-beijing-a
      - cn-beijing-b

  パラメータの説明:

  • type: cloud_essd,cloud_ssd,cloud_efficiency: システムは、企業向け SSD (ESSD)、標準 SSD、Ultra ディスクの順序でカテゴリのディスクを作成しようとします。システムは最初に ESSD の作成を試みます。 ESSD の在庫がない場合、システムは標準 SSD の作成を試みます。標準 SSD の在庫がない場合、システムは Ultra ディスクの作成を試みます。これにより、在庫不足によるディスク作成エラーのリスクが軽減され、ポッドの起動エラーを防ぐのに役立ちます。

  • volumeBindingMode: WaitForFirstConsumer: StorageClass を使用するポッドがノードにスケジュールされると、システムは StorageClass に基づいて、ノードがデプロイされているゾーンにディスクを作成しようとします。これにより、ゾーンの不整合によるディスクマウントエラーのリスクが軽減され、ポッドの起動エラーを防ぐのに役立ちます。

  • allowedTopologies: このパラメータを使用して、特定のリージョンおよびゾーンの StorageClass を使用してプロビジョニングされたボリュームのトポロジードメインを制限できます。 volumeBindingMode を WaitForFirstConsumer に設定すると、スケジューラは StorageClass を使用するポッドを指定されたトポロジードメインにスケジュールして、ディスク作成の要件を満たします。

推奨されるアプリケーション構成

次のサンプルコードは、標準の StatefulSet テンプレートの例を示しています。ビジネス要件に基づいてテンプレートをカスタマイズできます。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: mysql
        maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "mysql"
        volumeMounts:
        - name: disk-csi
          mountPath: /var/lib/mysql
      tolerations:
      - key: "app"
        operator: "Exists"
        effect: "NoSchedule"
  volumeClaimTemplates:
  - metadata:
      name: disk-csi
    spec:
      accessModes: [ "ReadWriteMany" ]
      storageClassName: alicloud-disk-topology-alltype
      resources:
        requests:
          storage: 40Gi

パラメータの説明:

• topologySpreadConstraints: システムは、アプリケーションによってプロビジョニングされたポッドを異なるゾーンに分散しようとします。詳細については、「トポロジースプレッド制約」をご参照ください。

• volumeClaimTemplates: システムは、複製されたポッドごとに自動的にディスクを作成します。これは、アプリケーションを迅速にスケールアウトするのに役立ちます。