Verfügbarkeitszonen in Azure Kubernetes Service (AKS)

2025-05-12

Verfügbarkeitszonen helfen dabei, Ihre Anwendungen und Daten vor Ausfällen in Rechenzentren zu schützen. Zonen sind eindeutige physische Standorte in einer Azure-Region. Jede Zone umfasst eines oder mehrere Rechenzentren, die mit unabhängiger Stromversorgung, Kühlung und unabhängigem Netzwerk ausgestattet sind.

Die Verwendung von Azure Kubernetes Service (AKS) mit Verfügbarkeitszonen verteilt Ressourcen physisch über verschiedene Verfügbarkeitszonen innerhalb einer einzelnen Region und verbessert die Zuverlässigkeit. Bei der Bereitstellung von Knoten in mehreren Zonen entstehen keine zusätzlichen Kosten.

In diesem Artikel erfahren Sie, wie Sie AKS-Ressourcen für die Verwendung von Verfügbarkeitszonen konfigurieren.

AKS-Ressourcen

Dieses Diagramm zeigt die Azure-Ressourcen, die beim Erstellen eines AKS-Clusters erstellt werden:

AKS-Steuerungsebene

Microsoft hostet die AKS-Steuerungsebene, den Kubernetes API-Server und Dienste wie scheduler und etcd als verwalteten Dienst. Microsoft repliziert die Steuerungsebene in mehreren Zonen.

Andere Ressourcen Ihres Clusters werden in einer verwalteten Ressourcengruppe in Ihrem Azure-Abonnement bereitgestellt. Standardmäßig wird dieser Ressourcengruppe MC_ für verwalteten Cluster vorangestellt und enthält die in den folgenden Abschnitten erwähnten Ressourcen.

Knotenpools

Knotenpools werden als Skalierungsgruppen für virtuelle Computer in Ihrem Azure-Abonnement erstellt.

Wenn Sie einen AKS-Cluster erstellen, ist ein Systemknotenpool erforderlich und automatisch erstellt. Er hostet kritische System-Pods wie CoreDNS und metrics-server. Sie können Ihrem AKS-Cluster weitere Benutzerknotenpools hinzufügen, um Ihre Anwendungen zu hosten.

Es gibt drei Möglichkeiten zum Bereitstellen von Knotenpools:

Zonenübergreifend
An Zonen ausgerichtet
Länderspezifisch

Die Systemknotenpoolzonen werden beim Erstellen des Cluster- oder Knotenpools konfiguriert.

Zonenübergreifend

In dieser Konfiguration werden Knoten über alle ausgewählten Zonen verteilt. Diese Zonen werden mithilfe des --zones Parameters angegeben.

# 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 gleicht automatisch die Anzahl der Knoten zwischen Zonen ab.

Wenn ein zonaler Ausfall auftritt, können Knoten innerhalb der betroffenen Zone betroffen sein, aber Knoten in anderen Verfügbarkeitszonen bleiben unberührt.

Führen Sie zum Überprüfen von Knotenspeicherorten den folgenden Befehl aus:

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

An Zonen ausgerichtet

In dieser Konfiguration wird jeder Knoten an eine bestimmte Zone ausgerichtet (angeheftet). So erstellen Sie drei Knotenpools für eine Region mit drei Verfügbarkeitszonen:

# # 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

Diese Konfiguration kann verwendet werden, wenn eine niedrigere Latenz zwischen Knoten erforderlich ist. Sie bietet auch eine genauere Kontrolle über Skalierungsvorgänge oder wenn Sie die Cluster-Autoskalierung verwenden.

Hinweis

Wenn eine einzelne Workload über Knotenpools hinweg bereitgestellt wird, empfehlen wir, --balance-similar-node-groups auf true zu setzen, um während der Skalierungsvorgänge eine ausgewogene Verteilung von Knoten über die Zonen für Ihre Workloads aufrechtzuerhalten.

Regional (keine Verfügbarkeitszonen verwenden)

Der regionale Modus wird verwendet, wenn die Zonenzuweisung nicht in der Bereitstellungsvorlage festgelegt ist (zum Beispiel "zones"=[] oder "zones"=null).

In dieser Konfiguration erstellt der Knotenpool regionale (nicht zonenanheftete) Instanzen und platziert Instanzen implizit in der gesamten Region. Es gibt keine Garantie dafür, dass Instanzen über Zonen hinweg ausgeglichen oder verteilt sind oder sich Instanzen in derselben Verfügbarkeitszone befinden.

Im seltenen Fall eines vollständigen Zonenausfalls können alle Instanzen innerhalb des Knotenpools betroffen sein.

Führen Sie zum Überprüfen von Knotenspeicherorten den folgenden Befehl aus:

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

Bereitstellungen

Pods

Kubernetes kennt Azure-Verfügbarkeitszonen und kann Pods über Knoten in verschiedenen Zonen hinweg ausgleichen. Wenn eine Zone nicht verfügbar ist, entfernt Kubernetes automatisch die Pods von den betroffenen Knoten.

Wie in der Kubernetes-Referenz Well-Known Labels, Anmerkungen und Taints dokumentiert, verwendet Kubernetes das topology.kubernetes.io/zone Label, um Pods in einem Replikationscontroller oder Dienst automatisch über die verschiedenen verfügbaren Zonen zu verteilen.

Führen Sie den folgenden Befehl aus, um anzuzeigen, welche Pods und Knoten ausgeführt werden:

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

Der maxSkew Parameter beschreibt den Grad, in dem Pods ungleich verteilt werden können. Wenn Sie von drei Zonen und drei Replikaten ausgehen, stellt die Einstellung dieses Wertes auf 1 sicher, dass in jeder Zone mindestens ein Pod ausgeführt wird:

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

Speicher und Volumes

Standardmäßig verwenden Kubernetes-Versionen 1.29 und höher Azure Managed Disks, indem zonenredundanter Speicher für persistente Volumeansprüche verwendet wird.

Diese Datenträger werden zwischen Zonen repliziert, um die Resilienz Ihrer Anwendungen zu verbessern. Diese Aktion trägt dazu bei, Ihre Daten vor Datencenterfehlern zu schützen.

Das folgende Beispiel zeigt einen persistenten Volumeanspruch, der Azure Standard SSD im zonenredundanten Speicher verwendet:

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

Für zonenorientierte Bereitstellungen können Sie eine neue Speicherklasse erstellen, deren skuname Parameter auf LRS (lokal redundanter Speicher) festgelegt ist. Anschließend können Sie die neue Speicherklasse in Ihrem persistenten Volumeanspruch verwenden.

Obwohl lokal redundante Speicherdatenträger weniger teuer sind, sind sie nicht zonenredundant, und das Anfügen eines Datenträgers an einen Knoten in einer anderen Zone wird nicht unterstützt.

Das folgende Beispiel zeigt eine lokal redundante Speicherstandard-SSD-Speicherklasse:

kind: StorageClass

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

Lastenausgleichsgeräte

Kubernetes stellt standardmäßig azure Standard Load Balancer bereit, der eingehenden Datenverkehr über alle Zonen in einer Region verteilt. Wenn ein Knoten nicht verfügbar ist, leitet der Lastenausgleich den Verkehr auf intakte Knoten um.

Ein Beispieldienst, der Azure Load Balancer verwendet:

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

Wichtig

Am 30. September 2025 wird Load Balancer im Tarif „Basic“ eingestellt. Weitere Informationen finden Sie in der offiziellen Ankündigung. Wenn Sie Load Balancer Basic verwenden, führen Sie unbedingt vor dem Ablaufdatum ein Upgrade auf Load Balancer Standard durch.

Einschränkungen

Die folgenden Einschränkungen gelten für die Verwendung von Verfügbarkeitszonen:

Siehe Kontingente, Größenbeschränkungen für virtuelle Computer und Regionsverfügbarkeit in AKS.
Die Anzahl der verwendeten Verfügbarkeitszonen kann nicht geändert werden , nachdem der Knotenpool erstellt wurde.
Die meisten Regionen unterstützen Verfügbarkeitszonen. Eine Liste der Regionen anzeigen.

Erfahren Sie mehr über Systemknotenpools.
Erfahren Sie mehr über Benutzerknotenpools.
Erfahren Sie mehr über Lastenausgleichsgeräte.
Erhalten Sie bewährte Methoden für Geschäftskontinuität und Notfallwiederherstellung in AKS.