Delen via

Beschikbaarheidszones in Azure Kubernetes Service (AKS)

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.

Het gebruik van Azure Kubernetes Service (AKS) met beschikbaarheidszones distribueert resources fysiek over verschillende beschikbaarheidszones binnen één regio, waardoor de betrouwbaarheid wordt verbeterd. Voor het implementeren van knooppunten in meerdere zones worden geen extra kosten in rekening gebracht.

In dit artikel leest u hoe u AKS-resources configureert voor het gebruik van beschikbaarheidszones.

AKS-resources

In dit diagram ziet u de Azure-resources die worden gemaakt bij het maken van een AKS-cluster:

Diagram met verschillende AKS-onderdelen, waaronder AKS-onderdelen die worden gehost door Microsoft- en AKS-onderdelen in uw Azure-abonnement.

AKS-besturingsvlak

Microsoft host het AKS-besturingsvlak, de Kubernetes-API-server en -services, zoals scheduler en etcd als een beheerde service. Microsoft repliceert het besturingsvlak in meerdere zones.

Andere resources van uw cluster worden ingezet in een beheerde resourcegroep in uw Azure-abonnement. Deze resourcegroep wordt standaard voorafgegaan door MC_ voor beheerd cluster en bevat de resources die in de volgende secties worden vermeld.

Knooppuntpools

Node pools worden gemaakt als virtuele machineschaalsets in uw Azure-abonnement.

Wanneer u een AKS-cluster maakt, is één systeemknooppuntgroep vereist en wordt automatisch gemaakt. Het host kritieke systeempods zoals CoreDNS en metrics-server. U kunt meer gebruikersknooppuntgroepen toevoegen aan uw AKS-cluster om uw toepassingen te hosten.

Er zijn drie manieren waarop knooppuntgroepen kunnen worden geïmplementeerd:

  • Zone-overstijgend
  • Zone uitgelijnd
  • Regionaal

Diagram met AKS-knooppuntdistributie over beschikbaarheidszones in verschillende modellen.

De zones van de systeemknooppuntgroep worden geconfigureerd wanneer het cluster of de knooppuntgroep wordt gemaakt.

Zone-omspannend

In deze configuratie worden knooppunten verspreid over alle geselecteerde zones. Deze zones worden opgegeven met behulp van de --zones parameter.

# Create an AKS cluster, and create a zone-spanning system node pool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1 2 3
# Add one new zone-spanning user node pool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1 2 3

AKS balanceert automatisch het aantal knooppunten tussen zones.

Als er een zonegebonden storing optreedt, kunnen knooppunten in de getroffen zone worden beïnvloed, maar blijven knooppunten in andere beschikbaarheidszones ongewijzigd.

Voer de volgende opdracht uit om knooppuntlocaties te valideren:

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

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

Zone uitgelijnd

In deze configuratie wordt elk knooppunt uitgelijnd (vastgemaakt) aan een specifieke zone. Drie knooppuntgroepen maken voor een regio met drie beschikbaarheidszones:

# # Add three new zone-aligned user node pools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

Deze configuratie kan worden gebruikt wanneer u een lagere latentie tussen knooppunten nodig hebt. Het biedt ook meer gedetailleerde controle over schaalbewerkingen of wanneer u de automatische schaalaanpassing van clusters gebruikt.

Notitie

Als een enkele workload wordt geïmplementeerd in knooppools, raden we u aan om --balance-similar-node-groups naar true te zetten om een evenwichtige verdeling van knooppunten tussen zones voor uw workloads te behouden tijdens schaalvergrotingsoperaties.

Regionaal (niet met beschikbaarheidszones)

De regionale modus wordt gebruikt wanneer de zonetoewijzing niet is ingesteld in de implementatiesjabloon (bijvoorbeeld "zones"=[] of "zones"=null).

In deze configuratie creëert de nodepool regionale (niet zone-gebonden) exemplaren en plaatst deze impliciet door de hele regio. Er is geen garantie dat exemplaren evenwichtig zijn of verspreid over zones, of dat exemplaren zich in dezelfde beschikbaarheidszone bevinden.

In het zeldzame geval van een volledige zonestoring kunnen alle of alle exemplaren in de knooppuntgroep worden beïnvloed.

Voer de volgende opdracht uit om knooppuntlocaties te valideren:

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

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   0
aks-nodepool1-34917322-vmss000001   eastus   0
aks-nodepool1-34917322-vmss000002   eastus   0

Installaties

Peulen

Kubernetes is bekend met Azure-beschikbaarheidszones en kan pods evenwichtig verdelen over knooppunten in verschillende zones. In het geval dat een zone niet beschikbaar is, verplaatst Kubernetes pods automatisch van betrokken knooppunten.

Zoals beschreven in de Kubernetes-verwijzing Well-Known Labels, Aantekeningen en Taints, gebruikt Kubernetes het topology.kubernetes.io/zone label om pods automatisch te distribueren in een replicatiecontroller of service over de verschillende beschikbare zones.

Voer de volgende opdracht uit om te zien welke pods en knooppunten actief zijn:

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

De maxSkew parameter beschrijft de mate waarin pods ongelijk verdeeld kunnen zijn. Ervan uitgaande dat er drie zones en drie replica's zijn, stelt u deze waarde in om ervoor te 1 zorgen dat elke zone ten minste één pod heeft die wordt uitgevoerd:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
      containers:
      - name: my-container
        image: my-image

Opslag en volumes

Kubernetes-versies 1.29 en hoger maken standaard gebruik van Azure Managed Disks met zone-redundante opslag voor permanente volumeclaims.

Deze schijven worden tussen zones gerepliceerd om de tolerantie van uw toepassingen te verbeteren. Met deze actie kunt u uw gegevens beschermen tegen storingen in datacenters.

In het volgende voorbeeld ziet u een permanente volumeclaim die gebruikmaakt van Azure Standard SSD in zone-redundante opslag:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

Voor zone-uitgelijnde implementaties kunt u een nieuwe opslagklasse maken met de skuname parameter ingesteld op LRS (lokaal redundante opslag). Vervolgens kunt u de nieuwe opslagklasse in uw permanente volumeclaim gebruiken.

Hoewel lokaal redundante opslagschijven goedkoper zijn, zijn ze niet zone-redundant en wordt het koppelen van een schijf aan een knooppunt in een andere zone niet ondersteund.

In het volgende voorbeeld ziet u een lokaal redundante Standard SSD-opslagklasse:

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

Verdelers

Kubernetes implementeert standaard Azure Standard Load Balancer, waarmee inkomend verkeer wordt verdeeld over alle zones in een regio. Als een knooppunt niet beschikbaar is, wordt verkeer door de load balancer omgeleid naar knooppunten die in orde zijn.

Een voorbeeldservice die gebruikmaakt van Azure Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Belangrijk

Op 30 september 2025 wordt Basic Load Balancer buiten gebruik gesteld. Zie de officiële aankondiging voor meer informatie. Als u Basic Load Balancer gebruikt, moet u vóór de buitengebruikstelling een upgrade uitvoeren naar Standard Load Balancer.

Beperkingen

De volgende beperkingen gelden wanneer u beschikbaarheidszones gebruikt:

Verwante inhoud