Improve availability for an ASM ingress gateway - Alibaba Cloud Service Mesh

イングレスゲートウェイは、Service Mesh (ASM) インスタンス内のサービスに対する単一のトラフィックエントリーポイントです。すべてのゲートウェイ Pod が同じノードまたは同じゾーンで実行されている場合、ノードまたはゾーンの障害によりゲートウェイ全体が停止し、すべてのインバウンドトラフィックがブロックされます。ゲートウェイ Pod を複数のノードまたはゾーンに分散することで、この単一障害点が解消され、インフラストラクチャの障害発生時でもトラフィックが流れ続けます。

このアプローチは、ご利用のクラスタータイプによって異なります。

クラスタータイプ	戦略	理由
ACK クラスター	ポッドアンチアフィニティ	Kubernetes スケジューリングルールにより、Pod をノードまたはゾーンに分散します。
ACK Serverless クラスター	ECI Pod アノテーション	ポッドアンチアフィニティはサーバーレスクラスターではサポートされていません。代わりに vSwitch ベースのゾーン分散を使用します。

前提条件

開始する前に、以下を確認してください。

ASM インスタンスが作成されていること。詳細については、「ASM インスタンスの作成」をご参照ください。
Container Service for Kubernetes (ACK) クラスターまたは ACK Serverless クラスターがあること。詳細については、「ACK マネージドクラスターの作成」または「ACK Serverless クラスターの作成」をご参照ください。
クラスターが ASM インスタンスに追加されていること。

ACK クラスターでのゲートウェイ Pod の分散

スケジューラが複数のゲートウェイ Pod を同じノードまたは同じゾーンに配置しないように、ご利用の IstioGateway リソースでポッドアンチアフィニティポリシーを構成します。

スケジューリング制約の選択

Kubernetes は 2 つのアンチアフィニティモードを提供します。ご利用のクラスター容量に基づいて選択してください。

モード	フィールド名	動作	使用時期
ソフト (デフォルト)	`preferredDuringSchedulingIgnoredDuringExecution`	スケジューラはルールを尊重しようとしますが、準拠するノードが利用できない場合でも Pod をスケジュールします。	ノード数が制限されているか、オートスケーリングによって変動します。
ハード	`requiredDuringSchedulingIgnoredDuringExecution`	スケジューラはルールを厳密に適用します。準拠するノードが存在しない場合、Pod は保留状態のままになります。	クラスターには、ノードまたはゾーンごとに 1 つの Pod を保証するのに十分なノードがあります。

以下の例では、ソフト制約を使用しています。ハード制約に切り替えるには、preferredDuringSchedulingIgnoredDuringExecution を requiredDuringSchedulingIgnoredDuringExecution に置き換え、weight フィールドを削除します。

ノード間での Pod の分散

各ノードで最大 1 つのゲートウェイ Pod が実行されるように、topologyKey を kubernetes.io/hostname に設定します。

apiVersion: istio.alibabacloud.com/v1beta1
kind: IstioGateway
metadata:
  name: ingressgateway-1
  namespace: istio-system
spec:
  clusterIds:
    - "c954ee9df88f64f229591f0ea4c61****"
  cpu:
    targetAverageUtilization: 80
  externalTrafficPolicy: Local
  maxReplicas: 4
  minReplicas: 2
  ports:
  - name: status-port
    port: 15020
    targetPort: 15020
  - name: http2
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 80
  - name: tls
    port: 15443
    targetPort: 15443
  replicaCount: 1
  resources:
    limits:
      cpu: '2'
      memory: 2G
    requests:
      cpu: 200m
      memory: 256Mi
  sds:
    enabled: true
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 2000m
        memory: 1024Mi
  serviceType: LoadBalancer
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - istio-ingressgateway-1     # ゲートウェイの app ラベルと一致する必要があります
          topologyKey: kubernetes.io/hostname # ノードごとに 1 つの Pod
        weight: 100
  rollingMaxSurge: "100%"
  rollingMaxUnavailable: "25%"

ゾーン間での Pod の分散

個々のノードではなく可用性ゾーン間で Pod を分散するには、topologyKey を topology.kubernetes.io/zone に変更します。他のすべてのフィールドは同じままです。

  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - istio-ingressgateway-1
          topologyKey: topology.kubernetes.io/zone  # ゾーンごとに 1 つの Pod
        weight: 100

ゾーンレベルの分散は、ゾーン全体の停止から保護しますが、クラスターが複数のゾーンにまたがる必要があります。すべてのノードがシングルゾーンにある場合は、ノードレベルの分散で十分です。

アンチアフィニティフィールドリファレンス

フィールド	説明
`preferredDuringSchedulingIgnoredDuringExecution`	ソフトアンチアフィニティ。スケジューラはこのルールを尊重することを優先しますが、準拠するノードが利用できない場合でもスケジューリングをブロックしません。
`requiredDuringSchedulingIgnoredDuringExecution`	ハードアンチアフィニティ。スケジューラはこのルールを厳密に適用します。準拠するノードが存在しない場合、Pod は保留状態のままになります。
`matchExpressions`	ラベルで Pod を選択します。この例では、`key: app`、`operator: In`、`values: istio-ingressgateway-1` は、ラベル `app=istio-ingressgateway-1` を持つ Pod をターゲットにします。
`topologyKey`	アンチアフィニティルールのスコープを定義します。ノードレベルの場合は `kubernetes.io/hostname`、ゾーンレベルの分散の場合は `topology.kubernetes.io/zone` に設定します。
`weight`	このルールの優先度 (1～100)。`100` の重みは、スケジューリング中に最高の優先度を与えます。ソフトアンチアフィニティにのみ適用されます。

ACK Serverless クラスターでのゲートウェイ Pod の分散

ACK Serverless クラスターはポッドアンチアフィニティをサポートしていません。これは、Pod が固定ノードなしで Elastic Container Instance (ECI) インスタンスとして実行されるためです。代わりに、Pod アノテーションを使用して ECI Pod をゾーン間で分散します。

ACK Serverless クラスターで複数のゾーンを構成します。詳細については、「ゾーン間での ECI の作成」をご参照ください。

ゲートウェイを異なるゾーンの vSwitch に関連付けるために、IstioGateway リソースに podAnnotations を追加します。

アノテーション	説明
`k8s.aliyun.com/eci-vswitch`	関連付けされるゾーンの仮想プライベートクラウド (VPC) に属する vSwitch の ID。各 vSwitch は異なるゾーンに属しているため、Pod はそれらのゾーンに分散されます。
`k8s.aliyun.com/eci-schedule-strategy`	ECI Pod のスケジューリング戦略。`VSwitchRandom` は ECI Pod をランダムモードでゾーンに割り当てます。

   apiVersion: istio.alibabacloud.com/v1beta1
   kind: IstioGateway
   metadata:
     name: ingressgateway
     namespace: istio-system
   spec:
     clusterIds:
       - "c954ee9df88f64f229591f0ea4c61****"
     cpu:
       targetAverageUtilization: 80
     externalTrafficPolicy: Local
     maxReplicas: 4
     minReplicas: 2
     ports:
     - name: status-port
       port: 15020
       targetPort: 15020
     - name: http2
       port: 80
       targetPort: 80
     - name: https
       port: 443
       targetPort: 80
     - name: tls
       port: 15443
       targetPort: 15443
     replicaCount: 1
     resources:
       limits:
         cpu: '2'
         memory: 2G
       requests:
         cpu: 200m
         memory: 256Mi
     sds:
       enabled: true
       resources:
         requests:
           cpu: 100m
           memory: 128Mi
         limits:
           cpu: 2000m
           memory: 1024Mi
     serviceType: LoadBalancer
     podAnnotations:
       k8s.aliyun.com/eci-vswitch: "vsw-bp1b07j0miob3khtn****,vsw-bp12b85hh323se8ft****"
       k8s.aliyun.com/eci-schedule-strategy: "VSwitchRandom"
     rollingMaxSurge: "100%"
     rollingMaxUnavailable: "25%"

追加の可用性対策

Pod 分散は、イングレスゲートウェイの可用性の 1 つのレイヤーです。本番環境の場合、以下の対策と組み合わせることを検討してください。

測定	目的
`HorizontalPodAutoscaler`	CPU またはメモリ使用率に基づいてゲートウェイ Pod の数を自動的にスケーリングします。`IstioGateway` リソースは、`minReplicas`、`maxReplicas`、および `cpu.targetAverageUtilization` を介してこれをすでにサポートしています。
ヘルスチェックとモニタリング	ゲートウェイ Pod のステータスを監視し、Pod の再起動またはスケジューリングの失敗に対するアラートを設定して、可用性の問題を早期に検出します。