Empfehlungen zur Zonen-Resilienz für Azure Kubernetes Service (AKS)

Gilt für: ✔️ AKS Automatic ✔️ AKS Standard

Die Resilienz der Zonen ist ein wichtiges Element beim Ausführen von Kubernetes Clustern in Produktionsqualität. Mit seiner Skalierbarkeit als Kernstück nutzt Kubernetes die Vorteile unabhängiger Infrastrukturen in Rechenzentren in vollem Umfang, ohne zusätzliche Kosten zu verursachen, da neue Knoten nur bei Bedarf bereitgestellt werden.

In diesem Artikel lernen Sie Empfehlungen für die Zonenresilienz in AKS kennen, einschließlich der Folgenden:

• AKS-Clusterkomponenten zonenresilient machen.
• Entwerfen Sie zustandslose Anwendungen für Zonenfehlerszenarien.
• Wählen Sie Speicherredundanzoptionen aus.
• Testen Sie das Anwendungs- und Plattformverhalten während zonaler Fehler.

AKS-Clustermodi und Zonenresilienz

AKS unterstützt zwei Clustermodi:

• AKS Automatic, das mehr vorkonfigurierte Plattformstandardwerte bereitstellt.
• AKS Standard, das eine umfassendere direkte Kontrolle für Betreiber bietet.

Zonenresilienzprinzipien in diesem Artikel gelten für beide Clustermodi. Der entscheidende Unterschied ist die Verantwortung für den Plattformbetrieb.

Eine vollständige Übersicht über das Verhalten der Features nach Modus finden Sie unter „Funktionsvergleich von AKS Automatic und AKS Standard“.

Gestalten zonenresilienter AKS-Clusterkomponenten

In den folgenden Abschnitten werden wichtige Entscheidungspunkte für die Zonenresilienz in AKS beschrieben. Sie sind nicht erschöpfend. Außerdem sollten Sie die Zonenresilienz für Abhängigkeiten wie Datenspeicher, Identitätssysteme und externe Dienste überprüfen.

Erstellen von zonenredundanten Clustern und Knotenpools

Mit AKS können Sie während der Erstellung von Cluster- und Knotenpools mehrere AZs auswählen. In Regionen, die mehrere AZs unterstützen, wird die Steuerebene automatisch über Zonen verteilt. Die Knoten des Knotenpools werden auf die ausgewählten Zonen verteilt. Mit diesem Ansatz wird sichergestellt, dass die Steuerebene und die Knoten über mehrere AZs verteilt werden, was die Resilienz im Falle eines AZ-Ausfalls gewährleistet.

Anleitung für den Clustermodus:

• AKS Automatic: Viele Plattformstandardwerte sind vorkonfiguriert. Sie sollten dennoch überprüfen, ob geschäftskritische Workloads absichtlich über Zonen verteilt werden und dass das Fehlerverhalten den Anforderungen entspricht.
• AKS Standard: Definieren Sie die Knotenpool-Topologie, Skalierungseinstellungen und das Verhalten bei Fehlerdomänen explizit.

Das folgende Beispiel zeigt, wie Sie einen Cluster mit drei Knoten verteilt über drei AZs mithilfe der Azure CLI erstellen:

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

Nachdem der Cluster erstellt wurde, können Sie den folgenden Befehl verwenden, um die Region und Verfügbarkeitszone für jeden Agentknoten aus den Bezeichnungen abzurufen:

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

Die folgende Beispielausgabe zeigt die Region und Verfügbarkeitszone für jeden Agentknoten:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

Weitere Informationen finden Sie unter Verwenden von Verfügbarkeitszonen in Azure Kubernetes Service (AKS).

Sicherstellen der Verteilung von Pods über VZs

Die Pod-Platzierungsstrategie ist sowohl bei AKS Automatic als auch bei AKS Standard ein Aspekt auf Workload-Ebene. Plattformstandardwerte ersetzen keine Anforderungen an die Topologie auf Workloadebene.

Ab Kubernetes-Version 1.33 ist der Standard-Kube-Scheduler in AKS so konfiguriert, dass für MaxSkew ein topology.kubernetes.io/zone-Wert von 1 verwendet wird:

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

Diese Konfiguration zielt nicht mehr als auf einen einzelnen Pod-Unterschied zwischen Zonen ab, wodurch die Chance verringert wird, dass ein Zonenausfall zu einem Bereitstellungsausfall führt.

Wenn Ihr Deployment spezifische Topologieanforderungen hat, überschreiben Sie diese Standardwerte in Ihrer Pod-Spezifikation. Sie können Topologieverteilungsregeln für Pods auf Grundlage der Labels zone und hostname verwenden, um Pods über AZs innerhalb einer Region und über Hosts innerhalb von AZs zu verteilen.

Nehmen wir beispielsweise an, Sie haben einen Cluster mit vier Knoten, in dem sich drei Pods mit der Bezeichnung app: mypod-app in node1, node2 und node3 befinden. Wenn die eingehende Bereitstellung möglichst auf unterschiedlichen Knoten gehostet werden soll, können Sie ein Manifest ähnlich dem folgenden Beispiel verwenden:

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Weitere Informationen zum Konfigurieren der Podverteilung und zum Verständnis der Auswirkungen von MaxSkewKubernetes Pod Topology finden Sie in der Dokumentation zu Kubernetes Pod Topology. Beispiel: Wie wirkt sich nodeTaintsPolicy: Honor auf die Podverteilung aus?

Konfigurieren von AZ-fähigen Netzwerken

Wenn Sie über Pods für Netzwerkdatenverkehr verfügen, sollten Sie für den Datenverkehr einen Lastenausgleich über mehrere VZs hinweg vornehmen, um sicherzustellen, dass Ihre Anwendung hochverfügbar und resilient gegenüber Fehlern ist. Sie können Azure Load Balancer verwenden, um eingehenden Datenverkehr über die Knoten in Ihrem AKS-Cluster zu verteilen.

Azure Load Balancer unterstützt sowohl internen als auch externen Lastenausgleich, und Sie können ihn so konfigurieren, dass eine Standard-SKU für einen zonenredundanten Lastenausgleich verwendet wird. Die Standard-SKU entspricht der standardmäßigen SKU in AKS und unterstützt regionale Resilienz mit Verfügbarkeitszonen, um sicherzustellen, dass Ihre Anwendung nicht von dem Ausfall einer Region betroffen ist. Im Fall eines Zonenausfalls wird ein zonenredundanter Lastenausgleich mit Standard-SKU nicht durch den Ausfall beeinträchtigt, und Ihre Bereitstellungen können den Datenverkehr aus den verbleibenden Zonen fortsetzen. Sie können einen globalen Lastenausgleich verwenden, z. B. Front Door oder Traffic Manager, oder Sie können regionsübergreifende Load Balancer vor Ihren regionalen AKS-Clustern verwenden, um sicherzustellen, dass Ihre Anwendung nicht von regionalen Ausfällen betroffen ist. Informationen zum Erstellen eines Standard-SKU-Lastenausgleichs in AKS finden Sie unter Verwenden eines Lastenausgleichs mit einer Standard-SKU in Azure Kubernetes Service (AKS).

Um sicherzustellen, dass der Netzwerkdatenverkehr Ihrer Anwendung ausfallsicher ist, sollten Sie AZ-fähige Netzwerke für Ihre AKS-Workloads konfigurieren. Azure bietet verschiedene Netzwerkdienste, die AZs unterstützen:

• Azure VPN Gateway: Sie können VPN- und ExpressRoute-Gateways in Azure AZs bereitstellen, um bessere Resilienz, Skalierbarkeit und Verfügbarkeit für virtuelle Netzwerk-Gateways zu ermöglichen. Weitere Informationen finden Sie unter Erstellen zonenredundanter Gateways für das virtuelle Netzwerk in Verfügbarkeitszonen.
• Azure Application Gateway v2: Azure Application Gateway bietet einen regionalen L7 Load-Balancer mit Unterstützung für Verfügbarkeitszonen. Weitere Informationen finden Sie unter Weiterleiten von Webdatenverkehr per Azure Application Gateway.
• Azure Front Door: Azure Front Door bietet einen globalen L7 Load-Balancer und nutzt Points of Presence (POPs) oder Azure Content Delivery Network (CDN). Weitere Informationen finden Sie unter Azure Front Door-POP-Standorte.

Einrichten einer zonenredundanten Containerregistrierung mit Georeplikation

Um sicherzustellen, dass Ihre Containerimages hoch verfügbar und ausfallsicher sind, sollten Sie eine zonenredundante Containerregistrierung einrichten. Die Azure Container Registry (ACR) Premium-SKU unterstützt Georeplikation und optionale Zonenredundanz. Diese Features bieten Verfügbarkeit und verringern die Latenz für regionale Vorgänge.

Sicherstellen der Verfügbarkeit und Redundanz für Schlüssel und geheime Schlüssel

Azure Key Vault bietet mehrere Redundanzebenen, um sicherzustellen, dass Ihre Schlüssel und Secrets für Ihre Anwendung verfügbar bleiben, selbst wenn einzelne Komponenten des Dienstes ausfallen oder Azure Regionen oder AZs nicht verfügbar sind. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz.

Verwenden von Features für die automatische Skalierung

Sie können die Verfügbarkeit und Resilienz von Anwendungen in AKS mit Features für automatische Skalierung verbessern, um die folgenden Ziele zu erreichen:

• Optimieren Sie die Ressourcenauslastung und Kosteneffizienz, indem Sie basierend auf der CPU- und Speicherauslastung Ihrer Pods nach oben oder unten skalieren.
• Verbessern Sie die Fehlertoleranz und -wiederherstellung, indem Sie weitere Knoten oder Pods hinzufügen, wenn ein Zonenausfall eintritt.

Sie können die Horizontale automatische Podskalierung (HPA) und Automatische Clusterskalierung verwenden, um die automatische Skalierung in AKS zu implementieren. Die HPA skaliert automatisch die Anzahl der Pods in einer Bereitstellung basierend auf beobachteter CPU-Auslastung, Speicherauslastung, benutzerdefinierten Metriken und Metriken anderer Dienste. Die Clusterautoskalierung passt die Anzahl der Knoten in einem Knotenpool basierend auf ausstehenden Pods und den Ressourcenanforderungen für die ausstehenden Pods automatisch an.

Anleitung für den Clustermodus:

• AKS Automatic: Konzentrieren Sie sich auf Workloadanforderungen und -beschränkungen, Podverteilungsrichtlinien und Unterbrechungskontrollen, sodass die vorkonfigurierte Plattformskalierung den Dienst während des zonalen Stress wiederherstellen kann.
• AKS Standard: Entwerfen Sie explizit Knotenpoolbegrenzungen, Skalierungsrichtlinien und Autoskalierungseinstellungen, um sie an zonenbezogene Planungseinschränkungen auszurichten.

Das Feature "AKS Karpenter Provider" ermöglicht die automatische Bereitstellung von Knoten mithilfe von Karpenter auf Ihrem AKS-Cluster. Weitere Informationen finden Sie in der Funktionsübersicht zu AKS Karpenter Provider.

Das Kubernetes-based Event Driven Autocaling (KEDA) Add-On für AKS wendet die ereignisgesteuerte automatische Skalierung an, um Ihre Anwendung basierend auf Metriken externer Dienste zu skalieren und so die Nachfrage zu erfüllen. Weitere Informationen finden Sie unter Installieren des KEDA-Add-Ons in Azure Kubernetes Service (AKS).

Zonenskalierungsstrategie durch den AKS-Clustermodus

Richten Sie Ihr Knotenpoolmodell für zonenbewusstes Scale-up-Verhalten an den Scheduler-Einschränkungen und Ihrem Clustermodus aus.

AKS Standard

Bei verwendung von Cluster autoscaler mit Verfügbarkeitszonen ist eine gängige bewährte Methode ein Knotenpool pro Zone. Sie können --balance-similar-node-groups auf True festlegen, um bei der Hochskalierung eine ausgewogene Verteilung der Knoten auf die Zonen beizubehalten.

Warum dies wichtig ist:

• Die Cluster-Autoskalierung simuliert die Planung nach Knotenpool, nicht nach einer bestimmten Zonenplatzierung.
• In einem Node-Pool mit mehreren Zonen kann eine Hochskalierung einen neuen Knoten in einer Zone platzieren, die weiterhin gegen strikte Topologieverteilungsbeschränkungen verstößt, wodurch Pods im Status „Pending“ verbleiben.
• Virtual Machine Scale Sets verwendet den Best-Effort-Zonenausgleich. Während Kapazitätsengpässen in einer Zone oder bei Ausfällen einer Zone kann die Zuweisung fehlschlagen und den Knotenpool in den Backoff-Status versetzen.
• Die Verwendung eines Knotenpools pro Zone verbessert die Kontrolle des zonenspezifischen Skalierungsverhaltens.

Die Cluster-Autoskalierung ist nicht zonenfähig, und die Zonenzuweisung wird von der zugrunde liegenden Virtual Machine Scale Sets und nicht von AKS behandelt. Diese bewährte Methode wird noch relevanter, wenn zonenbasierte Podtopologie-Einschränkungen für einen einzelnen Knotenpool mit mehreren Zonen verwendet werden, da restriktive Einschränkungen Pods in einem ausstehenden Zustand belassen können, insbesondere in kapazitätseinschränkten Regionen oder in Zonen-Down-Szenarien.

AKS Automatik

AKS Automatic verwendet vorkonfiguriertes Verhalten verwalteter Knoten und Standardwerte für die automatische Knotenbereitstellung. Sie können nicht annehmen, dass kritische Workloads zonenresilient sind, ohne Richtlinien auf Workload-Ebene.

Überprüfen Sie bei kritischen Diensten Folgendes:

• Verhalten der Pod-Topologieverteilung über Zonen hinweg.
• Wiederherstellungsverhalten während des Zonaldrucks.
• Planungsergebnisse, wenn strenge Einschränkungen verwendet werden.
• Anwendungsverhalten, wenn eine Zone nicht verfügbar ist.

Entwerfen einer zustandslosen Anwendung

Wenn eine Anwendung zustandslos ist, werden die Anwendungslogik und die Daten entkoppelt, und die Pods speichern keine persistenten oder Sitzungsdaten auf ihren lokalen Datenträgern. Dieses Design ermöglicht ein einfache Hoch- oder Runterskalieren der Anwendung, ohne dass man sich Gedanken über Datenverlust machen muss. Statusfreie Anwendungen sind resilienter gegenüber Ausfällen, da sie im Fall eines Knotenausfalls problemlos ersetzt oder neu geplant werden können.

Beim Entwerfen einer zustandslosen Anwendung mit AKS sollten Sie verwaltete Azure-Dienste wie Azure-Datenbanken, azure Managed Redis oder Azure Storage verwenden, um die Anwendungsdaten zu speichern. Durch die Verwendung dieser Dienste wird sichergestellt, dass Ihr Datenverkehr über Knoten und Zonen verschoben werden kann, ohne dass Sie Datenverluste oder Auswirkungen auf die Benutzererfahrung riskieren. Sie können Kubernetes-Bereitstellungen, -Dienste und -Integritätstests verwenden, um statusfreie Pods zu verwalten und die gleichmäßige Verteilung über Zonen hinweg sicherzustellen.

Treffen der Entscheidung über den Speicherdatenträger

Auswählen des richtigen Datenträgertyps basierend auf den Anwendungsanforderungen

Azure bietet zwei Arten von Datenträgern für beständigen Speicher: lokal redundanten Speicher (LRS) und zonenredundanten Speicher (ZRS). Bei LRS werden Ihre Daten in einer einzelnen VZ repliziert. ZRS repliziert Ihre Daten über mehrere AZs innerhalb einer Region. Ab AKS Version 1.29 verwendet die Standardspeicherklasse ZRS-Datenträger für beständigen Speicher. Weitere Informationen finden Sie unter In AKS integrierte Speicherklassen.

Die Art und Weise, wie Ihre Anwendung Daten repliziert, kann die Auswahl des Datenträgers beeinflussen. Wenn sich Ihre Anwendung in mehreren Zonen befindet und die Daten aus der Anwendung repliziert, können Sie Resilienz mit einem LRS-Datenträger in jeder AZ erzielen, da bei einem AZ-Ausfall die anderen AZs über die neuesten Daten verfügen. Wenn Ihre Anwendungsschicht diese Replikation nicht verarbeitet, sind ZRS-Datenträger eine bessere Wahl, da Azure die Replikation auf der Speicherebene behandelt.

In der folgenden Tabelle sind Vor- und Nachteile jedes Datenträgertyps aufgeführt:

Weitere Informationen zu den LRS- und ZRS-Datenträgertypen Azure Storage-Redundanz. Informationen zum Bereitstellen von Speicherdatenträgern in AKS finden Sie unter Bereitstellen von Azure Disks-Storage in Azure Kubernetes Service (AKS).

Überwachung der Datenträgerleistung

Um eine optimale Leistung und Verfügbarkeit Ihrer Speicherdatenträger in AKS sicherzustellen, sollten Sie wichtige Metriken wie IOPS, Durchsatz und Latenz überwachen. Diese Metriken können Ihnen dabei helfen, Probleme oder Engpässe zu identifizieren, die sich auf die Leistung Ihrer Anwendung auswirken können. Wenn Sie konsistente Leistungsprobleme feststellen, sollten Sie den Datenträgertyp oder die Größe des Speicherdatenträgers überdenken. Sie können Azure Monitor verwenden, um diese Metriken zu sammeln und zu visualisieren und Warnungen einzurichten, um Sie über Leistungsprobleme zu informieren.

Weitere Informationen finden Sie unter Überwachen von Azure Kubernetes Service (AKS) mit Azure Monitor.

Testen der AZ-Resilienz

Methode 1: Cordon und Entladen von Knoten in einer einzelnen VZ

Eine Möglichkeit zum Testen Ihres AKS-Clusters auf VZ-Resilienz besteht darin, einen Knoten in einer Zone zu entladen und zu überprüfen, ob sich dies auf den Datenverkehr auswirkt, bis ein Failover zu einer anderen Zone erfolgt. Diese Methode simuliert ein reales Szenario, in dem eine gesamte Zone aufgrund einer Katastrophe oder eines Ausfalls nicht verfügbar ist. Zum Testen dieses Szenarios können Sie mit dem Befehl kubectl drain alle Pods von einem Knoten ordnungsgemäß entfernen und als nicht geplant markieren. Anschließend können Sie den Clusterdatenverkehr und die Leistung mithilfe von Tools wie Azure Monitor oder Prometheus überwachen.

In der folgenden Tabelle sind die Vor- und Nachteile dieser Methode aufgeführt:

Methode 2: Simulieren eines AZ-Ausfalls mithilfe von Azure Chaos Studio

Eine weitere Möglichkeit zum Testen Ihres AKS-Clusters für AZ-Resilienz besteht darin, Fehler in Ihren Cluster einzufügen und die Auswirkungen auf Ihre Anwendung mithilfe von Azure Chaos Studio zu beobachten. Azure Chaos Studio ist ein Dienst, mit dem Sie Chaosexperimente für Azure-Ressourcen und -Dienste erstellen und verwalten können. Sie können Chaos Studio verwenden, um einen AZ-Ausfall zu simulieren, indem Sie ein Fehlereinfügungsexperiment erstellen, das auf eine bestimmte Zone abzielt und die virtuellen Computer (VMs) in dieser Zone stoppt oder neu startet. Anschließend können Sie die Verfügbarkeit, Latenz und Fehlerrate Ihrer Anwendung mithilfe von Metriken und Protokollen messen.

In der folgenden Tabelle sind die Vor- und Nachteile dieser Methode aufgeführt:

Weitere Informationen finden Sie unter Was ist Azure Chaos Studio?.

Verwandte Inhalte

• Was ist AKS Automatic?
• Leitfaden zu zonenredundanten AKS-Clustern und Speicher