Hohe Verfügbarkeit für Multitier-AKS-Anwendungen

In diesem Artikel wird die hohe Verfügbarkeit (HIGH Availability, HA) für die Mehrschichtanwendungsbereitstellung in Azure Kubernetes Service (AKS) Clustern erläutert. Es beschreibt Kubernetes HA-Mechanismen und -Konstrukte und bietet eine Checkliste und Richtlinien zur Identifizierung und Beseitigung einzelner Ha-Fehlerpunkte.

Es gibt zwei grundlegende Aufgaben für die Implementierung von HA für AKS-Anwendungen:

  • Identifizieren Sie alle einzelnen Fehlerpunkte in der Anwendung.
  • Beseitigen Sie die einzelnen Fehlerpunkte.

Um einzelne Fehlerpunkte zu beseitigen, benötigen Sie eine HA-Lösung.

Die vier HA-Säulen

In jedem hoch verfügbaren System erscheinen vier HA-Säulen:

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

Betrachten Sie die folgende mehrstufige AKS-Anwendung, bei der Datenverkehr auf der Geschäftslogikebene eingeht, die Datenebene den Zustand behält, und die Anwendung gibt Antworten an Benutzer zurück.

Diagramm, das eine mehrstufige AKS-Anwendung zeigt.

Identifizieren einzelner Fehlerpunkte

Um einzelne Fehlerpunkte zu identifizieren, bestimmen Sie zunächst den kritischen Pfad zwischen Clientanforderungen und den Komponenten, die diese Anforderungen erfüllen. Jede Komponente auf diesem Pfad, die nicht gemäß den vier HA-Säulen verwaltet wird, oder drei Säulen, wenn es sich um eine zustandslose Komponente ohne Prüfpunkt handelt, ist ein einzelner Fehlerpunkt. Selbst eine replizierte Komponente wird als einzelner Fehlerpunkt betrachtet, wenn sie nicht überwacht wird, da der Fehler im Hintergrund nicht erkannt wird.

Beseitigen einzelner Fehlerpunkte

Um einzelne Fehlerpunkte zu beseitigen, stellen Sie Ihre Anwendung bereit, um komponenten für kritische Pfade zu replizieren, und verwenden Sie Lastenausgleichs-, Überwachungs- und Wiederherstellungsmechanismen. Kubernetes können all diese Aktivitäten verarbeiten.

Diagramm, das replizierte Komponenten in einer mehrstufigen AKS-Anwendung zeigt.

Laden Sie eine Visio-Datei dieses Diagramms herunter.

In einer replizierten Anwendung:

  • Sie replizieren die Komponenten der Geschäftsebene mit verschiedenen Replikaten pro Komponente, je nach Leistung und Workload.
  • Sie replizieren auch die Datenschicht hinter einem Load Balancer.

Kubernetes bietet verschiedene Konzepte und Mechanismen wie Lastausgleich und Liveness-Probes, mit denen Sie die Grundpfeiler der Hochverfügbarkeit umsetzen können. Die folgende Checkliste und Diskussion unterteilen diese Konstrukte und Mechanismen in Kategorien, die den vier HA-Säulen zugeordnet sind.

Kubernetes HA Checkliste

Abgesehen von der Zustandsverwaltung leistet Kubernetes einen außergewöhnlichen Job bei der Aufrechterhaltung von Anwendungs-HA. Die HA-Checkliste listet allgemeine Konfigurationen auf, die Sie zum Optimieren der Kubernetes HA-Verwaltung verwenden können. Um die Checkliste zu verwenden, bewerten Sie Ihre Kubernetes-Bereitstellung anhand der folgenden Mechanismen und Konstrukte, und implementieren Sie alle fehlenden.

HA-Säule Lösung
Redundancy ☐ Kubernetes-Controllertyp
☐ Anzahl der Replikate
☐ Planen von Antiaffinität
Überwachung ☐ Liveness-Prüfungen
☐ Bereitschaftsprüfungen
☐ Startsonden
Wiederherstellung ☐ Diensttyp
☐ Wahl des Vorsitzenden
☐ Neustartrichtlinie
☐ Pre-Stop-Hooks
Setzen von Prüfpunkten ☐ Persistente Volumeansprüche
☐ Persistente Datenträger

Redundancy

Redundanz verringert das Risiko eines Single Point of Failure. Sie benötigen Redundanz auf allen Ebenen einer Anwendung. Um Redundanz zu erzielen, replizieren Sie eine Komponente einer bestimmten Ebene mit mindestens einem identischen Replikat.

  • Controllertyp. Konfiguration: kind: Deployment. Kubernetes stellt mehrere Controller bereit, die den Lebenszyklus des Pods Ihrer Anwendung verwalten können. Der beliebteste Controller ist Deployment. Statefulset, ein weiterer Controller, ist nützlich, wenn Sie die Pod-Identität auch nach einer Wiederherstellung beibehalten müssen. Andere Controller wie Replicasets bieten nicht dieselben nützlichen Funktionen, etwa Rollbacks, die Deployment bietet.

  • Anzahl der Repliken. Konfiguration: spec.replicas. Wenn Sie die Anzahl der Replikate auf nur eins festlegen, wird ein Kalt-Standby-Modell konfiguriert. Wenn Sie ein Kalt-Standby-Modell verwenden, beginnt beim Auftreten eines Fehlers eine neue Instanz von Grund auf neu, was sich auf die Verfügbarkeit auswirkt. Dieses Modell könnte für Komponenten mit geringem Lastaufkommen geeignet sein, Sie sollten jedoch die Replikation zustandsloser Komponenten mit hohem Lastaufkommen in Betracht ziehen.

    Durch Angabe der Ressourcenanforderungen und -limits, spec.containers[].resources, können Sie die horizontale Pod-Autoskalierung (HPA) hinzufügen, wodurch Kubernetes die Anzahl der Replikate basierend auf den von Ihnen definierten Schwellenwerten für die Ressourcenauslastung automatisch hoch- oder herunterskaliert. HPA hilft Ihnen, Szenarien zu vermeiden, in denen ein Auslastungsanstieg verhindert, dass Ihre Anwendung Anforderungen aufgrund einer Überlastung bedient.

  • Planen von Antiaffinität. Konfiguration: spec.affinity.podAntiAffinity. Ein typischer Kubernetes-Cluster für den Produktiveinsatz verfügt über Knoten, die auf mehrere Verfügbarkeitszonen verteilt sind, die Sie mithilfe von topologyKey konfigurieren. Pods derselben Bereitstellung sollten eine bevorzugte oder weiche Anti-Affinität zueinander aufweisen. Diese Konfiguration stellt sicher, dass die Pods auf Knoten in verschiedenen Verfügbarkeitszonen eingeplant werden.

    Ein AKS-Cluster kann über mehrere Knotenpools verfügen, die jeweils unterschiedliche Größen und Spezifikationen von VM-Skalierungsgruppen haben. Sie können z. B. Ihre Datenbank pods auf Knoten mit schnellen Festkörperlaufwerken (Solid State Drives, SSDs) hosten und Ihre Machine Learning-Pods auf Knoten mit Grafikverarbeitungseinheiten (GPUs) hosten.

Überwachung

Wenn Sie Ihre Anwendung nicht überwachen, kann Redundanz unwirksam werden. Sie benötigen einen konstanten Überwachungsmechanismus, um sicherzustellen, dass die Workload ein fehlerfreies Replikat erreicht.

  • Die Konfiguration der Liveness-Sondenspec.containers.livenessProbe überwacht den Zustand Ihrer Pods. Wenn ein Container fehlschlägt oder beendet wird, kann Kubernetes ihn erkennen. Wenn Liveness fehlschlägt, startet Kubernetes den Container neu.

  • Bereitschaftssonden, 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 hilfreich ist. Es ist wichtig, die Readiness-Probes sorgfältig zu konfigurieren, da sie keinen Neustart auslösen, sondern dazu verwendet werden, die Pods so lange vom Traffic fernzuhalten, bis sie bereit sind.

  • Startup-Sonden-Konfiguration spec.containers.startupProbe verhindert hauptsächlich Fehlalarme bei Bereitschafts- und Lebendigkeitsprüfungen in Anwendungen mit langsamem Start. Nachdem die Startup-Probe erfolgreich ist, startet die Liveness-Probe.

Azure bietet tiefere Einblicke, mit denen Sie Warnungen basierend auf Ihrer Clusterintegrität festlegen können.

Wiederherstellung

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

  1. Isolieren und Umleiten: Stellen Sie sicher, dass das fehlerhafte Replikat keinen Datenverkehr empfängt, und leiten Sie die Arbeitsauslastung auf fehlerfreie Replikate weiter.
  2. Reparatur: Starten Sie das fehlerhafte Replikat neu. Auf diese Weise können vorübergehende Fehler behoben werden.
  3. Wiedereinbinden: Nach der Reparatur wird das Replikat, wenn die Überwachung es als funktionsfähig einstuft, wieder mit den anderen Replikaten verbunden, um die Arbeitslast zu bewältigen.

Kubernetes bietet die folgenden Mechanismen zum Implementieren dieser Phasen:

  • Diensttyp. Konfiguration: spec.type. Das Verfügbarmachen Ihrer Pods über einen Dienst kann als Redundanz oder Wiederherstellung klassifiziert werden. In einigen Fällen können Sie jedoch eine Bereitstellung mit nur einem Replikat verwenden. Es gibt weiterhin Vorteile, um die Pods über einen Dienst verfügbar zu machen, obwohl kein Lastenausgleich vorhanden ist.

    Der Hauptvorteil der Verwendung des Diensts besteht darin, dass DNS-Einträge (Domain Name System) automatisch mit den Kubernetes-Dienstendpunkten aktualisiert werden. Ein Pod, dessen Container fehlschlagende Readiness-Probes haben, erhält über AKS keinen Datenverkehr. Obwohl die Lastenausgleichsfähigkeit von Kubernetes-Cluster-IP-Diensten rudimentär ist, können Sie einen kopflosen Dienst mit Eingangs- oder anderen Service-Gitterlösungen koppeln, um die Lastenverteilung besser auszugleichen.

    Der Mechanismus, mit dem externer Datenverkehr Ihren AKS-Cluster erreicht, liegt außerhalb des Bereichs von Kubernetes. Sie können externen Datenverkehr mithilfe von Diensten wie Azure Application Gateway verarbeiten.

  • Wahl des Vorsitzenden. Einige Komponenten werden am besten als Singletons bereitgestellt. Der Planer ist eine solche Komponente, da zwei aktive Planer miteinander in Konflikt stehen können. Die Verwendung eines Singletons setzt die Anwendung Cold-Standby-Problemen aus. Um den warmen Standbymodus eines Pods zu aktivieren, können Sie die Wahl des Leiters verwenden, wobei nur ein Pod, der Leiter, Anfragen verarbeitet.

  • Starten Sie die Richtlinie neu. Konfiguration: spec.restartPolicy. Die Neustartrichtlinie gilt für alle Container im Pod. Es sollte eine gültige Begründung für das Setzen dieses Attributs auf Never geben. Einige Container wenden sich bei jedem Start an einen Lizenzserver, und Sie sollten die zusätzlichen Kosten für übermäßige Neustarts vermeiden.

  • Pre-Stop-Hooks. Konfiguration: spec.containers.lifecycle.preStop. Pre-stop-Hooks werden ausgeführt, bevor ein SIGTERM-Signal an den Container gesendet wird. Ein Pre-Stop-Skript kann so einfach sein wie ein Sleep-Befehl für 30 Sekunden.

    Wenn beispielsweise eine von einer HPA verwaltete Anwendung herunterskaliert wird, können noch laufende Anfragen möglicherweise abrupt abgebrochen werden, es sei denn, die Anwendung verfügt über einen SIGTERM-Handler, der die Bearbeitung von Anfragen abschließt, bevor sie sich beendet. Ein Pre-Stop-Hook entfernt den Pod-Endpunkt und daher den DNS-Eintrag vom Dienstendpunkt. Während der PreStop-Hook ausgeführt wird, können keine neuen Anfragen an den Pod gesendet werden. Der PreStop-Hook ermöglicht es dem Pod, die Bearbeitung bereits laufender Anfragen abzuschließen, ohne neue anzunehmen. Pre-Stop-Hooks sind eine einfache Möglichkeit, verworfene Anforderungen zu minimieren, ohne Anwendungscode zu ändern.

Setzen von Prüfpunkten

Moderne Anwendungen enthalten viele zustandslose Komponenten, aber völlig zustandslose Anwendungen sind immer noch selten. Die meisten Anwendungen überprüfen ihren Zustand auf der Datenebene. Kubernetes bietet absichtlich keinen Mechanismus zum Behandeln des Anwendungszustands. Die Zustandsverwaltung ist eine komplexe Aufgabe, die nicht Teil der Containerverwaltung ist.

Sie können den Anwendungsstatus in drei Ebenen beibehalten:

  • Auf der Datenrecordsetebene werden die Daten in einer Datenbank gespeichert. Jeder Datenbankdatensatz kann in mehreren Datenbankinstanzen repliziert werden. Datenbankdatensätze sind die dominante 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 Plug-Ins für ihre Lösungen an. Beispielsweise stellt Azure Files ein Plug-In bereit.

  • Die Datenträgerebene speichert Daten auf Blockebene, die Flexibilität zum Definieren des zu verwendenden Dateisystems bieten, wie in Azure Disk Storage.

Kubernetes-Volumes, persistente Volumes und persistente Volume-Claims können den Zustand der Anwendung auf Dateisystem- oder Datenträgerebene dauerhaft speichern. Das am häufigsten verwendete Muster zum Speichern des Zustands ist weiterhin die Ebene der Datensätze.

HA und DR

Für HA und Notfallwiederherstellung (DR) sind die Auswahlmöglichkeiten von Netzwerktopologie- und Lastenausgleichslösungen wichtig.

DR erfordert jedoch die Bereitstellung multiregionsübergreifender Dienste auf der gesamten Dienstebene mit Lastenausgleichslösungen zwischen Azure Regionen. Die Anwendung wird entweder in mehreren Regionen bereitgestellt, oder in jeder Region wird eine gesamte Anwendungsinstanz bereitgestellt. Die Wahl hängt von Anwendungstyp, Anwendungsarchitektur und Latenztoleranz zwischen Komponenten ab.

HA profitiert von Multizone-Bereitstellungen in Azure Regionen anstelle der Verwendung mehrerer Regionen. Das folgende Diagramm veranschaulicht den Unterschied zwischen Verfügbarkeitszonen und Regionen für HA und DR.

Diagramm, das Verfügbarkeitszonen und Azure Regionen für HA und DR vergleicht.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Dieser Artikel konzentriert sich auf HA auf Anwendungsebene innerhalb eines AKS-Clusters. Weitere Informationen zu DR in AKS-Multiclusterbereitstellungen finden Sie unter AKS-Basisplan für Multiregion-Cluster.

Weitere Überlegungen

  • Um den Anwendungs-HA zu verwalten, stellen Sie sicher, dass Ihre Kubernetes-Steuerebene, einschließlich des API-Servers und des Controller-Managers, hoch verfügbar ist. Verwenden Sie das Standard- oder Premium-Preisniveau , um HA sicherzustellen.

  • Eine Strategie zur Ressourcenkonsolidierung verstößt direkt gegen die HA-Redundanzsäule. Daher sollten Sie die Kosten der Redundanz sorgfältig analysieren. Der Azure Preisrechner kann ihnen helfen.

Contributors

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Andere Mitwirkende:

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

  • Last updated on