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. Tento model nasazení při použití zón dostupnosti zajišťuje, že uzly v dané zóně dostupnosti jsou fyzicky oddělené od uzlů definovaných v jiné zóně dostupnosti. Clustery AKS nasazené s více 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 dál dostupné i v případě fyzického selhání v jednom datacentru, pokud jsou orchestrované tak, aby tolerovaly selhání podmnožinu uzlů.

V tomto článku se dozvíte, jak vytvořit cluster AKS a distribuovat komponenty uzlů napříč zónami dostupnosti.

Než začnete

Potřebujete nainstalované a nakonfigurované Rozhraní příkazového řádku Azure CLI verze 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 je možné v současné době vytvářet pomocí zón dostupnosti v následujících oblastech:

  • Austrálie – východ
  • Brazílie – jih
  • Střední Kanada
  • Indie – střed
  • USA – střed
  • Východní Asie
  • East US
  • USA – východ 2
  • Francie – střed
  • Německo – středozápad
  • Japonsko – východ
  • Jižní Korea – střed
  • Severní Evropa
  • Norsko – východ
  • Southeast Asia
  • Jižní Afrika – sever
  • Středojižní USA
  • Švédsko – střed
  • Švýcarsko – sever
  • Spojené království – jih
  • USA (Gov) – Virginia
  • West Europe
  • Západní USA 2
  • USA – západ 3

Při vytváření clusteru AKS pomocí zón dostupnosti platí následující omezení:

  • Zóny dostupnosti můžete definovat pouze při vytvoření clusteru nebo fondu uzlů.
  • Po vytvoření clusteru není možné aktualizovat nastavení zóny dostupnosti. Nemůžete také aktualizovat existující cluster bez 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í použití služby Azure Standard Load Balancers pro distribuci napříč zónami. Tento typ nástroje pro vyrovnávání zatížení lze definovat pouze v době vytvoření clusteru. Další informace a omezení nástroje pro vyrovnávání zatížení úrovně Standard najdete v tématu Omezení skladové položky standardu nástroje pro vyrovnávání zatížení Azure.

Podpora zóny dostupnosti disků Azure

  • Svazky, které používají disky Azure Managed LRS, nejsou zónově redundantní prostředky, tyto svazky nelze připojit napříč zónami a musí být umístěné ve stejné zóně jako daný uzel, který je hostitelem cílového podu.
  • Svazky, které používají disky Azure Managed ZRS (podporované ovladačem CSI disku Azure v1.5.0+), jsou zónově redundantní prostředky. Tyto svazky je možné naplánovat na všech uzlech zóny a agenta mimo zónu.

Kubernetes si je vědom zón dostupnosti Azure od verze 1.12. Objekt PersistentVolumeClaim odkazující na spravovaný disk Azure 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 a zóny dostupnosti Azure Resource Manager

Pokud při vytváření clusteru AKS explicitně definujete hodnotu null v šabloně s syntaxí, jako "availabilityZones": nullje například , Resource Manager šablona považuje vlastnost za vlastnost, jako by neexistovala, což znamená, že váš cluster nebude mít povolené zóny dostupnosti. Pokud také vytvoříte cluster s Resource Manager šablonou, která vynechá vlastnost zón dostupnosti, jsou zóny dostupnosti zakázané.

Nastavení zón dostupnosti v existujícím clusteru nemůžete aktualizovat, takže chování se liší při aktualizaci clusteru AKS pomocí šablon Resource Manager. Pokud v šabloně explicitně nastavíte hodnotu null pro zóny dostupnosti a aktualizujete cluster, neprovedou se v clusteru žádné změny pro zóny dostupnosti. Pokud ale vlastnost zón dostupnosti vynecháte se syntaxí, například "availabilityZones": [], pokusí se nasazení zakázat zóny dostupnosti ve stávají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ždou zónu tvoří jedno nebo několik datacenter vybavených nezávislým napájením, chlazením a sítí. K 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.

Distribuce uzlů AKS napříč zónami dostupnosti

Pokud se jedna zóna stane nedostupnou, vaše aplikace se budou dál spouštět, pokud je cluster rozložený do více zón.

Vytvoření clusteru AKS napříč zónami dostupnosti

Když vytvoříte cluster pomocí příkazu az aks create , parametr definuje, --zones do kterých uzlů agenta zón se nasadí. Komponenty řídicí roviny, jako jsou atd., nebo rozhraní API jsou rozloženy mezi dostupné zóny v oblasti, pokud parametr definujete --zones při vytváření clusteru. Konkrétní zóny, na kterých jsou komponenty řídicí roviny rozložené, jsou nezávislé na tom, jaké explicitní zóny jsou vybrány pro počáteční fond uzlů.

Pokud při vytváření clusteru AKS nedefinujete žádné zóny pro výchozí fond agentů, nejsou zaručeny, že se komponenty řídicí roviny rozprostírají mezi zóny dostupnosti. Další fondy uzlů můžete přidat pomocí příkazu az aks nodepool add a zadat --zones pro nové uzly, ale nezmění způsob rozložení řídicí roviny mezi zóny. Nastavení zóny dostupnosti je možné definovat pouze v době vytvoření fondu clusteru nebo uzlu.

Následující příklad vytvoří cluster AKS s názvem myAKSCluster ve skupině prostředků myResourceGroup. Vytvoří se celkem 3 uzly – jeden agent v zóně 1, jeden ve 2 a potom jeden ve 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, bude daný fond uzlů AKS používat vyrovnávání zón s nejlepším úsilím, které nabízí podkladová Virtual Machine Scale Sets Azure. Daný fond uzlů AKS se považuje za vyvážený, pokud každá zóna má stejný počet virtuálních počítačů nebo virtuálních počítačů +- 1 ve všech ostatních zónách pro škálovací sadu.

Ověření distribuce uzlů napříč zónami

Jakmile je cluster připravený, zobrazte seznam uzlů agenta ve škálovací sadě a zjistěte, v jaké zóně dostupnosti jsou nasazené.

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 zobrazte seznam uzlů 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

Při přidávání dalších uzlů do fondu agentů platforma Azure automaticky distribuuje základní virtuální počítače napříč zadanými zónami dostupnosti.

Všimněte si, že v novějších verzích Kubernetes (1.17.0 a novějších) používá AKS kromě zastaralého failure-domain.beta.kubernetes.io/zonepopisku novější popisektopology.kubernetes.io/zone. Stejný výsledek jako výše můžete získat 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}'

Tím získáte výstižnější výstup:

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 taints, Kubernetes používá topology.kubernetes.io/zone popisek k automatické distribuci podů v řadiči replikace nebo službě napříč různými dostupnými zónami. Abyste to mohli otestovat, můžete vertikálně navýšit kapacitu clusteru z 3 na 5 uzlů, abyste ověřili správné šíření podů:

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

Po dokončení operace škálování po několika minutách by měl příkaz kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" v prostředí Bash poskytnout výstup podobný této ukázce:

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áme dva další uzly v zónách 1 a 2. Aplikaci, která se skládá ze tří replik, můžete nasadit. Jako příklad použijeme 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ů, na 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 pomocí příkazu kubectl describe pod | grep -e "^Name:" -e "^Node:" v prostředí Bash byste získali výstup podobný tomuto:

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, který se nachází 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 správně rozprostírá pody napříč všemi třemi zónami dostupnosti.

Další kroky

Tento článek podrobně popisuje, jak vytvořit cluster AKS, který používá zóny dostupnosti. Další důležité informace o clusterech s vysokou dostupností najdete v tématu Osvědčené postupy pro provozní kontinuitu a zotavení po havárii v AKS.