Overzicht van beschikbaarheidszones in Azure Kubernetes Service (AKS)

Dit artikel bevat een overzicht van het gebruik van beschikbaarheidszones in Azure Kubernetes Service (AKS) om de beschikbaarheid van uw toepassingen te vergroten.

Een AKS-cluster 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.

Wat zijn beschikbaarheidszones?

Beschikbaarheidszones helpen uw toepassingen en gegevens te beschermen tegen datacenterfouten. 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.

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.

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

Zie Azure-beschikbaarheidszones gebruiken voor meer informatie.

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. Deze configuratie garandeert niet dat vergelijkbare knooppuntgroepen hetzelfde aantal knooppunten hebben:

• Op dit moment treedt er alleen een taakverdeling op tijdens het opschalen van bewerkingen. De automatische schaalaanpassing van clusters schaalt onderbenutte knooppunten omlaag, ongeacht de relatieve grootte van de knooppuntgroepen.
• De automatische schaalaanpassing van clusters voegt alleen zo veel knooppunten toe als nodig is om alle bestaande pods uit te voeren. Sommige groepen hebben mogelijk meer knooppunten dan andere als er meer pods zijn gepland.
• De automatische schaalaanpassing van clusters wordt alleen verdeeld tussen knooppuntgroepen die dezelfde set in behandeling zijnde pods kunnen ondersteunen.

U kunt ook ZRS-schijven (Zone-redundante opslag) van Azure gebruiken om uw opslag te repliceren in drie beschikbaarheidszones in de regio die u selecteert. Met een ZRS-schijf kunt u herstellen van een fout in de beschikbaarheidszone zonder gegevensverlies. Zie ZRS voor beheerde schijven voor meer informatie.

Beperkingen

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 Azure Disk-beschikbaarheidszones

Volumes die gebruikmaken van door Azure beheerde LRS-schijven zijn geen zone-redundante resources en het koppelen tussen zones wordt niet ondersteund. U moet volumes in dezelfde zone plaatsen 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. In het volgende voorbeeld ziet u hoe u een opslagklasse maakt 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-versies 1.12 en hoger zijn op de hoogte van Azure-beschikbaarheidszones. 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.

Vanaf Kubernetes versie 1.29, wanneer u AKS-clusters (Azure Kubernetes Service) implementeert in meerdere beschikbaarheidszones, maakt AKS nu gebruik van zone-redundante opslag (ZRS) om beheerde schijven te maken binnen ingebouwde opslagklassen. ZRS zorgt voor synchrone replicatie van uw door Azure beheerde schijven in meerdere Azure-beschikbaarheidszones in uw gekozen regio. Deze redundantiestrategie verbetert de tolerantie van uw toepassingen en beschermt uw gegevens tegen datacenterfouten.

Het is echter belangrijk om te weten dat zone-redundante opslag (ZRS) een hogere kosten heeft ten opzichte van lokaal redundante opslag (LRS). Als kostenoptimalisatie een prioriteit is, kunt u een nieuwe opslagklasse maken met de skuname parameter die is ingesteld op LRS. Vervolgens kunt u de nieuwe opslagklasse gebruiken in uw Persistent Volume Claim (PVC).

Volgende stappen

• Maak een AKS-cluster met beschikbaarheidszones.