Hochverfügbarkeit für AKS-Anwendungen mit mehreren Ebenen

Azure Cosmos DB

Azure Disk Storage

Azure Files

Azure Kubernetes Service (AKS)

Azure-Lastenausgleich

In diesem Leitfaden wird die Hochverfügbarkeit (High Availability, HA) für die Bereitstellung von Anwendungen mit mehreren Ebenen in Azure Kubernetes Service-Clustern (AKS-Clustern) erläutert. Der Artikel beschreibt Hochverfügbarkeitsmechanismen und -Konstrukte in Kubernetes und stellt eine Checkliste und Richtlinien bereit, um Single Points of Failure für Hochverfügbarkeit zu identifizieren und zu beseitigen.

Bei der Implementierung von Hochverfügbarkeit für AKS-Anwendungen sind zwei grundlegende Aufgaben zu beachten.

• Identifizieren aller Single Points of Failure in der Anwendung.
• Beseitigen der Single Points of Failure.

Das Beseitigen der Single Points of Failure erfordert eine Hochverfügbarkeitslösung.

Die vier Säulen der Hochverfügbarkeit

Vier Säulen der Hochverfügbarkeit sind Teil jedes hochverfügbaren Systems:

• Redundanz
• Überwachung
• Wiederherstellung
• Setzen von Prüfpunkten

Denken Sie beispielsweise an eine AKS-Anwendung mit mehreren Ebenen, bei der Datenverkehr zur Geschäftslogikebene gelangt. Die Datenebene behält den Status bei und die Anwendung gibt Antworten an Benutzer zurück.

Single Points of Failure erkennen

Um Single Points of Failure zu erkennen, bestimmen Sie zunächst den kritischen Pfad zwischen Clientanforderungen und den Komponenten, die diese Anforderungen erfüllen. Jede Komponente auf diesem Pfad, die nicht den vier Säulen der Hochverfügbarkeit entsprechend verwaltet wird (drei Säulen, wenn es sich um eine zustandslose Komponente ohne Prüfpunkte handelt), ist ein Single Point of Failure. Selbst eine replizierte Komponente wird als ein Single Point of Failure betrachtet, wenn sie nicht überwacht wird, da ein Fehler nicht erkannt würde.

Die Beseitigung eines Single Point of Failure

Um einzelne Fehlerpunkte zu beseitigen, stellen Sie Ihre Anwendung bereit, replizieren dabei kritische Pfadkomponenten und verwenden Lastenausgleichsmechanismen, Überwachung sowie Wiederherstellungsmechanismen. Kubernetes kann all diese Aktivitäten ausführen.

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

In einer replizierten Anwendung:

• Sie replizieren die Komponenten der Geschäftsebene mit unterschiedlich vielen Replikaten pro Komponente, je nach Leistung und Workload.
• Sie replizieren auch die Datenebene hinter einem Lastenausgleich.

Kubernetes bietet verschiedene Konstrukte und Mechanismen wie Lastenausgleiche und Livetests, die bei der Implementierung der Säulen der Hochverfügbarkeit helfen. Die folgende Checkliste und Diskussion teilen diese Konstrukte und Mechanismen in Kategorien auf, die den vier Säulen der Hochverfügbarkeit zugeordnet sind.

Die Kubernetes Hochverfügbarkeitscheckliste

Neben der Zustandsverwaltung eignet sich Kubernetes hervorragend für die Aufrechterhaltung der Hochverfügbarkeit einer Anwendung. Die Hochverfügbarkeitscheckliste enthält allgemeine Konfigurationen für die Optimierung der Hochverfügbarkeitsverwaltung durch Kubernetes. Um die Checkliste zu verwenden, bewerten Sie Ihre Kubernetes-Bereitstellung anhand der folgenden Mechanismen und Konstrukte und implementieren die fehlenden Mechanismen und Konstrukte.

Säule der Hochverfügbarkeit	Lösung
Redundanz	☐ Kubernetes-Controllertyp ☐ Anzahl von Replikaten ☐ Planen von Anti-Affinität
Überwachung	☐ Livetests ☐ Bereitschaftstests ☐ Starttests
Wiederherstellung	☐ Diensttyp ☐ Auswahl einer übergeordneten Instanz ☐ Neustartrichtlinie ☐ Vorstopp-Hooks
Setzen von Prüfpunkten	☐ Ansprüche auf persistente Volumes ☐ Persistente Volumes

Redundanz

Redundanz vermeidet einen Single Point of Failure. Sie benötigen Redundanz auf allen Ebenen einer Anwendung. Um Redundanz zu erreichen, müssen Sie eine Komponente einer bestimmten Ebene ein- oder mehrfach identisch replizieren.

• Controllertyp, Konfiguration kind: Deployment. Kubernetes bietet mehrere Controller für die Verwaltung des Lebenszyklus des Pods Ihrer Anwendung. Der verbreitetste Controller ist Deployment. Zu den anderen Controllern gehört Statefulset, welcher sich besonders dafür eignet, die Pod-Identität nach einer Wiederherstellung aufrechtzuerhalten. Andere Controller wie z. B. Replicasets bieten nicht den gleichen Umfang nützlicher Funktionen wie Rollbacks, den die Bereitstellung anbietet.

• Anzahl der Replikate, Konfiguration spec.replicas. Die Bewusste Entscheidung für nur ein Replikat dient dazu, ein verzögert betriebsbereites Modell zu verwenden. Die verzögerte Betriebsbereitschaft bedeutet, dass beim Auftreten eines Fehlers eine von Grund auf neue Instanz beginnt, was sich auf die Verfügbarkeit auswirkt. Dieses Modell kann für Komponenten mit geringem Workload-Volumen funktionieren, Sie sollten jedoch die Replikation zustandsloser Komponenten mit hohem Volumen in Betracht ziehen.

  Durch Angeben der Ressourcenanforderungsgrenzwerte, spec.containers[].resources, können Sie horizontale automatische Podskalierung (HPA) hinzufügen, wodurch Kubernetes die Anzahl der Replikate automatisch anhand der von Ihnen definierten Ressourcenverwendungsschwellenwerte nach oben oder unten skalieren kann. HPA verhindert, dass Ihre Anwendung Anforderungen aufgrund einer Überlastung durch einen Anstieg der Auslastung nicht mehr verarbeiten kann.

• Planen von Anti-Affinität, Konfiguration spec.affinity.podAntiAffinity. Ein typischer Kubernetes-Cluster auf Produktionsebene verfügt über Knoten, die auf mehrere Verfügbarkeitszonen verteilt sind, dies wird über eine topologyKey ausgedrückt. Pods derselben Bereitstellung sollten einander gegenüber eine bevorzugte oder weiche Anti-Affinität aufweisen. Diese Konfiguration stellt sicher, dass die Pods auf Knoten in verschiedenen Verfügbarkeitszonen geplant werden.

  Ein AKS-Cluster kann mehrere Knotenpools mit jeweils unterschiedlichen VM-Skalierungsgruppengrößen und -spezifikationen aufweisen. Sie können beispielsweise Ihre Datenbank-Pods auf Knoten mit schnellen SSD-Datenträgern hosten und Ihre ML-Pods auf Knoten mit Grafikprozessoren (GPUs) hosten.

Überwachung

Ohne Überwachung kann Redundanz ihre Wirkung verlieren. Sie benötigen einen konstanten Überwachungsmechanismus, um sicherzustellen, dass Workloads an ein fehlerfreies Replikat weitergegeben werden.

• Livetests, Konfiguration spec.containers.livenessProbe, Überwachen der Integrität Ihrer Pods. Wenn ein Container abstürzt oder beendet wird, kann Kubernetes dies erkennen. Wenn ein Livetest fehlschlägt, startet Kubernetes den Container neu.

• Bereitschaftstests, Konfiguration spec.containers.readinessProbe, bestimmen, ob Datenverkehr an den Pod gesendet werden soll. Wenn Pods einer Bereitstellung nicht bereit sind, sind sie nicht Teil der Endpunkte des Kubernetes-Diensts, der die Bereitstellung abstrahiert, und daher nicht nützlich. Es ist wichtig, die Bereitschaftstests sorgfältig festzulegen, da sie keinen Neustart auslösen, sondern dafür sorgen, dass Pods keinen Datenverkehrs erhalten, bis sie dafür bereit sind.

• Starttests, Konfiguration spec.containers.startupProbe, verhindern vornehmlich falsch positive Ergebnisse für Bereitschafts- und Livetests bei langsam startenden Anwendungen. Sobald der Starttest erfolgreich war, wird ein Livetest gestartet.

Azure ermöglicht tiefere Einblicke, mit denen Sie Warnungen auf Basis Ihrer Clusterintegrität festlegen können.

Wiederherstellung

Der Hauptzweck der Überwachung besteht darin, die Wiederherstellung auszulösen, wenn ein Fehler erkannt wird. Ein Wiederherstellungsvorgang besteht aus drei Phasen:

1. Isolieren und Umleiten: Sorgt dafür, dass das fehlerhafte Replikat keinen Datenverkehr empfängt, und leitet Workloads auf fehlerfreie Replikate weiter.
2. Reparatur: Startet das fehlerhafte Replikat neu, wodurch vorübergehende Fehler behoben werden können.
3. Neuverbindung: Wenn die Überwachung das Replikat als fehlerfrei erachtet, kann das Replikat erneut mit anderen Replikaten für die Verarbeitung von Workloads verbunden werden.

• Diensttyp, Konfiguration spec.type. Das Verfügbarmachen von Pods über einen Dienst kann sowohl der Redundanz als auch der Wiederherstellung zugerechnet werden. In manchen Fällen liegt jedoch möglicherweise eine Einzelreplikatbereitstellung vor. Die Verfügbarmachung der Pods über einen Dienst bietet weiterhin Vorteile, auch wenn kein Lastenausgleich stattfindet.

  Der Hauptvorteil des Diensts besteht darin, dass DNS-Einträge (Domain Name Service) automatisch auf den Kubernetes-Dienstendpunkten aktualisiert werden. Ein Pod mit Containern, bei denen Bereitschaftstests fehlschlagen, empfängt keinen Datenverkehr über AKS. Die Lastenausgleichsfähigkeit von Kubernetes-Cluster-IP-Diensten ist zwar rudimentär, erlaubt aber dennoch die Kopplung eines monitorlosen Diensts mit eingehenden oder anderen Dienstnetzlösungen, um die Lastenverteilung zu verbessern.

  Wie der externe Datenverkehr Ihren AKS-Cluster erreicht, liegt außerhalb des Funktionsumfangs von Kubernetes. Sie können externen Datenverkehr mit Diensten wie Azure Application Gateway verwalten.

• Auswahl einer übergeordneten Instanz. Einige Komponenten werden am besten als Singletons bereitgestellt. Der Zeitplaner ist eine solche Komponente, da zwei aktive Zeitplaner Konflikte verursachen können. Singleton-Anwendungen sind anfällig für Probleme bei verzögerter Betriebsbereitschaft. Um den Betriebsbereitschaftsmodus eines Pods zu aktivieren, können Sie die Auswahl einer übergeordneten Instanz verwenden, wobei nur ein Pod, die übergeordnete Instanz, Anforderungen verarbeitet.

• Neustartrichtlinie, Konfiguration spec.restartPolicy. Die Neustartrichtlinie gilt für alle Container im Pod. Es sollte einen triftigen Grund für das Festlegen dieses Attributs auf Never geben. Einige Container nehmen bei jedem Start Kontakt mit einem Lizenzserver auf, Möglicherweise möchten Sie die zusätzlichen Kosten für übermäßige Neustarts vermeiden.

• Vorstopp-Hooks, Konfiguration spec.containers.lifecycle.preStop. Vorstopp-Hooks werden ausgeführt, bevor ein SIGTERM-Signal an den Container gesendet wird. Ein Vorstopp-Skript kann einfach aus einem Befehl für einen Ruhezustand mit einer Dauer von 30 Sekunden bestehen.

  Wenn z. B. eine von einer HPA verwaltete Anwendung herunterskaliert wird, werden laufende Anforderungen möglicherweise plötzlich beendet, sofern die Anwendung nicht über einen SIGTERM-Handler verfügt, der dafür sorgt, dass Anforderungen vor dem Beenden abgeschlossen werden. Ein Vorstopp-Hook entfernt den Podendpunkt und somit den DNS-Eintrag vom Dienstendpunkt. Wenn der Vorstopp-Hook ausgeführt wird, können keine neuen Anforderungen an den Pod gesendet werden. Der Vorstopp-Hook ermöglicht es dem Pod, die Verarbeitung seiner laufenden Anforderungen abzuschließen, ohne neue zu empfangen. Vorstopp-Hooks sind eine einfache Möglichkeit, den Verlust von Anforderungen zu minimieren, ohne Anwendungscode zu ändern.

Setzen von Prüfpunkten

Moderne Anwendungen verfügen über viele zustandslose Komponenten, vollständig zustandslose Anwendungen sind jedoch immer noch selten. Die meisten Anwendungen überprüfen ihren Zustand auf der Datenebene. Kubernetes bietet bewusst keinen Mechanismus für die Verarbeitung des Anwendungszustands. Die Zustandsverwaltung ist eine komplexe Aufgabe, die nicht Teil der Containerverwaltung ist.

Sie können den Anwendungszustand auf drei Ebenen beibehalten:

• Die Datensatzebene speichert die Daten in einer Datenbank. Jeder Datenbankdatensatz kann über mehrere Datenbankinstanzen repliziert werden. Datenbankdatensätze sind die vorherrschende Form der Zustandspersistenz, insbesondere in verwalteten Clouddatenbanken wie Azure Cosmos DB.

• Die Dateisystemebene repliziert in der Regel Datendateien, z. B. WAL-Dateien (Write-Ahead Logging). Die meisten Cloudanbieter bieten Plugins für ihre Lösungen an, z. B. Azure Files.

• Die Datenträgerebene speichert Daten auf Blockebene, was Flexibilität für die Definition des zu verwendenden Dateisystems wie bietet, z. B. Azure Disk Storage.

Kubernetes-Volumes, persistente Volumes und persistente Volumeansprüche können den Status der Anwendung auf Dateisystem- oder Datenträgerebene beibehalten. Das häufigste Muster zum Speichern des Zustands ist nach wie vor die Datensatzebene.

HA und DR

Sowohl bei Hochverfügbarkeit als auch Notfallwiederherstellung (Disaster Recovery, DR) ist die Wahl der Netzwerktopologie und Lastenausgleichslösungen wichtig.

DR erfordert jedoch die multiregionale Bereitstellung von Diensten auf der gesamten Dienstebene mit Lastenausgleichslösungen zwischen Azure-Regionen. Die Anwendung wird entweder auf mehrere Regionen aufgeteilt oder es wird eine vollständige Anwendungsinstanz in jeder Region bereitgestellt. Diese Entscheidung hängt von Anwendungstyp, Anwendungsarchitektur und Latenztoleranz zwischen Komponenten ab.

Anstatt mehrere Regionen zu verwenden, profitiert Hochverfügbarkeit von Mehrzonen-Bereitstellungen in Azure-Regionen. Das folgende Diagramm veranschaulicht den Unterschied zwischen Verfügbarkeitszonen und Regionen für Hochverfügbarkeit und DR.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Schwerpunkt dieses Leitfadens liegt auf Hochverfügbarkeit auf Anwendungsebene innerhalb eines AKS-Clusters. Weitere Informationen zu DR in AKS-Multiclusterbereitstellungen finden Sie unter AKS-Baseline für Cluster in mehreren Regionen.

Weitere Überlegungen

• Stellen Sie sicher, dass Ihre Kubernetes-Steuerungsebene, einschließlich des API-Servers und Controller-Managers, hochverfügbar ist, um die Hochverfügbarkeit der Anwendung zu gewährleisten. Sie können eine AKS Uptime-SLA verwenden, um Hochverfügbarkeit zu gewährleisten.

• Eine Strategie zur Ressourcenkonsolidierung verstößt direkt gegen die Redundanzsäule der Hochverfügbarkeit. Daher sollten Sie die Kosten für die Redundanz sorgfältig bedenken. Der Azure-Preisrechner kann Ihnen dabei helfen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Ali Kanso | Leitender Softwareentwickler

Andere Mitwirkende:

• Karthik Sankara Subramanian | Software-Ingenieur II
• Kinshuman Patra | Partner Group Engineering Manager
• Ayobami Ayodeji | Leitender Programmmanager
• Oscar L Pla Alvarez | Architekt für Domain-Lösungen

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Muster für Kubernetes-Cluster mit Hochverfügbarkeit
• Regionen und Verfügbarkeitszonen
• Kontingente, Größeneinschränkungen für virtuelle Computer und regionale Verfügbarkeit in Azure Kubernetes Service (AKS)
• Orchestrieren von Microservices und Anwendungen mit mehreren Containern für hohe Skalierbarkeit und Verfügbarkeit
• Azure Kubernetes Service-Clusterarchitektur und -vorgänge (AKS)

Zugehörige Ressourcen

• AKS-Baseline für Cluster in mehreren Regionen
• Microservicearchitektur in Azure Kubernetes Service
• Azure Well-Architected Framework-Bewertung – Azure Kubernetes Service (AKS)

In diesem Leitfaden wird die Hochverfügbarkeit (High Availability, HA) für die Bereitstellung von Anwendungen mit mehreren Ebenen in Azure Kubernetes Service-Clustern (AKS-Clustern) erläutert. Der Artikel beschreibt Hochverfügbarkeitsmechanismen und -Konstrukte in Kubernetes und stellt eine Checkliste und Richtlinien bereit, um Single Points of Failure für Hochverfügbarkeit zu identifizieren und zu beseitigen.

Bei der Implementierung von Hochverfügbarkeit für AKS-Anwendungen sind zwei grundlegende Aufgaben zu beachten.

• Identifizieren aller Single Points of Failure in der Anwendung.
• Beseitigen der Single Points of Failure.

Das Beseitigen der Single Points of Failure erfordert eine Hochverfügbarkeitslösung.

Die vier Säulen der Hochverfügbarkeit

Vier Säulen der Hochverfügbarkeit sind Teil jedes hochverfügbaren Systems:

• Redundanz
• Überwachung
• Wiederherstellung
• Setzen von Prüfpunkten

Denken Sie beispielsweise an eine AKS-Anwendung mit mehreren Ebenen, bei der Datenverkehr zur Geschäftslogikebene gelangt. Die Datenebene behält den Status bei und die Anwendung gibt Antworten an Benutzer zurück.

Single Points of Failure erkennen

Um Single Points of Failure zu erkennen, bestimmen Sie zunächst den kritischen Pfad zwischen Clientanforderungen und den Komponenten, die diese Anforderungen erfüllen. Jede Komponente auf diesem Pfad, die nicht den vier Säulen der Hochverfügbarkeit entsprechend verwaltet wird (drei Säulen, wenn es sich um eine zustandslose Komponente ohne Prüfpunkte handelt), ist ein Single Point of Failure. Selbst eine replizierte Komponente wird als ein Single Point of Failure betrachtet, wenn sie nicht überwacht wird, da ein Fehler nicht erkannt würde.

Die Beseitigung eines Single Point of Failure

Um einzelne Fehlerpunkte zu beseitigen, stellen Sie Ihre Anwendung bereit, replizieren dabei kritische Pfadkomponenten und verwenden Lastenausgleichsmechanismen, Überwachung sowie Wiederherstellungsmechanismen. Kubernetes kann all diese Aktivitäten ausführen.

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

In einer replizierten Anwendung:

• Sie replizieren die Komponenten der Geschäftsebene mit unterschiedlich vielen Replikaten pro Komponente, je nach Leistung und Workload.
• Sie replizieren auch die Datenebene hinter einem Lastenausgleich.

Kubernetes bietet verschiedene Konstrukte und Mechanismen wie Lastenausgleiche und Livetests, die bei der Implementierung der Säulen der Hochverfügbarkeit helfen. Die folgende Checkliste und Diskussion teilen diese Konstrukte und Mechanismen in Kategorien auf, die den vier Säulen der Hochverfügbarkeit zugeordnet sind.

Die Kubernetes Hochverfügbarkeitscheckliste

Neben der Zustandsverwaltung eignet sich Kubernetes hervorragend für die Aufrechterhaltung der Hochverfügbarkeit einer Anwendung. Die Hochverfügbarkeitscheckliste enthält allgemeine Konfigurationen für die Optimierung der Hochverfügbarkeitsverwaltung durch Kubernetes. Um die Checkliste zu verwenden, bewerten Sie Ihre Kubernetes-Bereitstellung anhand der folgenden Mechanismen und Konstrukte und implementieren die fehlenden Mechanismen und Konstrukte.

Säule der Hochverfügbarkeit	Lösung
Redundanz	☐ Kubernetes-Controllertyp ☐ Anzahl von Replikaten ☐ Planen von Anti-Affinität
Überwachung	☐ Livetests ☐ Bereitschaftstests ☐ Starttests
Wiederherstellung	☐ Diensttyp ☐ Auswahl einer übergeordneten Instanz ☐ Neustartrichtlinie ☐ Vorstopp-Hooks
Setzen von Prüfpunkten	☐ Ansprüche auf persistente Volumes ☐ Persistente Volumes

Redundanz

Redundanz vermeidet einen Single Point of Failure. Sie benötigen Redundanz auf allen Ebenen einer Anwendung. Um Redundanz zu erreichen, müssen Sie eine Komponente einer bestimmten Ebene ein- oder mehrfach identisch replizieren.

• Controllertyp, Konfiguration kind: Deployment. Kubernetes bietet mehrere Controller für die Verwaltung des Lebenszyklus des Pods Ihrer Anwendung. Der verbreitetste Controller ist Deployment. Zu den anderen Controllern gehört Statefulset, welcher sich besonders dafür eignet, die Pod-Identität nach einer Wiederherstellung aufrechtzuerhalten. Andere Controller wie z. B. Replicasets bieten nicht den gleichen Umfang nützlicher Funktionen wie Rollbacks, den die Bereitstellung anbietet.

• Anzahl der Replikate, Konfiguration spec.replicas. Die Bewusste Entscheidung für nur ein Replikat dient dazu, ein verzögert betriebsbereites Modell zu verwenden. Die verzögerte Betriebsbereitschaft bedeutet, dass beim Auftreten eines Fehlers eine von Grund auf neue Instanz beginnt, was sich auf die Verfügbarkeit auswirkt. Dieses Modell kann für Komponenten mit geringem Workload-Volumen funktionieren, Sie sollten jedoch die Replikation zustandsloser Komponenten mit hohem Volumen in Betracht ziehen.

  Durch Angeben der Ressourcenanforderungsgrenzwerte, spec.containers[].resources, können Sie horizontale automatische Podskalierung (HPA) hinzufügen, wodurch Kubernetes die Anzahl der Replikate automatisch anhand der von Ihnen definierten Ressourcenverwendungsschwellenwerte nach oben oder unten skalieren kann. HPA verhindert, dass Ihre Anwendung Anforderungen aufgrund einer Überlastung durch einen Anstieg der Auslastung nicht mehr verarbeiten kann.

• Planen von Anti-Affinität, Konfiguration spec.affinity.podAntiAffinity. Ein typischer Kubernetes-Cluster auf Produktionsebene verfügt über Knoten, die auf mehrere Verfügbarkeitszonen verteilt sind, dies wird über eine topologyKey ausgedrückt. Pods derselben Bereitstellung sollten einander gegenüber eine bevorzugte oder weiche Anti-Affinität aufweisen. Diese Konfiguration stellt sicher, dass die Pods auf Knoten in verschiedenen Verfügbarkeitszonen geplant werden.

  Ein AKS-Cluster kann mehrere Knotenpools mit jeweils unterschiedlichen VM-Skalierungsgruppengrößen und -spezifikationen aufweisen. Sie können beispielsweise Ihre Datenbank-Pods auf Knoten mit schnellen SSD-Datenträgern hosten und Ihre ML-Pods auf Knoten mit Grafikprozessoren (GPUs) hosten.

Überwachung

Ohne Überwachung kann Redundanz ihre Wirkung verlieren. Sie benötigen einen konstanten Überwachungsmechanismus, um sicherzustellen, dass Workloads an ein fehlerfreies Replikat weitergegeben werden.

• Livetests, Konfiguration spec.containers.livenessProbe, Überwachen der Integrität Ihrer Pods. Wenn ein Container abstürzt oder beendet wird, kann Kubernetes dies erkennen. Wenn ein Livetest fehlschlägt, startet Kubernetes den Container neu.

• Bereitschaftstests, Konfiguration spec.containers.readinessProbe, bestimmen, ob Datenverkehr an den Pod gesendet werden soll. Wenn Pods einer Bereitstellung nicht bereit sind, sind sie nicht Teil der Endpunkte des Kubernetes-Diensts, der die Bereitstellung abstrahiert, und daher nicht nützlich. Es ist wichtig, die Bereitschaftstests sorgfältig festzulegen, da sie keinen Neustart auslösen, sondern dafür sorgen, dass Pods keinen Datenverkehrs erhalten, bis sie dafür bereit sind.

• Starttests, Konfiguration spec.containers.startupProbe, verhindern vornehmlich falsch positive Ergebnisse für Bereitschafts- und Livetests bei langsam startenden Anwendungen. Sobald der Starttest erfolgreich war, wird ein Livetest gestartet.

Azure ermöglicht tiefere Einblicke, mit denen Sie Warnungen auf Basis Ihrer Clusterintegrität festlegen können.

Wiederherstellung

Der Hauptzweck der Überwachung besteht darin, die Wiederherstellung auszulösen, wenn ein Fehler erkannt wird. Ein Wiederherstellungsvorgang besteht aus drei Phasen:

1. Isolieren und Umleiten: Sorgt dafür, dass das fehlerhafte Replikat keinen Datenverkehr empfängt, und leitet Workloads auf fehlerfreie Replikate weiter.
2. Reparatur: Startet das fehlerhafte Replikat neu, wodurch vorübergehende Fehler behoben werden können.
3. Neuverbindung: Wenn die Überwachung das Replikat als fehlerfrei erachtet, kann das Replikat erneut mit anderen Replikaten für die Verarbeitung von Workloads verbunden werden.

• Diensttyp, Konfiguration spec.type. Das Verfügbarmachen von Pods über einen Dienst kann sowohl der Redundanz als auch der Wiederherstellung zugerechnet werden. In manchen Fällen liegt jedoch möglicherweise eine Einzelreplikatbereitstellung vor. Die Verfügbarmachung der Pods über einen Dienst bietet weiterhin Vorteile, auch wenn kein Lastenausgleich stattfindet.

  Der Hauptvorteil des Diensts besteht darin, dass DNS-Einträge (Domain Name Service) automatisch auf den Kubernetes-Dienstendpunkten aktualisiert werden. Ein Pod mit Containern, bei denen Bereitschaftstests fehlschlagen, empfängt keinen Datenverkehr über AKS. Die Lastenausgleichsfähigkeit von Kubernetes-Cluster-IP-Diensten ist zwar rudimentär, erlaubt aber dennoch die Kopplung eines monitorlosen Diensts mit eingehenden oder anderen Dienstnetzlösungen, um die Lastenverteilung zu verbessern.

  Wie der externe Datenverkehr Ihren AKS-Cluster erreicht, liegt außerhalb des Funktionsumfangs von Kubernetes. Sie können externen Datenverkehr mit Diensten wie Azure Application Gateway verwalten.

• Auswahl einer übergeordneten Instanz. Einige Komponenten werden am besten als Singletons bereitgestellt. Der Zeitplaner ist eine solche Komponente, da zwei aktive Zeitplaner Konflikte verursachen können. Singleton-Anwendungen sind anfällig für Probleme bei verzögerter Betriebsbereitschaft. Um den Betriebsbereitschaftsmodus eines Pods zu aktivieren, können Sie die Auswahl einer übergeordneten Instanz verwenden, wobei nur ein Pod, die übergeordnete Instanz, Anforderungen verarbeitet.

• Neustartrichtlinie, Konfiguration spec.restartPolicy. Die Neustartrichtlinie gilt für alle Container im Pod. Es sollte einen triftigen Grund für das Festlegen dieses Attributs auf Never geben. Einige Container nehmen bei jedem Start Kontakt mit einem Lizenzserver auf, Möglicherweise möchten Sie die zusätzlichen Kosten für übermäßige Neustarts vermeiden.

• Vorstopp-Hooks, Konfiguration spec.containers.lifecycle.preStop. Vorstopp-Hooks werden ausgeführt, bevor ein SIGTERM-Signal an den Container gesendet wird. Ein Vorstopp-Skript kann einfach aus einem Befehl für einen Ruhezustand mit einer Dauer von 30 Sekunden bestehen.

  Wenn z. B. eine von einer HPA verwaltete Anwendung herunterskaliert wird, werden laufende Anforderungen möglicherweise plötzlich beendet, sofern die Anwendung nicht über einen SIGTERM-Handler verfügt, der dafür sorgt, dass Anforderungen vor dem Beenden abgeschlossen werden. Ein Vorstopp-Hook entfernt den Podendpunkt und somit den DNS-Eintrag vom Dienstendpunkt. Wenn der Vorstopp-Hook ausgeführt wird, können keine neuen Anforderungen an den Pod gesendet werden. Der Vorstopp-Hook ermöglicht es dem Pod, die Verarbeitung seiner laufenden Anforderungen abzuschließen, ohne neue zu empfangen. Vorstopp-Hooks sind eine einfache Möglichkeit, den Verlust von Anforderungen zu minimieren, ohne Anwendungscode zu ändern.

Setzen von Prüfpunkten

Moderne Anwendungen verfügen über viele zustandslose Komponenten, vollständig zustandslose Anwendungen sind jedoch immer noch selten. Die meisten Anwendungen überprüfen ihren Zustand auf der Datenebene. Kubernetes bietet bewusst keinen Mechanismus für die Verarbeitung des Anwendungszustands. Die Zustandsverwaltung ist eine komplexe Aufgabe, die nicht Teil der Containerverwaltung ist.

Sie können den Anwendungszustand auf drei Ebenen beibehalten:

• Die Datensatzebene speichert die Daten in einer Datenbank. Jeder Datenbankdatensatz kann über mehrere Datenbankinstanzen repliziert werden. Datenbankdatensätze sind die vorherrschende Form der Zustandspersistenz, insbesondere in verwalteten Clouddatenbanken wie Azure Cosmos DB.

• Die Dateisystemebene repliziert in der Regel Datendateien, z. B. WAL-Dateien (Write-Ahead Logging). Die meisten Cloudanbieter bieten Plugins für ihre Lösungen an, z. B. Azure Files.

• Die Datenträgerebene speichert Daten auf Blockebene, was Flexibilität für die Definition des zu verwendenden Dateisystems wie bietet, z. B. Azure Disk Storage.

Kubernetes-Volumes, persistente Volumes und persistente Volumeansprüche können den Status der Anwendung auf Dateisystem- oder Datenträgerebene beibehalten. Das häufigste Muster zum Speichern des Zustands ist nach wie vor die Datensatzebene.

HA und DR

Sowohl bei Hochverfügbarkeit als auch Notfallwiederherstellung (Disaster Recovery, DR) ist die Wahl der Netzwerktopologie und Lastenausgleichslösungen wichtig.

DR erfordert jedoch die multiregionale Bereitstellung von Diensten auf der gesamten Dienstebene mit Lastenausgleichslösungen zwischen Azure-Regionen. Die Anwendung wird entweder auf mehrere Regionen aufgeteilt oder es wird eine vollständige Anwendungsinstanz in jeder Region bereitgestellt. Diese Entscheidung hängt von Anwendungstyp, Anwendungsarchitektur und Latenztoleranz zwischen Komponenten ab.

Anstatt mehrere Regionen zu verwenden, profitiert Hochverfügbarkeit von Mehrzonen-Bereitstellungen in Azure-Regionen. Das folgende Diagramm veranschaulicht den Unterschied zwischen Verfügbarkeitszonen und Regionen für Hochverfügbarkeit und DR.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Schwerpunkt dieses Leitfadens liegt auf Hochverfügbarkeit auf Anwendungsebene innerhalb eines AKS-Clusters. Weitere Informationen zu DR in AKS-Multiclusterbereitstellungen finden Sie unter AKS-Baseline für Cluster in mehreren Regionen.

Weitere Überlegungen

• Stellen Sie sicher, dass Ihre Kubernetes-Steuerungsebene, einschließlich des API-Servers und Controller-Managers, hochverfügbar ist, um die Hochverfügbarkeit der Anwendung zu gewährleisten. Sie können eine AKS Uptime-SLA verwenden, um Hochverfügbarkeit zu gewährleisten.

• Eine Strategie zur Ressourcenkonsolidierung verstößt direkt gegen die Redundanzsäule der Hochverfügbarkeit. Daher sollten Sie die Kosten für die Redundanz sorgfältig bedenken. Der Azure-Preisrechner kann Ihnen dabei helfen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Ali Kanso | Leitender Softwareentwickler

Andere Mitwirkende:

• Karthik Sankara Subramanian | Software-Ingenieur II
• Kinshuman Patra | Partner Group Engineering Manager
• Ayobami Ayodeji | Leitender Programmmanager
• Oscar L Pla Alvarez | Architekt für Domain-Lösungen

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Muster für Kubernetes-Cluster mit Hochverfügbarkeit
• Regionen und Verfügbarkeitszonen
• Kontingente, Größeneinschränkungen für virtuelle Computer und regionale Verfügbarkeit in Azure Kubernetes Service (AKS)
• Orchestrieren von Microservices und Anwendungen mit mehreren Containern für hohe Skalierbarkeit und Verfügbarkeit
• Azure Kubernetes Service-Clusterarchitektur und -vorgänge (AKS)

Zugehörige Ressourcen

• AKS-Baseline für Cluster in mehreren Regionen
• Microservicearchitektur in Azure Kubernetes Service
• Azure Well-Architected Framework-Bewertung – Azure Kubernetes Service (AKS)