Een AKS-cluster (Azure Kubernetes Service) maken dat gebruikmaakt van beschikbaarheidszones

Artikel
12/09/2023

Een AKS-cluster (Azure Kubernetes Service) distribueert resources zoals knooppunten en opslag in logische secties van de onderliggende Azure-infrastructuur. Als u beschikbaarheidszones gebruikt, worden knooppunten fysiek gescheiden van andere knooppunten die zijn geïmplementeerd in verschillende beschikbaarheidszones. AKS-clusters die zijn geïmplementeerd met meerdere beschikbaarheidszones die in een cluster zijn geconfigureerd, bieden een hoger beschikbaarheidsniveau om te beschermen tegen een hardwarefout of een geplande onderhoudsgebeurtenis.

Door knooppuntgroepen in een cluster te definiëren voor meerdere zones, kunnen knooppunten in een bepaalde knooppuntgroep blijven werken, zelfs als één zone is uitgevallen. Uw toepassingen kunnen nog steeds beschikbaar blijven, zelfs als er zich een fysieke fout in één datacenter voordoet als deze is ingedeeld om het mislukken van een subset van knooppunten te tolereren.

In dit artikel leest u hoe u een AKS-cluster maakt en de knooppuntonderdelen over beschikbaarheidszones distribueert.

Voordat u begint

U moet Azure CLI versie 2.0.76 of hoger hebben geïnstalleerd en geconfigureerd. Voer az --version uit om de versie te bekijken. Als u Azure CLI 2.0 wilt installeren of upgraden, raadpleegt u Azure CLI 2.0 installeren.

Beperkingen en beschikbaarheid van regio's

AKS-clusters kunnen beschikbaarheidszones gebruiken in elke Azure-regio met beschikbaarheidszones.

De volgende beperkingen gelden wanneer u een AKS-cluster maakt met behulp van beschikbaarheidszones:

U kunt alleen beschikbaarheidszones definiëren tijdens het maken van het cluster of de knooppuntgroep.
Het is niet mogelijk om een bestaand cluster zonder beschikbaarheidszone bij te werken om beschikbaarheidszones te gebruiken nadat het cluster is gemaakt.
De geselecteerde knooppuntgrootte (VM-SKU) moet beschikbaar zijn in alle geselecteerde beschikbaarheidszones.
Voor clusters waarvoor beschikbaarheidszones zijn ingeschakeld, is het gebruik van Azure Standard Load Balancers vereist voor distributie tussen zones. U kunt dit type load balancer alleen definiëren tijdens het maken van het cluster. Zie De standaard-SKU-beperkingen van Azure Load Balancer voor meer informatie en de beperkingen van de standaard load balancer.

Ondersteuning voor beschikbaarheidszone voor Azure-schijven

Volumes die gebruikmaken van door Azure beheerde LRS-schijven zijn geen zone-redundante resources. Het koppelen tussen zones wordt niet ondersteund. U moet volumes in dezelfde zone zoeken als het opgegeven knooppunt dat als host fungeert voor de doelpod.
Volumes die gebruikmaken van door Azure beheerde ZRS-schijven zijn zone-redundante resources. U kunt deze volumes plannen op alle zone- en niet-zoneagentknooppunten. Hier volgt een voorbeeld van het maken van een opslagklasse met behulp van de StandardSSD_ZRS schijf:

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 is op de hoogte van Azure-beschikbaarheidszones sinds versie 1.12. U kunt een PersistentVolumeClaim-object implementeren dat verwijst naar een Azure Managed Disk in een AKS-cluster met meerdere zones en Kubernetes zorgt voor het plannen van pods die dit PVC claimen in de juiste beschikbaarheidszone.

Azure Resource Manager-sjablonen en -beschikbaarheidszones

Wanneer u een AKS-cluster maakt , begrijpt u de volgende informatie over het opgeven van beschikbaarheidszones in een sjabloon:

Als u expliciet een null-waarde in een sjabloon definieert, bijvoorbeeld door op te "availabilityZones": nullgeven, behandelt de Resource Manager-sjabloon de eigenschap alsof deze niet bestaat. Dit betekent dat uw cluster niet wordt geïmplementeerd in een beschikbaarheidszone.
Als u de "availabilityZones": eigenschap niet opneemt in uw Resource Manager-sjabloon, wordt uw cluster niet geïmplementeerd in een beschikbaarheidszone.
U kunt instellingen voor beschikbaarheidszones op een bestaand cluster niet bijwerken. Het gedrag verschilt wanneer u een AKS-cluster bijwerkt met Resource Manager-sjablonen. Als u expliciet een null-waarde in uw sjabloon instelt voor beschikbaarheidszones en uw cluster bijwerkt, wordt uw cluster niet bijgewerkt voor beschikbaarheidszones. Als u echter de eigenschap beschikbaarheidszones weglaat met syntaxis, zoals "availabilityZones": [], probeert de implementatie beschikbaarheidszones op uw bestaande AKS-cluster uit te schakelen en mislukt.

Overzicht van beschikbaarheidszones voor AKS-clusters

Beschikbaarheidszones zijn een aanbieding voor hoge beschikbaarheid waarmee uw toepassingen en gegevens worden beschermd tegen storingen in datacenters. Zones zijn unieke fysieke locaties binnen een Azure-regio. Elke zone bevat een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken. Om tolerantie te garanderen, is er altijd meer dan één zone in alle zone-ingeschakelde regio's. De fysieke scheiding tussen beschikbaarheidszones binnen een Azure-regio beschermt toepassingen en gegevens tegen storingen van het datacenter.

Zie Wat zijn beschikbaarheidszones in Azure? voor meer informatie.

AKS-clusters die zijn geïmplementeerd met behulp van beschikbaarheidszones, kunnen knooppunten verdelen over meerdere zones binnen één regio. Een cluster in de regio VS - oost 2 kan bijvoorbeeld knooppunten maken in alle drie de beschikbaarheidszones in VS - oost 2. Deze distributie van AKS-clusterresources verbetert de beschikbaarheid van clusters omdat ze bestand zijn tegen fouten in een specifieke zone.

AKS node distribution across availability zones

Als één zone niet beschikbaar is, blijven uw toepassingen worden uitgevoerd op clusters die zijn geconfigureerd om over meerdere zones te worden verdeeld.

Notitie

Bij het implementeren van beschikbaarheidszones met de automatische schaalaanpassing van clusters raden we u aan één knooppuntgroep voor elke zone te gebruiken. U kunt de --balance-similar-node-groups parameter instellen om True een evenwichtige verdeling van knooppunten tussen zones voor uw workloads te behouden tijdens het opschalen van bewerkingen. Wanneer deze aanpak niet wordt geïmplementeerd, kunnen omlaag schalen de balans tussen knooppunten tussen zones verstoren.

Een AKS-cluster maken in verschillende beschikbaarheidszones

Wanneer u een cluster maakt met behulp van de opdracht az aks create , geeft de --zones parameter de beschikbaarheidszones op waarin agentknooppunten moeten worden geïmplementeerd. De beschikbaarheidszones waar de onderdelen van het beheerde besturingsvlak in worden geïmplementeerd, worden niet beheerd door deze parameter. Ze worden automatisch verspreid over alle beschikbaarheidszones (indien aanwezig) in de regio tijdens de clusterimplementatie.

In het volgende voorbeeld wordt een AKS-cluster met de naam myAKSCluster gemaakt in de resourcegroep met de naam myResourceGroup met in totaal drie knooppunten. Eén agentknooppunt in zone 1, één in 2 en vervolgens één in 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

Het duurt enkele minuten om het AKS-cluster te maken.

Bij het bepalen van de zone waartoe een nieuw knooppunt moet behoren, gebruikt een opgegeven AKS-knooppuntgroep een best effort zone balancing die wordt aangeboden door onderliggende Virtuele-machineschaalsets van Azure. De AKS-knooppuntgroep is 'evenwichtig' wanneer elke zone hetzelfde aantal VM's of +- één VM in alle andere zones voor de schaalset heeft.

Knooppuntdistributie tussen zones controleren

Wanneer het cluster gereed is, vermeldt u in welke beschikbaarheidszone de agentknooppunten in de schaalset zich bevinden.

Haal eerst de AKS-clusterreferenties op met behulp van de opdracht az aks get-credentials :

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

Gebruik vervolgens de opdracht kubectl describe om de knooppunten in het cluster weer te geven en te filteren op de topology.kubernetes.io/zone waarde. Het volgende voorbeeld is voor een Bash-shell.

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

In de volgende voorbeelduitvoer ziet u de drie knooppunten die zijn verdeeld over de opgegeven regio en beschikbaarheidszones, zoals eastus2-1 voor de eerste beschikbaarheidszone en eastus2-2 voor de tweede beschikbaarheidszone:

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

Wanneer u meer knooppunten toevoegt aan een agentgroep, distribueert het Azure-platform automatisch de onderliggende VM's over de opgegeven beschikbaarheidszones.

Met Kubernetes-versies 1.17.0 en hoger gebruikt AKS het nieuwere label topology.kubernetes.io/zone en afgeschaft failure-domain.beta.kubernetes.io/zone. U kunt hetzelfde resultaat krijgen door de kubelet describe nodes opdracht uit te voeren in de vorige stap door het volgende script uit te voeren:

kubectl get nodes -o custom-columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology\.kubernetes\.io/region}',ZONE:'{metadata.labels.topology\.kubernetes\.io/zone}'

Het volgende voorbeeld lijkt op de uitvoer met uitgebreidere details:

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Poddistributie tussen zones controleren

Zoals beschreven in bekende labels, aantekeningen en Taints, gebruikt Kubernetes het topology.kubernetes.io/zone label om pods automatisch te distribueren in een replicatiecontroller of service in de verschillende beschikbare zones. Als u het label wilt testen en het cluster wilt schalen van 3 tot 5 knooppunten, voert u de volgende opdracht uit om te controleren of de pod correct wordt verdeeld:

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

Wanneer de schaalbewerking na een paar minuten is voltooid, voert u de opdracht kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" uit in een Bash-shell. De volgende uitvoer lijkt op de resultaten:

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

U hebt nu nog twee knooppunten in zones 1 en 2. U kunt een toepassing implementeren die bestaat uit drie replica's. In het volgende voorbeeld wordt NGINX gebruikt:

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

Door knooppunten weer te geven waarop uw pods worden uitgevoerd, ziet u dat pods worden uitgevoerd op de knooppunten die overeenkomen met drie verschillende beschikbaarheidszones. Met de opdracht kubectl describe pod | grep -e "^Name:" -e "^Node:" in een Bash-shell ziet u bijvoorbeeld de volgende voorbeelduitvoer:

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

Zoals u in de vorige uitvoer kunt zien, wordt de eerste pod uitgevoerd op knooppunt 0 in de beschikbaarheidszone eastus2-1. De tweede pod wordt uitgevoerd op knooppunt 2, die overeenkomt met eastus2-3en de derde in knooppunt 4, in eastus2-2. Zonder extra configuratie verspreidt Kubernetes de pods correct over alle drie de beschikbaarheidszones.

Volgende stappen

In dit artikel wordt beschreven hoe u een AKS-cluster maakt met behulp van beschikbaarheidszones. Zie Best practices voor bedrijfscontinuïteit en herstel na noodgevallen in AKS voor meer overwegingen over maximaal beschikbare clusters.