Azure Kubernetes Service (AKS) での可用性ゾーン

可用性ゾーンは、データセンターの障害からアプリケーションとデータを保護するのに役立ちます。 ゾーンは、Azure リージョン内の一意の物理的な場所です。 各ゾーンには、独立した電源、冷却、ネットワーキングを備えた 1 つ以上のデータセンターが含まれます。

可用性ゾーンで AKS を使用すると、単一リージョン内の異なる可用性ゾーン間でリソースが物理的に分散され、信頼性が向上します。 複数のゾーンにノードを展開しても追加コストは発生しません。

この記事では、Availability Zones を使用するように AKS リソースを構成する方法について説明します。

AKS リソース

この図は、AKS クラスターの作成時に作成される Azure リソースを示しています。

AKS コントロール プレーン

Microsoft は、AKS コントロール プレーン、Kubernetes API サーバー、および scheduler や etcd などのサービスを管理サービスとしてホストしています。 Microsoft は、コントロール プレーンを複数のゾーンにレプリケートします。

クラスターの他のリソースは、Azure サブスクリプション内の管理対象リソース グループに展開されます。 既定では、このリソース グループには管理対象クラスターを表す MC_ というプレフィックスが付いており、次のリソースが含まれています。

ノード プール

ノード プールは、Azure サブスクリプションの仮想マシン スケール セットとして作成されます。

AKS クラスターを作成する場合、システム ノード プールが 1 つ必要となり、自動的に作成されます。 これは、CoreDNS や metrics-server などの重要なシステム ポッドをホストします。 アプリケーションをホストするために、AKS クラスターにさらに多くのユーザー ノード プールを追加できます。

ノード プールを展開する方法は 3 つあります。

• ゾーン スパニング
• ゾーン アライン
• 地域

システム ノード プールの場合、使用されるゾーンの数はクラスターの作成時に構成されます。

ゾーン スパニング

ゾーン スパニング スケール セットでは、--zones パラメーターを使用してゾーンを指定することにより、選択したすべてのゾーン間でノードが分散されます。

# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1, 2, 3 

AKS はゾーン間のノード数を自動的に調整します。

ゾーン障害が発生した場合、影響を受けるゾーン内のノードは影響を受ける可能性がありますが、他の可用性ゾーン内のノードは影響を受けません。

ゾーン アライン

各ノードは、特定のゾーンに配置 (固定) されます。 3 つの Availability Zones を持つリージョンに 3 つのノード プールを作成するには:

# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

この構成は、ノード間の遅延を低くする必要がある場合に使用できます。 また、スケーリング操作に対して、またはクラスター オートスケーラーの使用時に、よりきめ細かい制御も提供します。

Note

• 単一のワークロードがノード プール全体に展開されている場合は、スケールアップ操作中にワークロードのゾーン間でノードのバランスの取れた分散を維持するために、--balance-similar-node-groups を true に設定することをお勧めします。

リージョン (Availability Zones を使用しない)

リージョン モードは、展開テンプレート ("zones"=[] or "zones"=null) でゾーン割り当てが設定されていない場合に使用されます。

この構成のノード プールでは、リージョン単位の (ゾーン固定ではない) インスタンスが作成されて、リージョン全体にインスタンスが暗黙的に配置されます。 ゾーン間のバランスや分散に関する保証、またはインスタンスが同じ可用性ゾーンに配置される保証はありません。

まれに、ゾーン全体が停止した場合、ノード プール内の一部または全部のインスタンスが影響を受ける可能性があります。

ノードの場所を検証するには、次のコマンドを実行します。

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

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

デプロイメント

ポッド

Kubernetes は Azure Availability Zones を認識し、異なるゾーン内のノード間でポッドのバランスを取ることができます。 ゾーンが使用できなくなった場合、Kubernetes は影響を受けるノードからポッドを自動的に移動します。

「有名なラベル、注釈、およびテイント」に記載されているように、Kubernetes は topology.kubernetes.io/zone ラベルを使用して、使用可能なさまざまなゾーンにわたってレプリケーション コントローラーまたはサービス内のポッドを自動的に分散します。

どのポッドでノードが実行されているかを確認するには、次のコマンドを実行します。

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

"maxSkew" パラメーターは、ポッドが不均等に分散される可能性の程度を表します。 3 つのゾーンと 3 つのレプリカがあるとを想定して、この値を 1 に設定すると、各ゾーンで少なくとも 1 つのポッドが実行されます。

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

ストレージとボリューム

既定では、Kubernetes バージョン 1.29 以降では、永続ボリューム要求にゾーン冗長ストレージ (ZRS) を使用する Azure Managed Disks が使用されます。

これらのディスクはゾーン間でレプリケートされ、アプリケーションの回復性を強化し、データセンターの障害からデータを保護します。

ZRS で Standard SSD を使用する永続ボリューム要求の例:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

ゾーン アライン展開の場合、skuname パラメーターを LRS (ローカル冗長ストレージ) に設定して新しいストレージ クラスを作成できます。 その後、永続ボリューム要求 (PVC) で新しいストレージ クラスを使用できます。

LRS ディスクはより低コストですが、ゾーン冗長がなく、ディスクを別のゾーンのノードに接続することはサポートされていません。

LRS Standard SSD ストレージ クラスの例:

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

ロード バランサー

Kubernetes は既定で Azure Standard Load Balancer を展開します。これにより、リージョン内のすべてのゾーン間でインバウンド トラフィックが分散されます。 ノードが使用できなくなると、ロード バランサーはトラフィックを正常なノードに再ルーティングします。

Azure Load Balancer を使用するサービスの例:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

重要

Basic Load Balancer は 2025 年 9 月 30 日に廃止されます。 詳細については、公式告知を参照してください。 現在 Basic Load Balancer をお使いの場合は、廃止日までに必ず Standard Load Balancer にアップグレードしてください。

制限事項

Availability Zones を使用する場合、次の制限事項が適用されます。

• 「AKS でのクォータ、仮想マシンのサイズ制限、利用可能なリージョン」を参照してください。
• ノード プールの作成後は、使用される Availability Zones の数を変更することはできません。
• Availability Zones は、ほとんどのリージョンでサポートされています。 一覧はこちらにあります。

次のステップ

• システム ノード プールについて学習する
• ユーザー ノード プールについて学習する
• ロード バランサーについて学習する
• AKS での事業継続とディザスター リカバリーに関するベスト プラクティス