Verfügbarkeitszonen in Azure Kubernetes Service (AKS)

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.

Durch die Verwendung von AKS mit Verfügbarkeitszonen werden die Ressourcen physisch auf verschiedene Verfügbarkeitszonen innerhalb einer einzigen Region verteilt, was die Zuverlässigkeit erhöht. 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 mit 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 das Präfix MC_ für Managed Cluster vorangestellt und sie enthält die folgenden Ressourcen:

Knotenpools

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

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

Es gibt drei Möglichkeiten zum Bereitstellen von Knotenpools:

• Zonenübergreifend
• An Zonen ausgerichtet
• Länderspezifisch

Für den Systemknotenpool wird die Anzahl der verwendeten Zonen konfiguriert, wenn der Cluster erstellt wird.

Zonenübergreifend

Eine zonenübergreifende Skalierungsgruppe verteilt Knoten auf alle ausgewählten Zonen, indem sie diese Zonen mit dem Parameter --zones angibt.

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

Bei einem Zonenausfall können Knoten innerhalb der betroffenen Zone beeinträchtigt sein, Knoten in anderen Verfügbarkeitszonen sind jedoch nicht betroffen.

An Zonen ausgerichtet

Jeder Knoten wird 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 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

Diese Konfiguration kann verwendet werden, wenn eine niedrigere Latenz zwischen Knoten erforderlich ist. Sie bietet zudem eine genauere Kontrolle über Skalierungsvorgänge oder bei Verwendung des Cluster-Autoscaler.

Regional (ohne Verwendung von Verfügbarkeitszonen)

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

In dieser Konfiguration erstellt der Knotenpool regionsbezogene (nicht an eine Zone angefügte) Instanzen und platziert Instanzen implizit in der gesamten Region. Es gibt keine Garantie für einen Lastenausgleich oder eine Verteilung auf die Zonen, und es ist nicht garantiert, dass Instanzen in derselben Verfügbarkeitszone landen.

Im seltenen Fall des Ausfalls einer ganzen Zone können einzelne oder alle Instanzen im Knotenpool betroffen sein.

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

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

Bereitstellungen

Pods

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

Wie unter Well-Known Labels, Annotations and Taints (Bekannte Bezeichnungen, Anmerkungen und Taints) dokumentiert, wird in Kubernetes die Bezeichnung topology.kubernetes.io/zone zum automatischen Verteilen von Pods in einem Replikationscontroller oder Replikationsdienst in den verschiedenen verfügbaren Zonen verwendet.

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

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

Der Parameter „maxSkew“ beschreibt das Ausmaß, in dem Pods ungleichmäßig 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:

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

Speicher und Volumes

Standardmäßig verwenden Kubernetes-Versionen 1.29 und höher Azure Managed Disks mit zonenredundantem Speicher (ZRS) für persistente Volumeansprüche.

Diese Datenträger werden zwischen Zonen repliziert, um die Resilienz Ihrer Anwendungen zu verbessern und Ihre Daten vor Rechenzentrumsaufällen zu schützen.

Ein Beispiel für einen persistenten Volumeanspruch, der SSD Standard in ZRS 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, wobei der Parameter skuname auf LRS (lokal redundanter Speicher) eingestellt ist. Anschließend können Sie die neue Speicherklasse in Ihrem Persistent Volume Claim (PVC) verwenden.

LRS-Datenträger sind zwar preiswerter, aber nicht zonenredundant, und das Anschließen eines Datenträgers an einen Knoten in einer anderen Zone wird nicht unterstützt.

Beispiel für eine LRS SSD Standard-Speicherklasse:

kind: StorageClass

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

Lastenausgleiche

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

Ein Beispieldienst, der den Azure Load Balancer verwendet:

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

Einschränkungen

Die folgenden Einschränkungen gelten bei der Verwendung von Verfügbarkeitszonen:

• Siehe Kontingente, Größeneinschränkungen für virtuelle Computer und regionale Verfü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 finden Sie hier.

Nächste Schritte

• Weitere Informationen zu Systemknotenpools
• Weitere Informationen zu Benutzerknotenpools
• Weitere Informationen zu Lastenausgleichern
• Bewährte Methoden für Geschäftskontinuität und Notfallwiederherstellung in AKS