可用性ゾーンを使用する Azure Kubernetes Service (AKS) クラスターを作成する

[アーティクル]
12/06/2023

Azure Kubernetes Service (AKS) クラスターは、ノードやストレージなどのリソースを、基になる Azure インフラストラクチャの複数の論理セクションに分散させます。可用性ゾーンを使用すると、異なる可用性ゾーンにデプロイされたノード間は物理的に分離されます。クラスター全体に構成された複数の可用性ゾーンでデプロイされる AKS クラスターは、ハードウェア障害または計画メンテナンスイベントから保護するための高レベルの可用性を提供します。

クラスター内のノードプールを複数のゾーンにまたがるように定義することで、1 つのゾーンがダウンした場合でも、特定のノードプール内のノードは動作を継続できます。 1 つのデータセンターで物理的な障害が発生した場合でも、ノードのサブセットの障害に耐えられるよう調整できていれば、アプリケーションを引き続き利用できます。

この記事では、AKS クラスターを作成し、複数の可用性ゾーンにノードコンポーネントを分散させる方法について説明します。

開始する前に

Azure CLI バージョン 2.0.76 以降がインストールされて構成されている必要があります。バージョンを確認するには、az --version を実行します。インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。

制限事項とリージョンの可用性

AKS クラスターは、可用性ゾーンを含む任意の Azure リージョンの可用性ゾーンを使用できます。

可用性ゾーンを使用して AKS クラスターを作成する場合、次の制限事項が適用されます。

可用性ゾーンは、クラスターまたはノードプールの作成時にのみ定義できます。
クラスターの作成後に、可用性ゾーンを使用するように既存の非可用性ゾーンクラスターを更新することはできません。
選択したノードサイズ (VM SKU) を、選択したすべての可用性ゾーンで使用できる必要があります。
可用性ゾーンが有効になっているクラスターでは、複数のゾーンへの分散のために Azure Standard Load Balancer を使用する必要があります。このロードバランサーの種類は、クラスターの作成時にのみ定義できます。 Standard Load Balancer の詳細と制限事項については、Azure Load Balancer Standard SKU の制限事項に関する記事をご覧ください。

Azure ディスク可用性ゾーンのサポート

Azure マネージド LRS ディスクを使用するボリュームは、ゾーン冗長リソースではありません。ゾーンをまたぐアタッチはサポートされません。ターゲットポッドをホストしている指定ノードと同じゾーン内のボリュームを併置する必要があります。
Azure マネージド ZRS ディスクを使用するボリュームはゾーン冗長リソースです。これらのボリュームは、すべてのゾーンおよびゾーン以外のエージェントノードでスケジュールできます。StandardSSD_ZRS ディスクを使用してストレージクラスを作成する方法の例を次に示します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-csi-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: StandardSSD_ZRS  # or Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Kubernetes では、バージョン 1.12 以降で、Azure 可用性ゾーンが認識されています。ユーザーは、複数ゾーンの AKS クラスターで Azure マネージドディスクを参照して PersistentVolumeClaim オブジェクトをデプロイすることができます。また、適切な可用性ゾーン内にこの PVC を要求するあらゆるポッドのスケジュール設定が Kubernetes によって管理されます。

Azure Resource Manager テンプレートと可用性ゾーン

AKS クラスターを "作成する" 場合は、テンプレートでの可用性ゾーンの指定に関する次の詳細を理解してください。

テンプレートで null 値を明示的に定義した場合 (たとえば、"availabilityZones": null を指定するなど)、Resource Manager テンプレートはプロパティを存在しないかのように扱います。つまり、クラスターは可用性ゾーンにデプロイされません。
Resource Manager テンプレートに "availabilityZones": プロパティを含めない場合、クラスターは可用性ゾーンにデプロイされません。
既存のクラスターで可用性ゾーンの設定を更新することはできないため、Resource Manager テンプレートを使用して AKS クラスターを更新するときの動作は異なったものになります。テンプレートで可用性ゾーンに対して null 値を明示的に設定し、クラスターを "更新" した場合、クラスターに対して可用性ゾーンの更新は行われません。ただし、"availabilityZones": [] のような構文で可用性ゾーンプロパティを省略した場合、デプロイでは既存の AKS クラスターで可用性ゾーンを無効にしようとして、"availabilityZones": []します。

AKS クラスターの可用性ゾーンの概要

可用性ゾーンとは高可用性を提供するサービスで、アプリケーションとデータをデータセンターの障害から保護します。ゾーンは、Azure リージョン内の一意の物理的な場所です。各ゾーンには、独立した電源、冷却、ネットワーキングを備えた 1 つ以上のデータセンターが含まれます。回復性を確保するため、ゾーンが有効になっているすべてのリージョンに常に複数のゾーンがあります。可用性ゾーンはリージョン内で物理的に分離されているため、データセンターで障害が発生してもアプリケーションとデータは保護されます。

詳しくは、「Azure の可用性ゾーンの概要」をご覧ください。

可用性ゾーンを使用してデプロイされる AKS クラスターでは、1 つのリージョン内の複数のゾーンにノードを分散させることができます。たとえば、米国東部 2 リージョンのクラスターでは、米国東部 2 の 3 つすべての可用性ゾーンでノードを作成できます。この AKS クラスターリソースの分散により、特定のゾーンの障害に対する回復力があるため、クラスターの可用性が向上します。

AKS node distribution across availability zones

1 つのゾーンが使用できなくなった場合でも、アプリケーションは、複数のゾーンをまたいで分散するように構成されたクラスター上で引き続き実行されます。

Note

クラスターオートスケーラーを使用して可用性ゾーンを実装する場合は、ゾーンごとに 1 つのノードプールを使用することをお勧めします。スケールアップ操作中にTrue、ワークロードのゾーン間でノードの分散を分散メインするようにパラメーターを設定--balance-similar-node-groupsできます。この方法が実装されていない場合、スケールダウン操作によって、ゾーン間のノードのバランスが中断される可能性があります。

複数の可用性ゾーンでの AKS クラスターの作成

az aks create コマンドを使用してクラスターを作成する場合は、--zones パラメーターで、エージェントノードのデプロイ先となる可用性ゾーンを指定します。マネージドコントロールプレーンコンポーネントがデプロイされる可用性ゾーンは、このパラメーターによって制御されません 。これらは、クラスターのデプロイ中にリージョン内のすべての可用性ゾーン (存在する場合) に自動的に分散されます。

次の例では、合計 3 つのノードが含まれる myResourceGroup という名前のリソースグループに、myAKSCluster という名前の AKS クラスターを作成します。ゾーン 1、2、3 にそれぞれ 1 つずつのエージェントノードがあります。

az group create --name myResourceGroup --location eastus2

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

AKS クラスターの作成には数分かかります。

新しいノードが属するゾーンを決定するときに、指定された AKS ノードプールは、基になる Azure Virtual Machine Scale Sets によって提供されるベストエフォートのゾーン分散を使用します。スケールセットの各ゾーンの VM 数の差が 1 つ以内の場合、AKS ノードプールは "バランスが取れている" と見なされます。

複数のゾーンへのノードの分散を確認する

クラスターの準備ができたら、スケールセット内のエージェントノードが配置されている可用性ゾーンをリストします。

最初に、az aks get-credentials コマンドを使用して、AKS クラスターの資格情報を取得します。

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

次に、kubectl describe コマンドを使用して、クラスター内のノードを一覧表示し、topology.kubernetes.io/zone 値でフィルター処理します。 Bash シェルの例を次に示します。

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

次の出力例では、指定のリージョンの複数の可用性ゾーンに分散した 3 つのノードが示されています (1 番目の可用性ゾーンは eastus2-1、2 番目の可用性ゾーンは eastus2-2 など)。

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 Platform は、基になる VM を指定の複数の可用性ゾーンに自動的に分散させます。

Kubernetes バージョン 1.17.0 以降では、AKS は新しいラベル topology.kubernetes.io/zone と非推奨の failure-domain.beta.kubernetes.io/zone を使用します。次のスクリプトを実行すると、前のステップの kubelet describe nodes コマンドを実行した場合と同じ結果が得られます。

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

複数のゾーンへのポッドの分散を確認する

「有名なラベル、注釈、およびテイント」に記載されているように、Kubernetes は topology.kubernetes.io/zone ラベルを使用して、使用可能なさまざまなゾーンにわたってレプリケーションコントローラーまたはサービス内のポッドを自動的に分散します。ラベルをテストしてクラスターを 3 ノードから 5 ノードにスケーリングするには、次のコマンドを実行して、ポッドが正しく分散されていることを確認します。

az aks scale \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 5

数分後にスケール操作が完了したら、Bash シェルでコマンド 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
Name:       aks-nodepool1-28993262-vmss000003
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            topology.kubernetes.io/zone=eastus2-2

これで、ゾーン 1 とゾーン 2 に 2 つのノードが追加されました。 3 つのレプリカで構成されるアプリケーションをデプロイできます。次の例では、NGINX を使用します。

kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3

ポッドが実行されているノードを表示すると、3 つの異なる可用性ゾーンに対応するノードでポッドが実行されていることがわかります。たとえば、Bash シェルでコマンド kubectl describe pod | grep -e "^Name:" -e "^Node:" を実行すると、次の例のような出力が表示されます。

Name:         nginx-6db489d4b7-ktdwg
Node:         aks-nodepool1-28993262-vmss000000/10.240.0.4
Name:         nginx-6db489d4b7-v7zvj
Node:         aks-nodepool1-28993262-vmss000002/10.240.0.6
Name:         nginx-6db489d4b7-xz6wj
Node:         aks-nodepool1-28993262-vmss000004/10.240.0.8

前の出力からわかるように、最初のポッドは、可用性ゾーン eastus2-1 にあるノード 0 で実行されています。 2 つ目のポッドは、eastus2-3 に対応するノード 2 で実行されています。また、3 つ目のポッドは、eastus2-2 のノード 4 で実行されています。追加の構成を行わなくても、Kubernetes は 3 つすべての可用性ゾーンにポッドを正しく分散させます。

次のステップ

この記事では、可用性ゾーンを使用する AKS クラスターの作成方法について説明しました。高可用性クラスターの考慮事項について詳しくは、「AKS での事業継続とディザスターリカバリーに関するベストプラクティス」をご覧ください。