Empfehlungen zur Zonenresilienz für Azure Kubernetes Service (AKS)

Die Zonenresilienz ist ein wichtiger Bestandteil der Ausführung von Kubernetes-Clustern auf Produktionsniveau. 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.

Von Bedeutung

Das Skalieren eines Clusters in und aus, indem Knoten hinzugefügt oder entfernt werden, reicht nicht aus, um die Ausfallsicherheit der Anwendung sicherzustellen. Sie müssen ein tieferes Verständnis Ihrer Anwendung und ihrer Abhängigkeiten gewinnen, um Resilienz besser planen zu können. Mit AKS können Sie Verfügbarkeitszonen (AZs) für Ihre Cluster und Knotenpools einrichten, um sicherzustellen, dass Ihre Anwendungen ausfallsicher gegenüber Fehlern sind und weiterhin Datenverkehr bereitstellen können, auch wenn eine gesamte Zone ausfällt. Weitere Informationen zur Unterstützung von Verfügbarkeitszonenfeatures in AKS finden Sie unter Zuverlässigkeit in Azure Kubernetes Service (AKS).For more information on availability zone support features in AKS, see Reliability in Azure Kubernetes Service (AKS)

In diesem Artikel erfahren Sie mehr über die verschiedenen Empfehlungen für die Zonenresilienz in Azure Kubernetes Service (AKS), einschließlich der Folgenden:

Gestalten zonenresilienter AKS-Clusterkomponenten
Entwerfen einer zustandslosen Anwendung
Treffen der Entscheidung über den Speicherdatenträger
Testen auf Resilienz der Verfügbarkeitszone (AZ)

Gestalten zonenresilienter AKS-Clusterkomponenten

In den folgenden Abschnitten finden Sie Anleitungen zu wichtigen Entscheidungspunkten für die Ausfallsicherheit Ihrer AKS-Clusterkomponenten. Allerdings sind sie nicht vollständig. Sie sollten andere Faktoren basierend auf Ihren spezifischen Anforderungen und Einschränkungen berücksichtigen und Ihre anderen Abhängigkeiten überprüfen, um eine Konfiguration für Zonenresilienz sicherzustellen.

Erstellen von redundanten Zonenclustern und Knotenpools

Mit AKS können Sie während der Erstellung von Cluster- und Knotenpools mehrere AZs auswählen. Wenn Sie einen Cluster in einer Region mit mehreren AZs erstellen, wird die Steuerebene automatisch über alle AZs in dieser Region verteilt. Die Knoten im Knotenpool werden jedoch nur über die ausgewählten AZs 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. Sie können AZs mithilfe der Azure-Portal-, Azure CLI- oder Azure Resource Manager-Vorlagen konfigurieren.

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, dass Pods über AZs verteilt sind

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

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

Diese Konfiguration unterscheidet sich von der Upstream-Standardeinstellung, da nicht auf mehrere Podunterschiede zwischen Zonen abgezielt wird. Daher werden Pods gleichmäßiger über Zonen verteilt, wodurch die Wahrscheinlichkeit verringert wird, dass ein Zonenausfall zu einem Ausfall der entsprechenden Bereitstellung führt.

Wenn Ihr Deployment jedoch spezielle Topologieanforderungen hat, können Sie die oben genannten Standardwerte außer Kraft setzen, indem Sie Ihre eigenen Werte in der Pod-Spezifikation hinzufügen. Sie können Pod-Topologieverbreitungsbeschränkungen basierend auf den zone und hostname Labels 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

Hinweis

Wenn Ihre Anwendung strenge Anforderungen an die Zonenausbreitung hat, wobei erwartet wird, dass ein Pod im ausstehenden Zustand verbleibt, falls kein geeigneter Knoten gefunden wird, können Sie whenUnsatisfiable: DoNotSchedule verwenden. Diese Konfiguration weist den Planer an, den Pod in Wartestellung zu lassen, falls ein Knoten in der richtigen Zone oder ein anderer Host nicht existiert oder nicht skaliert werden kann.

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 verfügen, die Netzwerkdatenverkehr bereitstellen, sollten Sie den Datenverkehr über mehrere AZs hinweg laden, um sicherzustellen, dass Ihre Anwendung hoch verfügbar und widerstandsfähig 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 Falle eines Zonenfehlerszenarios wird ein zonenredundanter Standard-SKU-Lastenausgleich 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 eine bessere Resilienz, Skalierbarkeit und Verfügbarkeit für die Gateways des virtuellen Netzwerks zu erzielen. Weitere Informationen finden Sie unter Erstellen zonenredundanter Gateways für das virtuelle Netzwerk in Verfügbarkeitszonen.
Azure Application Gateway v2: Azure Application Gateway bietet ein regionales L7-Lastenausgleichsmodul mit Unterstützung der Verfügbarkeitszone. Weitere Informationen finden Sie unter Weiterleiten von Webdatenverkehr per Azure Application Gateway.
Azure Front Door: Azure Front Door bietet einen globalen L7-Lastenausgleich und nutzt Anwesenheitspunkte (POPs) oder Azure Content Delivery Network (CDN). Weitere Informationen finden Sie unter Azure Front Door-POP-Standorte.

Von Bedeutung

Mit Azure NAT Gateway können Sie NAT Gateways in bestimmten AZs erstellen oder eine zonale Bereitstellung für die Isolierung für bestimmte Zonen verwenden. NAT Gateway unterstützt zonale Bereitstellungen, aber keine zonenredundanten Bereitstellungen. Dies kann ein Problem sein, wenn Sie einen AKS-Cluster mit dem ausgehenden Typ des NAT-Gateways konfigurieren und das NAT-Gateway sich in einer einzelnen Zone befindet. Wenn in diesem Fall die Zone, in der Ihr NAT-Gateway gehostet wird, abläuft, verliert Ihr Cluster die ausgehende Konnektivität. Weitere Informationen finden Sie unter NAT Gateway und Verfügbarkeitszonen.

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 stellt mehrere Redundanzebenen bereit, um sicherzustellen, dass Ihre Schlüssel und geheimen Schlüssel für Ihre Anwendung verfügbar bleiben, auch wenn einzelne Komponenten des Diensts fehlschlagen oder Azure-Regionen oder AZs nicht verfügbar sind. Weitere Informationen finden Sie unter Azure Key Vault: Verfügbarkeit und Redundanz.

Nutzen der 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 automatische Clusterskalierung passt die Anzahl der Knoten in einem Knotenpool basierend auf den Ressourcenanforderungen der auf den Knoten ausgeführten Pods automatisch an. Wenn Sie beide automatischen Skalierungen zusammen verwenden möchten, stellen Sie sicher, dass die Knotenpools mit aktivierter Autoskalierung mehrere Zonen umfassen. Wenn sich der Knotenpool in einer einzelnen Zone befindet und diese Zone abläuft, kann der Autoscaler den Cluster nicht über Zonen hinweg skalieren.

Die Previewfunktion von 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).

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. Zustandslose Anwendungen sind widerstandsfähiger gegenüber Ausfällen, da sie im Falle eines Knotenausfalls problemlos ersetzt oder neu geplant werden können.

Beim Entwerfen einer zustandslosen Anwendung mit AKS sollten Sie verwaltete Azure-Dienste wie Azure Databases, Azure Cache for Redisoder 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 zustandslose 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). LRS repliziert Ihre Daten in einer einzigen AZ. 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:

Datenträgertyp	Vorteile	Nachteile
LRS	* Niedrigere Kosten * Unterstützt für alle Datenträgergrößen und Regionen * Einfach zu bedienen und einzurichten	* Geringere Verfügbarkeit und Haltbarkeit * Anfällig für Bereichsausfälle * Unterstützt keine Zone oder Georeplikation
ZRS	* Höhere Verfügbarkeit und Haltbarkeit * Widerstandsfähiger gegen Ausfälle in Zonen * Unterstützt die Zonenreplikation für die Resilienz innerhalb der Region	* Höhere Kosten * Nicht unterstützt für alle Datenträgergrößen und Regionen * Erfordert zusätzliche Konfiguration zum Aktivieren

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 Ausgleichsknoten in einem einzigen AZ

Eine Möglichkeit zum Testen Ihres AKS-Clusters auf AZ-Resilienz besteht darin, einen Knoten in einer Zone abzugleichen und zu sehen, wie sich das auf den Datenverkehr auswirkt, bis ein Failover zu einer anderen Zone stattfindet. 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 den Befehl kubectl drain verwenden, um alle Pods von einem Knoten ordnungsgemäß zu entfernen und als nicht geplant zu 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:

Vorteile	Nachteile
* Imitiert ein realistisches Fehlerszenario und testet den Wiederherstellungsvorgang. * Ermöglicht Es Ihnen, die Verfügbarkeit und Haltbarkeit Ihrer Daten in allen Regionen zu überprüfen. * Hilft Ihnen, potenzielle Probleme oder Engpässe in Ihrer Clusterkonfiguration oder anwendungsdesign zu erkennen.	* Kann vorübergehende Unterbrechungen oder Beeinträchtigung des Dienstes für Ihre Benutzer verursachen * Erfordert manuelle Eingriffe und Koordination, um den Knoten zu entwässern und wiederherzustellen * Möglicherweise entstehen zusätzliche Kosten aufgrund erhöhter Netzwerkdatenverkehr oder Speicherreplikation

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.