Container Service for Kubernetes:ACK クラスター高可用性アーキテクチャの推奨構成

本ドキュメントのガイダンス

このトピックは、Container Service for Kubernetes を使用するクラスター開発者および管理者向けです。高可用性クラスターの計画と構築に関する一般的な推奨事項を提供します。実際の構成は、ご利用のクラスター環境とビジネス要件によって異なる場合があります。このトピックで提案されているコントロールプレーンとデータプレーンの高可用性構成を参考にしてください。

クラスターアーキテクチャの例

ACK クラスターは、コントロールプレーンと、通常のノードまたは仮想ノードの2つの主要な部分で構成されています。

• クラスターコントロールプレーンは、ワークロードのスケジューリングやクラスターの状態の維持など、クラスターを管理および調整します。ACK マネージドクラスターを例にとると、ACK マネージドクラスターは、Kube API Server、etcd、Kube Scheduler などのクラスターのコントロールプレーンコンポーネントをホストするために Kubernetes-on-Kubernetes アーキテクチャを使用します。

• 通常のノードまたは仮想ノード: ACK クラスターは、ECS インスタンスである通常のノードと仮想ノードをサポートします。ノードは実際のワークロードを実行し、コンテナを実行するためのリソースを提供します。

デフォルトでは、ACK クラスターはマルチアベイラビリティーゾーン (マルチ AZ) の高可用性クラスターデプロイメントアーキテクチャを提供します。たとえば、次の図はACK マネージドクラスターのクラスターアーキテクチャを示しています。

コントロールプレーンアーキテクチャの高可用性

ACK マネージドクラスター (Pro Edition および Basic Edition)、ACK Serverless クラスター (Pro Edition および Basic Edition)、ACK Edge クラスター、および LINGJUN Clusters などのマネージド ACK クラスターの場合、ACK はそれらのコントロールプレーンと、kube-apiserver、etcd、kube-scheduler などの関連コンポーネントを管理します。

• マルチゾーンリージョン: すべてのマネージドコンポーネントは、マルチレプリカ、マルチ AZ のバランスの取れたデプロイメント戦略を使用します。これにより、単一のゾーンまたはノードに障害が発生した場合でも、クラスターはサービスを提供し続けることができます。

• シングルゾーンリージョン: すべてのマネージドコンポーネントは、マルチレプリカ、マルチノードのデプロイメント戦略を使用します。これにより、単一のノードに障害が発生した場合でも、クラスターはサービスを提供し続けることができます。

具体的には、etcd は少なくとも3つのレプリカを持ち、kube-apiserver は少なくとも2つのレプリカを持ちます。すべての kube-apiserver レプリカは、Elastic Network Interfaces (ENIs) をマウントすることでクラスター VPC とのネットワーク接続を実現します。ノード上の kubelet と Kube Proxy は、API Server Classic Load Balancer (CLB) または ENI を介して kube-apiserver に接続します。

すべての ACK のコア管理コンポーネントは、CPU 使用量およびメモリ使用量などの実際のリソース使用量に基づいて弾力的にスケールできます。この機能により、API サーバーのリソース要件を動的に満たし、安定したサービス レベル アグリーメント (SLA) の保証を提供します。

クラスターコントロールプレーンのデフォルトのマルチゾーン高可用性アーキテクチャに加えて、クラスターデータプレーンの高可用性アーキテクチャも構成する必要があります。これには、ノードプールと仮想ノードの高可用性構成、ワークロード高可用性構成、ロードバランシング高可用性構成、および コンポーネントの推奨構成が含まれます。

ノードプールと仮想ノードの高可用性構成

ACK クラスターは、通常のノード (ECS インスタンス) と仮想ノードをサポートします。ノードプールを使用してノードを管理できます。これにより、アップグレード、スケーリング、日常の O&M などの操作のためにノードをグループ化できます。サービスへのトラフィックが比較的安定しているか、予測可能なピークとトラフがある場合は、ECS インスタンスを使用することをお勧めします。サービスが予測できない瞬間的なピークを経験する場合は、仮想ノードを使用してバーストトラフィックを処理し、コンピューティングコストを削減できます。詳細については、「ノードプール」、「マネージドノードプールの概要」、および「仮想ノード」をご参照ください。

ノードプール高可用性構成

ノードの自動スケーリング、デプロイメントセット、およびマルチゾーンデプロイメントを Kubernetes スケジューリングトポロジースプレッド制約と組み合わせて使用できます。これにより、サービスは異なる障害ドメイン間で十分かつ隔離されたリソースを確保できます。障害ドメインで問題が発生した場合でも、サービスは引き続き実行されます。これにより、単一障害点のリスクが軽減され、システム全体の信頼性と可用性が向上します。

ノードの自動スケーリングの構成

各ノードプールは Auto Scaling グループ (ESS) によってバックアップされています。これにより、ロードスケジューリングレイヤーまたはクラスターリソースレイヤーでのノードの手動スケーリングと自動スケーリングがサポートされます。これにより、より低いコストとより高い柔軟性でエラスティックコンピューティングリソースを調整できます。ACK の自動スケーリングソリューションの詳細については、「自動スケーリング」および「ノードの自動スケーリングの有効化」をご参照ください。

デプロイメントセットの有効化

デプロイメントセットは、ECS インスタンスの分散を制御する戦略です。この戦略は、ECS インスタンスを異なる物理サーバーに分散させ、単一の物理マシン障害による複数の ECS インスタンスの障害を防ぎます。ノードプールにデプロイメントセットを指定して、ノードプールによってスケールアウトされた ECS インスタンスが同じ物理マシンに分散されないようにすることができます。アフィニティ構成により、アプリケーションは基盤となるノードトポロジーを認識し、異なるノードに均等に分散されます。これにより、アプリケーションのディザスタリカバリ機能と高可用性が保証されます。デプロイメントセット機能の有効化の詳細については、「ノードプールデプロイメントセットのベストプラクティス」をご参照ください。

マルチ AZ 分散の構成

ACK はマルチゾーンノードプールをサポートしています。ノードプールを作成して実行するときに、ノードプールに異なるゾーンの複数の vSwitch を選択できます。スケーリングポリシー を構成するときに、分散バランスポリシー を選択します。これにより、ECS インスタンスは、スケーリンググループで指定されたゾーン (複数の vSwitch に対応) に均等に分散されます。在庫切れなどの理由でゾーン間でリソースの不均衡が発生した場合、リバランス操作を実行してゾーン間のリソース分散をバランスさせることができます。自動スケーリングポリシーの構成の詳細については、「ノードの自動スケーリングの有効化」をご参照ください。

トポロジースプレッド制約の有効化

ノードの自動スケーリング、デプロイメントセット、およびマルチゾーン分散は、Kubernetes スケジューリングトポロジースプレッド制約 (Topology Spread Constraints) と組み合わせて、異なるレベルの障害ドメインの隔離を実現するのに役立ちます。ACK ノードプールのすべてのノードには、kubernetes.io/hostname、topology.kubernetes.io/zone、および topology.kubernetes.io/region などのトポロジー関連のラベルが自動的に追加されます。トポロジースプレッド制約を使用して、Pod が異なる障害ドメインにどのように分散されるかを制御できます。これにより、基盤となるインフラストラクチャ障害に対する耐性が向上します。

複数のトポロジー ドメインでの Pod の再試行や、同じ低レイテンシーデプロイメントセットに属する ECS インスタンスへの Pod のスケジューリングなど、ACK クラスターでのトポロジーアウェアスケジューリングの使用方法の詳細については、「トポロジーアウェアスケジューリング」をご参照ください。

仮想ノード高可用性構成

ACK 仮想ノードを使用すると、Elastic Container Instance (ECI) 上で Pod を迅速にスケジューリングして実行できます。ECI を使用すると、基盤となる ECS サーバーを購入および管理する必要がありません。これにより、基盤となるインフラストラクチャのメンテナンスではなく、コンテナ化されたアプリケーションに集中できます。必要に応じて ECI インスタンスを作成し、コンテナに構成されたリソースに対してのみ、秒単位で課金される従量課金で支払うことができます。

ただし、バーストトラフィックを処理するためにサービスを水平方向に迅速にスケールアウトしたり、Job タスク処理のために多数のインスタンスを起動したりすると、指定されたゾーンでのインスタンス在庫不足や、指定された vSwitch での IP アドレスの枯渇などの状況に遭遇する可能性があります。これにより、ECI インスタンスの作成が失敗する可能性があります。ACK Serverless クラスターのマルチゾーン機能は、ECI インスタンス作成の成功率を向上させるのに役立ちます。

仮想ノードの ECI Profile を構成し、異なるゾーンの vSwitch を指定することで、マルチゾーンアプリケーションデプロイメントを実現できます。

• ECI は、Pod 作成リクエストをすべての vSwitch に分散させ、負荷を効果的に分散します。

• vSwitch の在庫不足により Pod を作成できない場合、ECI は自動的に次の vSwitch を使用して Pod の作成を試行します。

次のコマンドを実行して、kube-system/eci-profile ConfigMap の vSwitchIds フィールドを変更できます。複数の ID をコンマ (,) で区切って vSwitch ID を追加できます。変更はすぐに有効になります。詳細については、「マルチゾーン ECI Pod の作成」をご参照ください。

kubectl -n kube-system edit cm eci-profile

apiVersion: v1
data:
  kube-proxy: "true"
  privatezone: "true"
  quota-cpu: "192000"
  quota-memory: 640Ti
  quota-pods: "4000"
  regionId: cn-hangzhou
  resourcegroup: ""
  securitygroupId: sg-xxx
  vpcId: vpc-xxx
  vSwitchIds: vsw-xxx,vsw-yyy,vsw-zzz
kind: ConfigMap

ワークロード高可用性構成

ワークロードの高可用性は、アプリケーション Pod が正常に実行されること、または障害発生時に迅速に回復できることを保証します。トポロジースプレッド制約、Pod アンチアフィニティ、Pod Disruption Budget (PDB)、および自己修復による Pod ヘルスチェックを構成することで、アプリケーション Pod の高可用性を実現できます。

トポロジースプレッド制約の構成

トポロジースプレッド制約 (Topology Spread Constraints) は、Kubernetes クラスターにおける Pod 分散を管理する機能です。これにより、Pod が異なるノードやゾーンに均等に分散され、アプリケーションの高可用性と安定性が向上します。このテクノロジーは、Deployment、StatefulSet、DaemonSet、Job、CronJob などのワークロードタイプに適用されます。

maxSkew.topologyKey などの構成を設定して、Pod 分散を制御できます。これにより、Pod がクラスター内の目的のトポロジーに基づいてデプロイされることが保証されます。たとえば、異なるゾーンにワークロードを均等に分散することで、信頼性と可用性を向上させることができます。以下に例を示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-zone
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-zone
  template:
    metadata:
      labels:
        app: app-run-per-zone
    spec:
      containers:
        - name: app-container
          image: app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: app-run-per-zone

Pod アンチアフィニティの構成

Pod アンチアフィニティは、Kubernetes スケジューリングポリシーです。これにより、Pod が同じノードにスケジューリングされないことが保証され、アプリケーションの高可用性と障害分離が向上します。以下に例を示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-node
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-node
  template:
    metadata:
      labels:
        app: app-run-per-node
    spec:
      containers:
        - name: app-container
          image: app-image
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - app-run-per-node
              topologyKey: "kubernetes.io/hostname"

トポロジースプレッド制約を使用すると、各ノードで最大1つの Pod が実行されるようにすることもできます。topologyKey: "kubernetes.io/hostname" を指定すると、各ノードがトポロジー ドメインとして機能します。

次の例では、トポロジースプレッド制約を作成します。maxSkew は 1 に、topologyKey は "kubernetes.io/hostname" に、whenUnsatisfiable は DoNotSchedule に設定されています。これは、同じトポロジー ドメイン (ノード) 内の Pod の数が、他のドメインよりも最大で1つ多くなることを示します。これにより、ノードの高可用性を実現するために Pod が強制的に分散されます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: my-app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: my-app

Pod Disruption Budget の構成

Pod Disruption Budget (PDB) を使用して、アプリケーションの可用性をさらに向上させることができます。PDB は、利用可能なレプリカの最小数を定義します。ノードがメンテナンス中または障害状態にある場合、クラスターは少なくとも指定された数のレプリカが実行され続けることを保証します。PDB は、一度に多数のレプリカが終了するのを防ぎます。これは、複数のレプリカが大量のトラフィックを処理するシナリオに特に適しています。以下に例を示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-pdb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-with-pdb
  template:
    metadata:
      labels:
        app: app-with-pdb
    spec:
      containers:
        - name: app-container
          image: app-container-image
          ports:
            - containerPort: 80
--- 
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-for-app
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: app-with-pdb

Pod ヘルスチェックと自己修復の構成

ACK クラスターでは、さまざまな種類のプローブを構成して、コンテナーステータスと可用性を監視および管理できます。これには、liveness プローブ、readiness プローブ、および startup プローブが含まれます。これらのプローブは、Pod 構成にそれらと再起動ポリシーを追加することで構成できます。以下に例を示します。

apiVersion: v1
kind: Pod
metadata:
  name: app-with-probe
spec:
  containers:
    - name: app-container
      image: app-image
      livenessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 5
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/ready
        initialDelaySeconds: 20
        periodSeconds: 15
  restartPolicy: Always

ロードバランシング高可用性構成

クラスターにおけるロードバランシングの高可用性を実現することは、サービスの安定性、応答速度、および障害分離を向上させるために不可欠です。Server Load Balancer (SLB) インスタンスのプライマリゾーンとセカンダリゾーンを指定し、トポロジーアウェアヒントを有効にすることで、これを実現できます。

CLB インスタンスのプライマリゾーンとセカンダリゾーンの指定

Classic Load Balancer (CLB) は、ほとんどのリージョンで複数のゾーンにデプロイされ、同じリージョン内でクロスデータセンターディザスタリカバリを実現します。Service アノテーションを使用して、CLB インスタンスのプライマリゾーンとセカンダリゾーンを指定できます。これにより、CLB インスタンスのプライマリゾーンとセカンダリゾーンがノードプールの ECS インスタンスのゾーンと一致することが保証されます。これにより、クロスゾーンデータ転送が削減され、ネットワークアクセス性能が向上します。CLB がサポートするリージョンとゾーンの詳細については、「CLB がサポートするリージョンとゾーン」をご参照ください。CLB インスタンスのプライマリゾーンとセカンダリゾーンの指定の詳細については、「CLB インスタンス作成時のプライマリゾーンとセカンダリゾーンの指定」をご参照ください。

以下に例を示します。

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "cn-hangzhou-b"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "cn-hangzhou-i"
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

トポロジーアウェアヒントの有効化

クロスゾーンネットワークトラフィックを削減し、ネットワーク性能を向上させるために、Kubernetes 1.23 ではトポロジーアウェアルーティング (トポロジーアウェアヒントとも呼ばれる) が導入されました。この機能により、トポロジーアウェア近接ルーティングが可能になります。

Service でこの機能を有効にできます。この機能が有効になると、ゾーン内に十分なエンドポイントがある場合、EndpointSlice コントローラーは、EndpointSlice のトポロジーヒント情報に基づいて、リクエストの発生元に近いエンドポイントにトラフィックをルーティングすることを優先します。クロスゾーンネットワークトラフィックがあるシナリオでは、この機能はネットワークトラフィックを同じゾーン内に維持することを優先します。これにより、ネットワーク効率が向上し、関連コストが削減されます。詳細については、「Topology Aware Routing」をご参照ください。

コンポーネントの推奨構成

ACK はさまざまな種類のコンポーネントを提供します。必要に応じて、新規または既存のクラスターに特定のコンポーネントを構成して、クラスター機能を拡張できます。ACK がサポートするコンポーネント、その説明、および変更履歴の詳細については、「コンポーネントの概要とリリースノート」をご参照ください。構成、アンインストール、アップグレードなど、コンポーネントのアップグレードと管理の詳細については、「コンポーネントの管理」をご参照ください。

参考

• ワーカーノードには、より大きな ECS インスタンスタイプを使用してください。詳細については、「推奨される ECS インスタンスタイプ構成」をご参照ください。

• ご利用の ACK マネージドクラスター Pro Edition が大規模 (通常 500 ノード以上または 10,000 Pod 以上) の場合は、利用に関するアドバイスについて「大規模クラスターの利用に関する推奨事項」をご参照ください。

• ノードとノードプールのベストプラクティスの詳細については、「ノードとノードプールのベストプラクティス」をご参照ください。

• 自動スケーリングのベストプラクティスの詳細については、「自動スケーリングのベストプラクティス」をご参照ください。