Ein wichtiger Punkt bei der Arbeit mit verteilten Systemen ist die Fehlerbehandlung. Kubernetes unterstützt dabei, indem es Controller einsetzt, die den Status Ihres Systems überwachen und nicht funktionierende Dienste neu starten. Allerdings kann Kubernetes auch Ihre Anwendungen zwangsweise stoppen, um die allgemeine Lebensfähigkeit des Systems zu gewährleisten. In dieser Reihe werden wir untersuchen, wie Sie Kubernetes dabei helfen können, seine Arbeit effizienter zu erledigen und die Ausfallzeiten von Anwendungen zu reduzieren.
Vor der Einführung von Containern liefen die meisten Anwendungen auf virtuellen oder physischen Maschinen. Wenn eine Anwendung abstürzte oder sich aufhängte, benötigte es viel Zeit, um die laufende Aufgabe zu beenden und das Programm neu zu laden. Im schlimmsten Fall musste jemand dieses Problem manuell nachts zur ungünstigsten Zeit lösen. Wenn eine wichtige Aufgabe nur auf 1-2 Arbeitsmaschinen durchgeführt wurde, war ein solcher Ausfall völlig inakzeptabel.
Deshalb begann man anstelle manueller Neufragungen, die Überwachung auf Prozessebene zu nutzen, um die Anwendung bei einem Absturz automatisch neu zu starten. Wenn das Programm abstürzt, erfasst der Überwachungsprozess den Exit-Code und startet den Server neu. Mit dem Aufkommen von Systemen wie Kubernetes wurde diese Form der Reaktion auf Systemausfälle einfach in die Infrastruktur integriert.
Kubernetes verwendet eine Ereignisschleife von "Beobachtung – Feststellung von Abweichungen – Durchführung von Aktionen", um sicherzustellen, dass die Ressourcen beim Übergang von Containern zu den Knoten funktionsfähig bleiben.
Das bedeutet, dass Sie die Überwachung von Prozessen nicht mehr manuell starten müssen. Wenn eine Ressource den Health Check nicht besteht, stellt Kubernetes einfach automatisch einen Ersatz bereit. Dabei leistet Kubernetes weit mehr, als nur die Ausfälle Ihrer Anwendungen zu überwachen. Es kann zusätzliche Kopien der Anwendung erstellen, um auf mehreren Maschinen zu arbeiten, die Anwendung aktualisieren oder mehrere Versionen Ihrer Anwendung gleichzeitig ausführen.
Es gibt viele Gründe, warum Kubernetes einen völlig gesunden Container stoppen kann. Zum Beispiel, wenn Sie Ihr Deployment aktualisieren, wird Kubernetes die alten Pods schrittweise abschalten, während neue gestartet werden. Wenn Sie einen Knoten deaktivieren, wird Kubernetes alle Pods in diesem Knoten stoppen. Schließlich, wenn einem Knoten die Ressourcen ausgehen, wird Kubernetes alle Pods abschalten, um diese Ressourcen freizugeben.
Es ist daher sehr wichtig, dass Ihre Anwendung mit minimalen Auswirkungen auf den Endbenutzer und minimaler Wiederherstellungszeit heruntergefahren wird. Das bedeutet, dass sie vor der Abschaltung alle notwendigen Daten speichern, alle Netzwerkverbindungen schließen, verbleibende Aufgaben beenden und andere dringende Aufgaben erledigen sollte.
In der Praxis bedeutet dies, dass Ihre Anwendung in der Lage sein sollte, das SIGTERM-Signal zu verarbeiten – das Prozessbeendigungszeichen, das das Standardzeichen für die Kill-Utility in Unix-basierten Betriebssystemen ist. Beim Erhalt dieses Signals sollte die Anwendung heruntergefahren werden.
Sobald Kubernetes beschlossen hat, einen Pod zu beenden, geschieht eine ganze Reihe von Ereignissen. Lassen Sie uns jeden Schritt betrachten, den Kubernetes beim Herunterfahren eines Containers oder Pods durchführt.
Nehmen wir an, wir möchten einen der Pods beenden. In diesem Moment wird er den neuen Verkehr nicht mehr erhalten – die laufenden Container im Pod werden nicht betroffen sein, aber der gesamte neue Verkehr wird blockiert.
Lassen Sie uns den preStop-Hook betrachten – dies ist ein spezieller Befehl oder HTTP-Anfrage, die an die Container im Pod gesendet wird. Wenn Ihre Anwendung beim Erhalt von SIGTERM nicht ordnungsgemäß herunterfährt, können Sie preStop verwenden, um sie korrekt zu beenden.
Die meisten Programme beenden ihre Arbeit korrekt, wenn sie das SIGTERM-Signal erhalten, aber wenn Sie fremden Code oder ein System verwenden, das Sie nicht vollständig kontrollieren können, ist der preStop-Hook eine hervorragende Möglichkeit, um ein elegantes Herunterfahren zu initiieren, ohne die Anwendung zu ändern.
Nach dem Ausführen dieses Hooks sendet Kubernetes ein SIGTERM-Signal an die Container im Pod, das ihnen mitteilt, dass sie bald abgeschaltet werden. Nachdem sie dieses Signal erhalten haben, wird Ihr Code in den Abschaltprozess übergehen. Dieser Prozess kann das Stoppen von langlebigen Verbindungen wie einer Datenbankverbindung oder einem WebSocket-Stream, das Speichern des aktuellen Zustands und Ähnliches umfassen.
Selbst wenn Sie den preStop-Hook verwenden, ist es sehr wichtig zu überprüfen, was genau mit Ihrer Anwendung passiert, wenn Sie ihr ein SIGTERM-Signal senden, wie sie sich dabei verhält, damit Ereignisse oder Systemänderungen, die durch das Herunterfahren des Pods verursacht werden, für Sie keine Überraschung werden.
In diesem Moment wird Kubernetes, bevor es weitere Maßnahmen ergreift, die angegebene Zeit, die als terminationGracePeriodSecond bekannt ist, oder den Zeitraum für ein sauberes Herunterfahren nach Erhalt des SIGTERM-Signals abwarten.
Standardmäßig beträgt dieser Zeitraum 30 Sekunden. Es ist wichtig zu beachten, dass er parallel zu dem preStop-Hook und dem SIGTERM-Signal verläuft. Kubernetes wartet nicht, bis der preStop-Hook und das SIGTERM abgeschlossen sind – wenn Ihre Anwendung vor Ablauf des terminationGracePeriod beendet wird, geht Kubernetes sofort zum nächsten Schritt über. Stellen Sie daher sicher, dass der Wert dieses Zeitraums in Sekunden nicht geringer ist als die für ein sauberes Herunterfahren des Pods erforderliche Zeit, und wenn er 30 Sekunden überschreitet, erhöhen Sie den Zeitraum im YAML auf den benötigten Wert. In dem gegebenen Beispiel beträgt er 60 Sekunden.
Und schließlich, der letzte Schritt – wenn die Container nach Ablauf des terminationGracePeriod weiterhin laufen, senden sie ein SIGKILL-Signal und werden gezwungen, entfernt zu werden. Zu diesem Zeitpunkt wird Kubernetes auch alle anderen Objekte des Pods bereinigen.
Kubernetes beendet Pods aus vielen Gründen, daher sollten Sie sicherstellen, dass Ihre Anwendung in jedem Fall ordnungsgemäß beendet wird, um einen stabilen Betrieb des Dienstes zu gewährleisten.
Ein wenig Werbung 🙂
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, , ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).
Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab $99! Lesen Sie, wie
Quelle: habr.com
