可用性ゾーンを使用する Azure Kubernetes Service (AKS) クラスターを作成する
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 ディスク (Azure Disk CSI ドライバー v1.5.0 以降でサポート) を使用するボリュームは、ゾーン冗長リソースです。 これらのボリュームは、すべてのゾーンおよび非ゾーン エージェント ノード上でスケジュールできます。
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 クラスターリソースの分散により、特定のゾーンの障害に対する回復力があるため、クラスターの可用性が向上します。
1 つのゾーンが使用できなくなった場合でも、アプリケーションは、複数のゾーンをまたいで分散するように構成されたクラスター上で引き続き実行されます。
複数の可用性ゾーンでの AKS クラスターの作成
az aks create コマンドを使用してクラスターを作成する場合は、--zones
パラメーターで、エージェント ノードのデプロイ先となるゾーンを指定します。 etcd や API などのコントロール プレーン コンポーネントは、クラスターのデプロイ時にリージョン内の使用可能な複数のゾーンに分散されます。 コントロール プレーン コンポーネントが分散される特定のゾーンは、初期ノード プールに対して選択した明示的なゾーンに依存しません。
AKS クラスターの作成時に既定のエージェント プールのゾーンを指定しない場合、コントロール プレーン コンポーネントは可用性ゾーンに存在しません。 az aks nodepool add コマンドを使用してノード プールを追加し、新しいノードに対して --zones
を指定できます。 コマンドは、AKS コントロール プレーンを可用性ゾーンをまたいで分散するように変換します。
次の例では、合計 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 は ラベルを使用して、使用可能なさまざまなゾーンにわたってレプリケーション コントローラーまたはサービス内のポッドを自動的に分散します。 ラベルをテストしてクラスターを 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 での事業継続とディザスター リカバリーに関するベスト プラクティス」をご覧ください。