可用性ゾーンは、データセンターの障害からアプリケーションとデータを保護するのに役立ちます。 ゾーンは、Azure リージョン内の一意の物理的な場所です。 各ゾーンには、独立した電源、冷却、ネットワーキングを備えた 1 つ以上のデータセンターが含まれます。
可用性ゾーンで Azure Kubernetes Service (AKS) を使用すると、1 つのリージョン内の異なる可用性ゾーンにリソースが物理的に分散され、信頼性が向上します。 複数のゾーンにノードを展開しても追加コストは発生しません。
この記事では、可用性ゾーンを使用するように 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 node pool 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 node pool, 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 は、ゾーン間のノード数のバランスを自動的に調整します。
ゾーン障害が発生した場合、影響を受けるゾーン内のノードが影響を受ける可能性がありますが、他の可用性ゾーン内のノードは影響を受けません。
ノードの場所を検証するには、次のコマンドを実行します。
kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.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
ゾーン アライン
この構成では、各ノードが特定のゾーンに配置 (固定) されます。 3 つの可用性ゾーンを持つリージョンに対して 3 つのノード プールを作成するには:
# # Add three new zone-aligned user node pools, 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
この構成は、ノード間の遅延を低くする必要がある場合に使用できます。 また、スケーリング操作やクラスター オートスケーラーを使用している場合に、より細かく制御できます。
注
単一のワークロードをノードプールにデプロイする際には、スケールアップ操作中にワークロードのゾーン間でノードが均等に分散されるようにするために、--balance-similar-node-groups
を true
に設定することをお勧めします。
リージョン (Availability Zones を使用しない)
リージョン モードは、デプロイ テンプレートでゾーンの割り当てが設定されていない場合に使用されます (たとえば、 "zones"=[]
や "zones"=null
)。
この構成では、ノード プールはリージョン (ゾーン固定ではない) インスタンスを作成し、リージョン全体にインスタンスを暗黙的に配置します。 インスタンスが均等に配置されたり、ゾーン間で分散されたり、または同じ可用性ゾーンに配置される保証はありません。
まれに、ゾーン全体の停止が発生した場合、ノード プール内の任意のインスタンスまたはすべてのインスタンスが影響を受ける可能性があります。
ノードの場所を検証するには、次のコマンドを実行します。
kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.topology\.kubernetes\.io/zone'
NAME REGION ZONE
aks-nodepool1-34917322-vmss000000 eastus 0
aks-nodepool1-34917322-vmss000001 eastus 0
aks-nodepool1-34917322-vmss000002 eastus 0
デプロイメント
ポッド
Kubernetes は Azure 可用性ゾーンを認識しており、異なるゾーン内のノード間でポッドのバランスを取ることができます。 ゾーンが使用できなくなった場合、Kubernetes は影響を受けるノードからポッドを自動的に移動します。
Kubernetes リファレンス Well-Known ラベル、注釈、およびテイントに関するページに記載されているように、Kubernetes では、 topology.kubernetes.io/zone
ラベルを使用して、使用可能なさまざまなゾーンにわたってレプリケーション コントローラーまたはサービス内のポッドを自動的に分散します。
実行されているポッドとノードを確認するには、次のコマンドを実行します。
kubectl describe pod | grep -e "^Name:" -e "^Node:"
maxSkew
パラメーターは、ポッドが不均等に分散される可能性がある度合いを表します。 3 つのゾーンと 3 つのレプリカを想定して、この値を 1
に設定すると、各ゾーンで少なくとも 1 つのポッドが実行されます。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: my-app
containers:
- name: my-container
image: my-image
ストレージとボリューム
既定では、Kubernetes バージョン 1.29 以降では、永続ボリューム要求にゾーン冗長ストレージを使用して Azure Managed Disks を使用します。
これらのディスクは、アプリケーションの回復性を高めるために、ゾーン間でレプリケートされます。 このアクションは、データセンターの障害からデータを保護するのに役立ちます。
次の例は、ゾーン冗長ストレージで Azure 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
(ローカル冗長ストレージ) に設定して新しいストレージ クラスを作成できます。 その後、永続ボリューム要求で新しいストレージ クラスを使用できます。
ローカル冗長ストレージ ディスクのコストは低くなりますが、ゾーン冗長ではなく、ディスクを別のゾーンのノードに接続することはサポートされていません。
次の例は、ローカル冗長ストレージ 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 に アップグレード してください。
制限事項
可用性ゾーンを使用する場合は、次の制限が適用されます。
- AKS でのクォータ、仮想マシン サイズの制限、リージョンの可用性について参照してください。
- 使用される可用性ゾーンの数は、ノード プールの作成後に 変更することはできません 。
- ほとんどのリージョンでは、可用性ゾーンがサポートされています。 リージョンの一覧を参照してください。
関連コンテンツ
- システム ノード プールについて説明します。
- ユーザー ノード プールについて説明します。
- ロード バランサーについて説明します。
- AKS でのビジネス継続性とディザスター リカバリーのベスト プラクティスを取得します。
Azure Kubernetes Service