Azure Kubernetes Service (AKS) のゾーンの回復性に関するレコメンデーション

適用対象: ✔️ AKS 自動 ✔️ AKS Standard

ゾーンの回復性は、運用グレードの Kubernetes クラスターを実行する上で重要な部分です。 その中核となるスケーラビリティにより、Kubernetes は、必要な場合にのみ新しいノードをプロビジョニングして、追加コストを発生させることなく、データ センター内の独立したインフラストラクチャを最大限に活用します。

この記事では、次の方法を含む、AKS でのゾーンの回復性に関する推奨事項について説明します。

• AKS クラスター コンポーネントゾーンの回復性を高めよう。
• ゾーン障害シナリオ用のステートレス アプリケーションを設計します。
• ストレージ冗長オプションを選択します。
• ゾーン 障害時のアプリケーションとプラットフォームの動作をテストします。

AKS クラスター モードとゾーンの回復性

AKS では、次の 2 つのクラスター モードがサポートされています。

• AKS Automatic。これは、より多くの事前構成済みプラットフォームの既定設定を提供します。
• AKS Standard。より広範な直接的なオペレーター制御を提供します。

この記事のゾーンの回復性の原則は、両方のクラスター モードに適用されます。 主な違いは、プラットフォーム操作の所有権です。

モードごとの完全な機能動作については、AKS 自動機能と AKS Standard 機能の比較に関する記事を参照してください。

AKS クラスター コンポーネントのゾーンの回復性を高める

次のセクションでは、AKS でのゾーンの回復性に関する重要な決定ポイントについて説明します。 これらは網羅的ではありません。 また、データ ストア、ID システム、外部サービスなどの依存関係に対するゾーンの回復性も検証する必要があります。

ゾーン冗長クラスターとノード プールを作成する

AKS を使用すると、クラスターとノード プールの作成時に複数の AZ を選択できます。 複数の AZ をサポートするリージョンでは、コントロール プレーンはゾーン間で自動的に分散されます。 ノード プール ノードは、選択したゾーンに分散されます。 この方法により、コントロール プレーンとノードが複数の AZ に分散され、AZ で障害が発生したときの回復性が提供されます。

クラスター モードのガイダンス:

• AKS 自動: 多くのプラットフォームの既定値が事前に構成されています。 ビジネス クリティカルなワークロードが意図的に複数のゾーンに分散されていること、および障害の動作が要件を満たしていることを検証する必要があります。
• AKS Standard: ノード プール トポロジ、スケーリング設定、および障害ドメインの動作を明示的に設計します。

次の例では、Azure CLI を使用して、3 つのノードが 3 つの AZ に分散されたクラスターを作成する方法を示します。

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

クラスターが作成されたら、次のコマンドを使用して、各エージェント ノードのリージョンと可用性ゾーンをラベルから取得します。

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

次に示すのは、各エージェント ノードのリージョンと可用性ゾーンの出力例です。

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

詳細については、「Azure Kubernetes Service (AKS) で可用性ゾーンを使用する」を参照してください。

ポッドが複数の AZ に分散されるようにする

ポッドの配置戦略は、AKS Automatic と AKS Standard の両方でワークロード レベルの懸念事項です。 プラットフォームの既定値は、ワークロード レベルのトポロジ要件に代わるものではありません。

Kubernetes バージョン 1.33 以降では、AKS の既定の Kube-Scheduler は、MaxSkewに topology.kubernetes.io/zone 値 1 を使用するように構成されています。

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

この構成は、ゾーン間のポッドの違いを 1 つ以上ターゲットとしないため、ゾーンの障害によってデプロイが停止する可能性が低くなります。

デプロイに特定のトポロジが必要な場合は、ポッド スペックでこれらの既定値をオーバーライドします。 zone ラベルと hostname ラベルに基づくポッド トポロジ分散制約を使用して、リージョン内の AZ 間および AZ 内のホスト間でポッドを分散できます。

たとえば、app: mypod-app というラベルが付いた 3 つのポッドがそれぞれ node1、node2、node3 に配置されている 4 ノード クラスターがあるとします。 受信デプロイを個別のノードで可能な限りホストする場合は、次の例のようなマニフェストを使用できます。

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

ポッド配布の構成と MaxSkewの影響の詳細については、 Kubernetes ポッド トポロジのドキュメントを参照してください。 たとえば、 nodeTaintsPolicy: Honor がポッドの配布に与える影響などです。

AZ 対応ネットワークを構成する

ネットワーク トラフィックを提供するポッドがある場合は、アプリケーションの高可用性と障害に対する回復性を確保するため、複数の AZ 間にトラフィックを負荷分散する必要があります。 Azure Load Balancer を使用すると、AKS クラスター内のノード間に着信トラフィックを分散できます。

Azure Load Balancer は内部と外部両方の負荷分散をサポートしており、ゾーン冗長負荷分散に Standard SKU を使うように構成できます。 Standard SKU は AKS の既定の SKU であり、アプリケーションがリージョンの障害による影響を受けないように、可用性ゾーンを使用してリージョンの回復性をサポートします。 ゾーンで障害が発生した場合でも、ゾーン冗長 Standard SKU ロード バランサーは障害の影響を受けず、デプロイは残りのゾーンからのトラフィックに引き続き対応できます。 Front Door や Traffic Manager などのグローバルなロード バランサーを使用するか、リージョンの AKS クラスターの前に配置されたリージョン間ロード バランサーを使用して、アプリケーションが地域的な障害の影響を受けないようにします。 AKS での Standard SKU ロード バランサーの作成については、「Azure Kubernetes Service (AKS) で標準のロード バランサーを使用する」を参照してください。

アプリケーションのネットワーク トラフィックが障害に対して回復性を持つようにするには、AKS ワークロード用に AZ 対応ネットワークを構成する必要があります。 Azure には、AZ をサポートするさまざまなネットワーク サービスが用意されています。

• Azure VPN Gateway: Azure AZ に VPN と ExpressRoute ゲートウェイをデプロイすると、仮想ネットワーク ゲートウェイに対する回復性、スケーラビリティ、可用性を向上させることができます。 詳細については、「可用性ゾーンでゾーン冗長仮想ネットワーク ゲートウェイを作成する」を参照してください。
• Azure Application Gateway v2: Azure Application Gateway は、可用性ゾーンのサポートを備えたリージョン L7 ロード バランサーを提供します。 詳細については、「Azure Application Gateway 経由で Web トラフィックを転送する」を参照してください。
• Azure Front Door: Azure Front Door はグローバル L7 ロード バランサーを提供し、ポイント オブ プレゼンス (POP) または Azure Content Delivery Network (CDN) を活用します。 詳細については、「Azure Front Door POP ロケーション」を参照してください。

ゾーン冗長の geo レプリケートされたコンテナー レジストリを設定する

コンテナー イメージが高可用で、障害に対する回復性を確保するには、ゾーン冗長コンテナー レジストリを設定する必要があります。 Azure Container Registry (ACR) Premium SKU は、geo レプリケーションと冗長をサポートします。 これらの機能は、可用性を提供し、地域的な運用における遅延を低減します。

キーとシークレットの可用性と冗長性を確実にする

Azure Key Vault が提供する複数レイヤーの冗長性により、サービスの各コンポーネントで障害が発生した場合や、Azure リージョンまたは AZ が使用できない場合でも、アプリケーションでキーとシークレットを引き続き使用できます。 詳細については、「Azure Key Vault の可用性と冗長性」を参照してください。

自動スケール機能を使用する

自動スケーリング機能を使用すると、AKS でのアプリケーションの可用性と回復性を向上させることができます。これは次の目標を達成するのに役立ちます。

• ポッドの CPU とメモリの使用量に基づいて拡張縮小し、リソース使用率とコスト効率を最適化します。
• ゾーン障害が発生した際に、ノードまたはポッドを追加して、フォールト トレランスと復旧を強化します。

Horizontal Pod Autoscaler (HPA) および Cluster Autoscaler を使用すると AKS で自動スケーリングを実装できます。 HPA は、観察された CPU 使用率、メモリ使用率、カスタム メトリック、他のサービスのメトリックに基づいて、デプロイ内のポッド数を自動的にスケーリングします。 クラスター オートスケーラーは、保留中のポッドと保留中のポッドのリソース要求に基づいて、ノード プール内のノードの数を自動的に調整します。

クラスター モードのガイダンス:

• AKS 自動: ワークロードの要求と制限、ポッド配布ポリシー、中断制御に重点を置いて、構成済みのプラットフォームスケーリングがゾーンストレス時にサービスを復旧できるようにします。
• AKS Standard: ゾーン対応のスケジュール制約に合わせて、ノード プールの境界、スケーリング ポリシー、および自動スケーラー設定を明示的に設計します。

AKS Karpenter プロバイダー機能を使用すると、AKS クラスターで Karpenter を使用したノードの自動プロビジョニングが可能になります。 詳細については、「AKS Karpenter Provider 機能の概要」を参照してください。

AKS 用の Kubernetes Event-driven Autoscaling (KEDA) アドオンを、イベント駆動型自動スケーリングに適用し、外部サービスのメトリックに基づいて需要を満たすようにアプリケーションをスケーリングします。 詳細については、「Azure Kubernetes Service (AKS) に KEDA アドオンをインストールする」を参照してください。

AKS クラスター モードによるゾーン スケーリング戦略

ゾーン対応のスケールアップ動作の場合は、ノード プール モデルをスケジューラ制約とクラスター モードに合わせます。

AKS Standard

可用性ゾーンでクラスター オートスケーラーを使用する場合の一般的なベスト プラクティスは、ゾーンごとに 1 つのノード プールです。 --balance-similar-node-groupsをTrueに設定して、スケールアップ中にゾーン間のノード分散のバランスを維持できます。

これが重要な理由:

• クラスター オートスケーラーは、特定のゾーン配置ではなく、ノード プールごとのスケジュール設定をシミュレートします。
• マルチゾーン ノード プールでは、スケールアップによって、厳密なトポロジ分散制約にまだ違反しているゾーンに新しいノードを配置でき、ポッドは保留中のままです。
• Virtual Machine Scale Sets では、ベスト エフォートゾーン分散が使用されます。 ゾーン容量の制約またはゾーンダウン イベント中に、割り当てが失敗し、ノード プールがバックオフに配置される可能性があります。
• ゾーンごとに 1 つのノード プールを使用すると、ゾーン固有のスケーリング動作の制御が向上します。

クラスター オートスケーラーはゾーン対応ではなく、ゾーンの割り当ては基になるVirtual Machine Scale Setsによって処理され、AKS では処理されません。 このベスト プラクティスは、単一のマルチゾーン ノード プールでゾーン ベースの ポッド トポロジ分散制約 を使用する場合に、さらに関連性が高まります。これは、制限付き制約によって、特に容量が制約されたリージョンやゾーンダウン シナリオでポッドが保留中の状態になる可能性があるためです。

AKS Automatic

AKS Automatic では、事前構成済みのマネージド ノードの動作とノードの自動プロビジョニングの既定値が使用されます。 ワークロード レベルのポリシーがないと、重要なワークロードがゾーン回復性を持っているとは考えられません。

重要なサービスの場合は、次を検証します。

• ポッド トポロジは、ゾーン間で動作を分散します。
• ゾーン圧中の回復動作。
• 厳密な制約が使用される場合の結果のスケジュール設定。
• 1 つのゾーンが使用できなくなった場合のアプリケーションの動作。

ステートレス アプリケーションを設計する

アプリケーションがステートレスの場合、アプリケーションのロジックとデータは切り離されて、ポッドはローカル ディスクに永続データまたはセッション データを格納しません。 この設計により、データ損失を気にすることなく、アプリケーションを簡単に拡張縮小できます。 ステートレス アプリケーションは、ノード障害が発生した場合に、別のノードで簡単に置き換えたり、再スケジュールしたりできるため、障害に対する回復性が高くなります。

AKS を使用してステートレス アプリケーションを設計する場合は、Azure Databases、Azure Managed Redis、Azure Storage などのマネージド Azure サービスを使用して、アプリケーション データを格納する必要があります。 これらのサービスを使用すると、データ損失のリスクやユーザー エクスペリエンスへの影響なしに、ノード間とゾーン間でトラフィックを移動できます。 Kubernetes の Deployment、Service、Health Probe を使用すると、ステートレス ポッドを管理でき、ゾーン間に均等に分散できます。

ストレージ ディスクに関する決定を行う

アプリケーションのニーズに基づいて適切なディスクの種類を選択する

Azure には、永続ストレージ用に、ローカル冗長ストレージ (LRS) とゾーン冗長ストレージ (ZRS) の 2 種類のディスクがあります。 LRS は、1 つの AZ 内でデータをレプリケートします。 ZRS は、1 つのリージョン内の複数の AZ 間でデータをレプリケートします。 AKS バージョン 1.29 以降の既定のストレージ クラスでは、永続ストレージに ZRS ディスクが使用されます。 詳細については、「AKS 組み込みストレージ クラス」を参照してください。

アプリケーションがデータをレプリケートする方法は、ディスクの選択に影響を与える可能性があります。 アプリケーションが複数のゾーンに配置され、アプリケーション内からデータをレプリケートする場合、各 AZ の LRS ディスクで回復性を実現できます。これは、1 つの AZ がダウンした場合でも、他の AZ は最新のデータを使用できるためです。 アプリケーション レイヤーでこのようなレプリケーションが処理されない場合は、Azure がストレージ レイヤーでレプリケーションを処理する ZRS ディスクが、より良い選択になります。

次の表は、各ディスクの種類の長所と短所の概要を示したものです。

LRS と ZRS のディスクの種類については、「Azure Storage の冗長性」を参照してください。 AKS の プロビジョニング ストレージ ディスクの詳細については、「Azure Kubernetes Service (AKS) で Azure ディスク ストレージをプロビジョニングする」を参照してください。

ディスク パフォーマンスを監視する

AKS でストレージ ディスクのパフォーマンスと可用性が最適になるようにするには、IOPS、スループット、遅延などの主要なメトリックを監視する必要があります。 これらのメトリックは、アプリケーションのパフォーマンスに影響を与える可能性がある問題やボトルネックを特定するのに役立ちます。 パフォーマンスに常に問題がある場合は、ストレージ ディスクの種類またはサイズを再検討してください。 Azure Monitor を使用すると、これらのメトリックを収集して視覚化し、パフォーマンスの問題を通知するアラートを設定できます。

詳細については、「Azure Monitor のコンテナー正常性機能を使用して Azure Kubernetes Service (AKS) を監視する」を参照してください。

AZ の回復性をテストする

方法 1: 単一 AZ でノードを切断してドレインする

AKS クラスターで AZ の回復性をテストする方法の 1 つとして、あるゾーンのノードをドレインし、別のゾーンにフェールオーバーするまで、トラフィックにどのような影響があるか確認することが挙げられます。 この方法は、障害または停止が原因でゾーン全体が使用できなくなる実際のシナリオをシミュレートします。 このシナリオをテストするには、kubectl drain コマンドを使用して、ノードからすべてのポッドを適切に削除し、スケジュール不可としてマークします。 その後、Azure Monitor や Prometheus などのツールを使用すると、クラスターのトラフィックとパフォーマンスを監視できます。

次の表は、この方法の長所と短所を示しています。

方法 2: Azure Chaos Studio を使用して AZ の障害をシミュレートする

AKS クラスターで AZ の回復性をテストするもう 1 つの方法は、Azure Chaos Studio を使って、クラスターに障害を挿入してアプリケーションへの影響を観察することです。 Azure Chaos Studio は、Azure リソースとサービスでカオス実験を作成および管理できるサービスです。 Chaos Studio を使うと、特定のゾーンをターゲットにしてそのゾーン内の仮想マシン (VM) を停止または再起動するフォールト挿入実験を作成し、AZ 障害をシミュレートできます。 その後、メトリックとログを使用して、アプリケーションの可用性、遅延、エラー率を測定できます。

次の表は、この方法の長所と短所を示しています。

詳細については、「Azure Chaos Studio とは」を参照してください。

関連するコンテンツ

• AKS Automatic とは
• ゾーン冗長 AKS クラスターとストレージのガイド