Azure Kubernetes Service (AKS) で可用性ゾーンを構成する

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

可用性ゾーンで Azure Kubernetes Service (AKS) を使用すると、1 つのリージョン内の異なる可用性ゾーンにリソースが物理的に分散され、信頼性が向上します。 複数のゾーンにノードを展開しても追加コストは発生しません。 可用性ゾーン、複数リージョン構成、サービス メンテナンス中の信頼性、バックアップなどの AKS の信頼性機能の詳細については、 AKS の信頼性に関するページを参照してください。

この記事では、可用性ゾーンを使用するように 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

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

リージョン (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

制限事項

可用性ゾーンを使用する場合は、次の制限が適用されます。

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

関連コンテンツ

• AKS の信頼性について説明します。
• システム ノード プールについて説明します。
• ユーザー ノード プールについて説明します。
• ロード バランサーについて説明します。
• AKS でのビジネス継続性とディザスター リカバリーのベスト プラクティスを取得します。