次の方法で共有

Azure Kubernetes Service (AKS) のゾーンの回復性に関する考慮事項

この記事では、次のような Azure Kubernetes Service (AKS) でのゾーンの回復性に関するさまざまな考慮事項について説明します。

  • AKS クラスター コンポーネントのゾーンの回復性を高くする
  • ステートレス アプリケーションを設計する
  • ストレージ ディスクに関する決定を行う
  • 可用性ゾーン (AZ) の回復性をテストする

概要

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

重要

クラスター内のノードの数をスケールアップまたはスケールダウンするだけでは、アプリケーションの回復性を確保するのに十分ではありません。 回復性をいっそう適切に計画するには、アプリケーションとその依存関係についてより深く理解する必要があります。 AKS では、クラスターとノード プールのために可用性ゾーン (AZ) を設定し、アプリケーションが障害に対する回復性を持ち、ゾーン全体がダウンした場合でもトラフィックを処理し続けられるようにすることができます。

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

以下のセクションでは、ゾーン回復性を備えた AKS クラスター コンポーネントにするための主要な決定事項に関するガイダンスを提供しますが、すべてを網羅しているわけではありません。 具体的な要件と制約に基づいて他の要因を検討し、他の依存関係を調べて、それらがゾーン回復性のために構成されていることを確認する必要があります。

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

AKS では、クラスターとノード プールの作成時に複数の AZ を選択できます。 複数の AZ を持つリージョンにクラスターを作成すると、そのリージョン内のすべての AZ にコントロール プレーンが自動的に分散されます。 ただし、ノード プール内のノードは、選択した AZ のみに分散されます。 この方法により、コントロール プレーンとノードが複数の AZ に分散され、AZ で障害が発生したときの回復性が提供されます。 Azure portal、Azure CLI、または Azure Resource Manager テンプレートを使用して、AZ を構成できます。

次の例では、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 に分散されるようにする

Kubernetes バージョン 1.33 以降では、AKS の既定の Kube-Scheduler は、次に示すように、topology.kubernetes.io/zoneに MaxSkew 値 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

注

アプリケーションに厳密なゾーン分散要件があり、適切なノードが見つからない場合にポッドを保留中の状態のままにすることが想定される動作である場合は、 whenUnsatisfiable: DoNotScheduleを使用できます。 この構成では、適切なゾーン内のノードまたは別のホストが存在しない場合、またはスケールアップできない場合は、ポッドを保留中のままにするようにスケジューラに指示します。

ポッド配布の構成と MaxSkewの影響の詳細については、 Kubernetes ポッド トポロジのドキュメントを参照してください。

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) での Standard ロード バランサーの使用に関する記事をご覧ください。

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

重要

Azure NAT Gateway では、特定の AZ に NAT ゲートウェイを作成したり、ゾーン デプロイを使って特定のゾーンに分離したりできます。 NAT Gateway は、ゾーン デプロイはサポートしていますが、ゾーン冗長デプロイはサポートしていません。 これは、NAT ゲートウェイと同じアウトバウンドの種類で AKS クラスターを構成し、NAT ゲートウェイが単一のゾーンにある場合に、問題になる可能性があります。 この場合、NAT ゲートウェイをホストしているゾーンがダウンすると、クラスターはアウトバウンド接続を失います。 詳細については、「NAT ゲートウェイと可用性ゾーン」を参照してください。

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

可用性が高く、障害に対する回復性を備えたコンテナー イメージを実現するには、ゾーン冗長コンテナー レジストリを設定する必要があります。 Azure Container Registry (ACR) Premium SKU は、geo レプリケーションと、オプションでゾーン冗長をサポートしています。 これらの機能により、リージョン内の操作の可用性が提供され、待ち時間が短縮されます。

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

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

自動スケーリング機能を利用する

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

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

水平ポッド オートスケーラー (HPA) とクラスター オートスケーラーを使って、AKS に自動スケーリングを実装できます。 HPA は、観察された CPU 使用率、メモリ使用率、カスタム メトリック、他のサービスのメトリックに基づいて、デプロイ内のポッドの数を自動的にスケーリングします。 クラスター オートスケーラーは、ノードで実行されているポッドのリソース要求に基づいて、ノード プール内のノードの数を自動的に調整します。 両方のオートスケーラーを併用したい場合は、オートスケーラーを有効にするノード プールが複数のゾーンにまたがっていることを確認します。 ノード プールが 1 つのゾーン内にあり、そのゾーンがダウンした場合、オートスケーラーはゾーンをまたいでクラスターをスケーリングできません。

AKS Karpenter Provider プレビュー機能を使うと、AKS クラスターで Karpenter を使ってノードを自動プロビジョニングできます。 詳しくは、AKS Karpenter Provider の機能の概要に関する説明をご覧ください。

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

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

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

AKS でステートレス アプリケーションを設計するときは、Azure データベース、Azure Cache for 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 (ラーニング・レコード・ストア) • 低コスト
• すべてのディスク サイズとリージョンでサポートされる
• 使用とプロビジョニングが簡単		 • 可用性と持続性が低い
• ゾーンの障害に対して脆弱
• ゾーンまたは geo レプリケーションをサポートしていない
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 障害をシミュレートできます。 その後、メトリックとログを使って、アプリケーションの可用性、待ち時間、エラー率を測定できます。

次の表は、この方法の長所と短所です。

長所 短所
• 障害を挿入して結果を監視するための、制御および自動化された方法を提供する
• ネットワーク待ち時間、CPU ストレス、ディスク障害など、さまざまな種類の障害とシナリオをサポートする
• データの収集と分析のため、Azure Monitor や他のツールと統合する		 • 実験の作成と実行のため、追加の構成とセットアップが必要な場合がある
• 実際の停止時に発生する可能性のあるすべての障害モードとエッジ ゾーンがカバーされない可能性がある
• 実験の範囲や期間に、制限や制約がある可能性がある

詳しくは、「Azure Chaos Studio とは」をご覧ください。

次のステップ

実装について詳しくは、ゾーン冗長 AKS クラスターとストレージのガイドに関する記事をご覧ください。