Vytvoření clusteru Azure Kubernetes Service (AKS), který používá zóny dostupnosti
Cluster Azure Kubernetes Service (AKS) distribuuje prostředky, jako jsou uzly a úložiště, napříč logickými oddíly základní infrastruktury Azure. Použití zón dostupnosti fyzicky odděluje uzly od jiných uzlů nasazených do různých zón dostupnosti. Clustery AKS nasazené s několika zónami dostupnosti nakonfigurovanými v rámci clusteru poskytují vyšší úroveň dostupnosti pro ochranu před selháním hardwaru nebo událostí plánované údržby.
Definováním fondů uzlů v clusteru pro rozsah více zón můžou uzly v daném fondu uzlů pokračovat v provozu i v případě, že jedna zóna přestala fungovat. Vaše aplikace můžou být i nadále dostupné, i když dojde k fyzickému selhání v jednom datacentru, pokud je orchestrace orchestrovaná tak, aby tolerovala selhání podmnožina uzlů.
V tomto článku se dozvíte, jak vytvořit cluster AKS a distribuovat komponenty uzlu napříč zónami dostupnosti.
Než začnete
Potřebujete nainstalovanou a nakonfigurovanou verzi Azure CLI 2.0.76 nebo novější. Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.
Omezení a dostupnost oblastí
Clustery AKS můžou používat zóny dostupnosti v libovolné oblasti Azure, která má zóny dostupnosti.
Při vytváření clusteru AKS pomocí zón dostupnosti platí následující omezení:
- Během vytváření clusteru nebo fondu uzlů můžete definovat pouze zóny dostupnosti.
- Po vytvoření clusteru není možné aktualizovat existující cluster zóny dostupnosti tak, aby používal zóny dostupnosti.
- Vybraná velikost uzlu (skladová položka virtuálního počítače) musí být dostupná ve všech vybraných zónách dostupnosti.
- Clustery s povolenými zónami dostupnosti vyžadují pro distribuci napříč zónami službu Azure Standard Load Balancers. Tento typ nástroje pro vyrovnávání zatížení můžete definovat pouze v době vytvoření clusteru. Další informace a omezení standardního nástroje pro vyrovnávání zatížení najdete v tématu Omezení skladové položky Azure Load Balancer úrovně Standard.
Podpora zón dostupnosti disků Azure
- Svazky, které používají disky Spravované LRS Azure, nejsou zónově redundantní prostředky, připojení napříč zónami se nepodporuje. Musíte společně vyhledat svazky ve stejné zóně jako zadaný uzel, který je hostitelem cílového podu.
- Svazky, které používají disky Azure managed ZRS, jsou zónově redundantní prostředky. Tyto svazky můžete naplánovat na všech uzlech agenta zóny a jiných než zón, tady je příklad vytvoření třídy úložiště pomocí disku 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 o zónách dostupnosti Azure ví od verze 1.12. Objekt PersistentVolumeClaim odkazující na spravovaný disk Azure můžete nasadit v clusteru AKS s více zónami a Kubernetes se postará o naplánování jakéhokoli podu, který tento PVC deklaruje ve správné zóně dostupnosti.
Šablony Azure Resource Manageru a zóny dostupnosti
Při vytváření clusteru AKS se seznamte s následujícími podrobnostmi o určení zón dostupnosti v šabloně:
- Pokud explicitně definujete hodnotu null v šabloně, například zadáním
"availabilityZones": null, šablona Resource Manageru považuje vlastnost za vlastnost, jako by neexistovala. To znamená, že váš cluster se nenasazuje v zóně dostupnosti. - Pokud do šablony Resource Manageru
"availabilityZones":nezadáte vlastnost, cluster se nenasadí do zóny dostupnosti. - Nastavení zón dostupnosti v existujícím clusteru nemůžete aktualizovat, chování se liší při aktualizaci clusteru AKS pomocí šablon Resource Manageru. Pokud v šabloně explicitně nastavíte hodnotu null pro zóny dostupnosti a aktualizujete cluster, neaktualizuje cluster pro zóny dostupnosti. Pokud však vynecháte vlastnost zón dostupnosti se syntaxí, jako
"availabilityZones": []je například , pokusí se nasazení zakázat zóny dostupnosti ve vašem existujícím clusteru AKS a selže.
Přehled zón dostupnosti pro clustery AKS
Zóny dostupnosti jsou nabídka s vysokou dostupností, která chrání vaše aplikace a data před selháním datacentra. Zóny jsou jedinečná fyzická umístění v rámci oblasti Azure. Každá zóna zahrnuje jedno nebo více datacenter vybavených nezávislým napájením, chlazením a sítěmi. Kvůli zajištění odolnosti existuje vždy více než jedna zóna ve všech oblastech s povolenými zónami. Fyzické oddělení zón dostupnosti v rámci oblasti chrání aplikace a data před selháním datacenter.
Další informace najdete v tématu Co jsou zóny dostupnosti v Azure?
Clustery AKS nasazené pomocí zón dostupnosti můžou distribuovat uzly napříč několika zónami v rámci jedné oblasti. Například cluster v oblasti USA – východ 2 může vytvářet uzly ve všech třech zónách dostupnosti v oblasti USA – východ 2. Tato distribuce prostředků clusteru AKS zlepšuje dostupnost clusteru, protože jsou odolné vůči selhání konkrétní zóny.
Pokud se jedna zóna stane nedostupnou, vaše aplikace budou dál běžet na clusterech nakonfigurovaných tak, aby se rozprostřely mezi více zón.
Poznámka:
Při implementaci zón dostupnosti s automatickým škálováním clusteru doporučujeme pro každou zónu použít jeden fond uzlů. Parametr můžete nastavit --balance-similar-node-groups tak, aby True se zachovala vyvážená distribuce uzlů napříč zónami pro vaše úlohy během operací vertikálního navýšení kapacity. Pokud tento přístup není implementovaný, operace vertikálního snížení kapacity můžou narušit rovnováhu uzlů napříč zónami.
Vytvoření clusteru AKS napříč zónami dostupnosti
Když vytvoříte cluster pomocí příkazu az aks create , --zones parametr určuje zóny dostupnosti pro nasazení uzlů agenta do. Zóny dostupnosti, do které jsou nasazené komponenty spravované roviny řízení, nejsou tímto parametrem řízeny. Během nasazování clusteru se automaticky šíří mezi všechny zóny dostupnosti (pokud jsou k dispozici).
Následující příklad vytvoří cluster AKS s názvem myAKSCluster ve skupině prostředků myResourceGroup s celkem třemi uzly. Jeden uzel agenta v zóně 1, jeden v 2 a potom jeden v 3.
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
Vytvoření clusteru AKS bude trvat několik minut.
Při rozhodování o tom, do jaké zóny má nový uzel patřit, využívá zadaný fond uzlů AKS vyrovnávání zóny s nejlepším úsilím, které nabízí základní škálovací sady virtuálních počítačů Azure. Fond uzlů AKS je "vyvážený", pokud má každá zóna stejný počet virtuálních počítačů nebo +- jeden virtuální počítač ve všech ostatních zónách pro škálovací sadu.
Ověření distribuce uzlů napříč zónami
Jakmile je cluster připravený, vypište, ve které zóně dostupnosti jsou uzly agenta ve škálovací sadě.
Nejprve pomocí příkazu az aks get-credentials získejte přihlašovací údaje clusteru AKS:
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
Dále pomocí příkazu kubectl describe vypíšete uzly v clusteru a vyfiltrujte hodnotu topology.kubernetes.io/zone . Následující příklad je pro prostředí Bash.
kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"
Následující příklad výstupu ukazuje tři uzly distribuované napříč zadanou oblastí a zónami dostupnosti, například eastus2-1 pro první zónu dostupnosti a eastus2-2 pro druhou zónu dostupnosti:
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
Když do fondu agentů přidáte další uzly, platforma Azure automaticky distribuuje základní virtuální počítače napříč zadanými zónami dostupnosti.
S Kubernetes verze 1.17.0 a novější používá AKS novější popisek topology.kubernetes.io/zone a zastaralé failure-domain.beta.kubernetes.io/zone. Stejný výsledek můžete získat spuštěním kubelet describe nodes příkazu v předchozím kroku spuštěním následujícího skriptu:
kubectl get nodes -o custom-columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology\.kubernetes\.io/region}',ZONE:'{metadata.labels.topology\.kubernetes\.io/zone}'
Následující příklad se podobá výstupu s více podrobnými podrobnostmi:
NAME REGION ZONE
aks-nodepool1-34917322-vmss000000 eastus eastus-1
aks-nodepool1-34917322-vmss000001 eastus eastus-2
aks-nodepool1-34917322-vmss000002 eastus eastus-3
Ověření distribuce podů napříč zónami
Jak je uvedeno v dobře známých popiscích, poznámkách a taintech, Kubernetes tento popisek používá topology.kubernetes.io/zone k automatické distribuci podů v řadiči replikace nebo službě napříč různými dostupnými zónami. Pokud chcete otestovat popisek a škálovat cluster z 3 na 5 uzlů, spuštěním následujícího příkazu ověřte správné rozložení podu:
az aks scale \
--resource-group myResourceGroup \
--name myAKSCluster \
--node-count 5
Po dokončení operace škálování po několika minutách spusťte příkaz kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" v prostředí Bash. Následující výstup se podobá výsledkům:
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
Teď máte dva další uzly v zónách 1 a 2. Aplikaci, která se skládá ze tří replik, můžete nasadit. Následující příklad používá NGINX:
kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3
Zobrazením uzlů, ve kterých jsou pody spuštěné, vidíte, že pody běží na uzlech odpovídajících třem různým zónám dostupnosti. Například s příkazem kubectl describe pod | grep -e "^Name:" -e "^Node:" v prostředí Bash uvidíte následující příklad výstupu:
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
Jak vidíte z předchozího výstupu, první pod běží na uzlu 0 umístěném v zóně eastus2-1dostupnosti . Druhý pod běží na uzlu 2, který odpovídá eastus2-3, a třetí pod v uzlu 4, v eastus2-2. Bez jakékoli další konfigurace kubernetes rozdělí pody správně do všech tří zón dostupnosti.
Další kroky
Tento článek popisuje, jak vytvořit cluster AKS pomocí zón dostupnosti. Další důležité informace o vysoce dostupných clusterech najdete v tématu Osvědčené postupy pro provozní kontinuitu a zotavení po havárii v AKS.