Vytvoření clusteru Azure Kubernetes Service (AKS), který používá zóny dostupnosti

  • Článek
  • 7 min ke čtení

Cluster Azure Kubernetes Service (AKS) distribuuje prostředky, jako jsou uzly a úložiště, mezi logické 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 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.

Díky definování fondů uzlů v clusteru pro více zón budou uzly v daném fondu uzlů moci pokračovat v provozu i v případě, že dojde k selhání jedné zóny. Vaše aplikace mohou být i nadále dostupné i v případě, že dojde k fyzickému selhání v jednom datacentru, pokud je orchestrováno tak, aby tolerovala selhání podmnožiny uzlů.

Tento článek ukazuje, jak vytvořit cluster AKS a distribuovat komponenty uzlu napříč zónami dostupnosti.

Než začnete

Potřebujete mít 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 v současné době možné 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
  • Norska – východ
  • Southeast Asia
  • Středojižní USA
  • Kaský republika – střed
  • 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 zón bez dostupnosti tak, aby se zóny dostupnosti používají.
  • 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í k distribuci mezi zónami nástroje Azure Standard Load Balancer. Tento typ nástroje pro vyrovnávání zatížení je možné definovat pouze při vytváření clusteru. Další informace a omezení standardního nástroje pro vyrovnávání zatížení najdete v tématu Omezení standardní SKU nástroje pro vyrovnávání zatížení Azure.

Omezení disků Azure

Svazky, které používají spravované disky Azure, v současné době nejsou zónově redundantní prostředky. 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.

Kubernetes ví o zónách dostupnosti Azure od verze 1.12. Můžete nasadit 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 nárokuje ve správné zóně dostupnosti.

Azure Resource Manager šablon a zón dostupnosti

Pokud při vytváření clusteru AKS explicitně definujete hodnotu null v šabloně se syntaxí, jako je , šablona Resource Manager považuje vlastnost za neexistující, což znamená, že váš cluster nebude mít povolené zóny "availabilityZones": null dostupnosti. Pokud vytvoříte cluster s novou šablonou Resource Manager, která vymešle vlastnost zón dostupnosti, zóny dostupnosti budou zakázané.

Nemůžete aktualizovat nastavení pro zóny dostupnosti v existujícím clusteru, takže se chování liší při aktualizaci clusteru AKS pomocí Resource Manager šablon. Pokud v šabloně explicitně nastavíte hodnotu null pro zóny dostupnosti a aktualizujete cluster, v clusteru se pro zóny dostupnosti nic nemění. Pokud ale vynecháte vlastnost zón dostupnosti se syntaxí, jako je , nasazení se pokusí zakázat zóny dostupnosti ve stávajícím clusteru AKS a "availabilityZones": [] 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 je 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 mohou distribuovat uzly mezi více zón 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 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 budou dál běžet, pokud je cluster rozprostřen mezi více zón.

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

Při vytváření clusteru pomocí příkazu az aks create parametr definuje, do kterých uzlů agentů zón se --zones nasadí. Komponenty řídicí roviny, jako je etcd nebo rozhraní API, jsou rozprostřené mezi dostupné zóny v oblasti, pokud parametr --zones definujete při vytváření clusteru. Konkrétní zóny, na kterých jsou součásti řídicí roviny rozloženy, 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 nedefinujte žádné zóny pro výchozí fond agentů, není zaručeno, že se komponenty řídicí roviny rozprostře mezi zóny dostupnosti. Další fondy uzlů můžete přidat pomocí příkazu az aks nodepool add a zadat je pro nové uzly, ale nezmění se tím rozložení řídicí roviny napříč --zones zónami. Nastavení zóny dostupnosti je možné definovat pouze při vytváření clusteru nebo fondu uzlů.

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

Ověření distribuce uzlů mezi zónami

Až bude cluster připravený, zobrazte seznam uzlů agentů ve škálovací sadě, abyste viděli, ve které 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 vypište uzly v clusteru a vyfiltrujte hodnotu failure-domain.beta.kubernetes.io/zone clusteru. Následující příklad je pro prostředí Bash.

kubectl describe nodes | grep -e "Name:" -e "failure-domain.beta.kubernetes.io/zone"

Následující příklad výstupu ukazuje tři uzly distribuované v zadané oblasti a zónách dostupnosti, například eastus2-1 pro první zónu dostupnosti a eastus2-2 pro druhou zónu dostupnosti:

Name:       aks-nodepool1-28993262-vmss000000
            failure-domain.beta.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            failure-domain.beta.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            failure-domain.beta.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 mezi zadané zóny dostupnosti.

Všimněte si, že v novějších verzích Kubernetes (1.17.0 a novější) používá AKS kromě zastaralého popisku i topology.kubernetes.io/zone novější failure-domain.beta.kubernetes.io/zone popisek. Stejný výsledek jako výše získáte 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 se zobrazí struč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 zdokumentované ve známých popiscích, anotacích a taintech,Používá Kubernetes tento popisek k automatické distribuci podů v kontroleru replikace nebo službě mezi různé failure-domain.beta.kubernetes.io/zone dostupné zóny. Abyste to mohli otestovat, můžete cluster škálovat ze 3 na 5 uzlů a ověřit správné rozlož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 v prostředí Bash poskytnout výstup kubectl describe nodes | grep -e "Name:" -e "failure-domain.beta.kubernetes.io/zone" podobný tomuto příkladu:

Name:       aks-nodepool1-28993262-vmss000000
            failure-domain.beta.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            failure-domain.beta.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            failure-domain.beta.kubernetes.io/zone=eastus2-3
Name:       aks-nodepool1-28993262-vmss000003
            failure-domain.beta.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            failure-domain.beta.kubernetes.io/zone=eastus2-2

Teď máme v zónách 1 a 2 další dva uzly. Můžete nasadit aplikaci skládající se ze tří replik. 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ů, ve kterých jsou pody spuštěné, uvidíte, že pody běží na uzlech odpovídajících třem různým zónám dostupnosti. Například příkazem v prostředí Bash získáte kubectl describe pod | grep -e "^Name:" -e "^Node:" 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ě dostupnosti eastus2-1 . Druhý pod je spuštěn v uzlu 2, který odpovídá eastus2-3 a třetí z nich v uzlu 4 v eastus2-2 . Bez jakékoli další konfigurace Kubernetes rozšíří lusky správně ve všech třech zónách dostupnosti.

Další kroky

V tomto článku se dozvíte, jak vytvořit cluster AKS, který používá zóny dostupnosti. Další informace o clusterech s vysokou dostupností najdete v tématu osvědčené postupy pro kontinuitu podnikových procesů a zotavení po havárii v AKS.