Delen via

Beschikbaarheidszones in Azure Kubernetes Service (AKS)

  • Artikel

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 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, met 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 implementeren in een beheerde resourcegroep in uw Azure-abonnement. Deze resourcegroep wordt standaard voorafgegaan door MC_, voor beheerd cluster en bevat de volgende resources:

Knooppuntpools

Knooppuntgroepen worden gemaakt als een virtuele-machineschaalset in uw Azure-abonnement.

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

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

  • Zone-spanning
  • Zone uitgelijnd
  • Regionaal

Diagram met AKS-knooppuntdistributie over beschikbaarheidszones in de verschillende modellen.

Voor de systeemknooppuntgroep wordt het aantal gebruikte zones geconfigureerd wanneer het cluster wordt gemaakt.

Zone-spanning

Een zone die de schaalset beslaat, verspreidt knooppunten over alle geselecteerde zones door deze zones met de --zones parameter op te geven.

# Create an AKS Cluster, and create a zone spanning System Nodepool 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 Nodepool, 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 binnen de getroffen zone worden beïnvloed, terwijl knooppunten in andere beschikbaarheidszones niet worden beïnvloed.

Zone uitgelijnd

Elk knooppunt wordt uitgelijnd (vastgemaakt) aan een specifieke zone. Drie knooppuntgroepen maken voor een regio met drie Beschikbaarheidszones:

# # Add three new zone aligned User Nodepools, 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 gedetailleerdere controle over schaalbewerkingen of wanneer u de automatische schaalaanpassing van clusters gebruikt.

Notitie

  • Als één workload wordt geïmplementeerd in knooppuntgroepen, raden we u aan --balance-similar-node-groups om een evenwichtige verdeling van knooppunten tussen zones voor uw workloads te true behouden tijdens het opschalen van bewerkingen.

Regionaal (niet met Beschikbaarheidszones)

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

In deze configuratie maakt de knooppuntgroep regionale (niet-zone vastgemaakte) exemplaren en plaatst impliciet exemplaren in de hele regio. Er is geen garantie voor saldo of verdeling tussen zones, of die exemplaren landen in dezelfde beschikbaarheidszone.

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 describe nodes | grep -e "Name:" -e "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

Installaties

Pods

Kubernetes is op de hoogte van Azure Beschikbaarheidszones en kan pods verdelen over knooppunten in verschillende zones. In het geval dat een zone niet meer beschikbaar is, verplaatst Kubernetes pods automatisch van betrokken knooppunten.

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.

Voer de volgende opdracht uit om te bekijken op welke pods-knooppunten worden uitgevoerd:

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

De parameter maxSkew beschrijft de mate waarin Pods ongelijk verdeeld kunnen zijn. Ervan uitgaande dat er drie zones en drie replica's zijn, zorgt u ervoor dat elke zone ten minste één pod heeft die wordt uitgevoerd:

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Opslag en volumes

Kubernetes-versies 1.29 en hoger maken standaard gebruik van Azure Managed Disks met zone-redundant-storage (ZRS) voor permanente volumeclaims.

Deze schijven worden tussen zones gerepliceerd om de tolerantie van uw toepassingen te verbeteren en uw gegevens te beschermen tegen datacenterfouten.

Een voorbeeld van een permanente volumeclaim die gebruikmaakt van Standard SSD in ZRS:

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 gebruiken in uw Persistent Volume Claim (PVC).

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

Een voorbeeld van een LRS Standard SSD-opslagklasse:

kind: StorageClass

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

Load balancers

Kubernetes implementeert standaard een 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 de 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 momenteel Basic Load Balancer gebruikt, moet u vóór de buitengebruikstelling een upgrade uitvoeren naar Standard Load Balancer.

Beperkingen

De volgende beperkingen zijn van toepassing bij het gebruik van Beschikbaarheidszones:

Volgende stappen