Ein wichtiger Punkt beim Betrieb verteilter Systeme ist die Fehlerbehandlung. Kubernetes hilft dabei, indem es Controller verwendet, die den Zustand Ihres Systems überwachen und Dienste neu starten, die nicht mehr funktionieren. Allerdings kann Kubernetes Ihre Anwendungen zwangsweise stoppen, um den allgemeinen Systemzustand sicherzustellen. In dieser Serie schauen wir uns an, wie Sie Kubernetes dabei helfen können, seine Arbeit effizienter zu erledigen und Anwendungsausfallzeiten zu reduzieren.
Vor Containern liefen die meisten Anwendungen auf virtuellen oder physischen Maschinen. Wenn die Anwendung abstürzte oder einfror, dauerte es lange, die laufende Aufgabe abzubrechen und das Programm neu zu laden. Im schlimmsten Fall musste jemand dieses Problem nachts, zur ungünstigsten Stunde, manuell lösen. Wenn nur 1-2 Arbeitsmaschinen eine wichtige Aufgabe erledigten, war eine solche Störung völlig inakzeptabel.
Anstelle manueller Neustarts begannen sie daher mit der Überwachung auf Prozessebene, um die Anwendung im Falle einer abnormalen Beendigung automatisch neu zu starten. Wenn das Programm fehlschlägt, erfasst der Überwachungsprozess den Exit-Code und startet den Server neu. Mit dem Aufkommen von Systemen wie Kubernetes wurde diese Art der Reaktion auf Systemausfälle einfach in die Infrastruktur integriert.
Kubernetes verwendet eine Ereignisschleife zum Beobachten, Unterscheiden und Handeln, um sicherzustellen, dass die Ressourcen auf ihrem Weg von den Containern zu den Knoten selbst gesund bleiben.
Dies bedeutet, dass Sie die Prozessüberwachung nicht mehr manuell durchführen müssen. Wenn eine Ressource den Health Check nicht besteht, stellt Kubernetes ihr einfach automatisch einen Ersatz zur Verfügung. Kubernetes leistet jedoch viel mehr als nur die Überwachung Ihrer Anwendung auf Fehler. Es kann mehr Kopien der Anwendung erstellen, um sie auf mehreren Computern auszuführen, die Anwendung aktualisieren oder mehrere Versionen Ihrer Anwendung gleichzeitig ausführen.
Daher gibt es viele Gründe, warum Kubernetes einen vollkommen fehlerfreien Container beenden kann. Wenn Sie beispielsweise Ihre Bereitstellung aktualisieren, stoppt Kubernetes langsam alte Pods, während neue gestartet werden. Wenn Sie einen Knoten herunterfahren, stoppt Kubernetes die Ausführung aller Pods auf diesem Knoten. Wenn einem Knoten schließlich die Ressourcen ausgehen, fährt Kubernetes alle Pods herunter, um diese Ressourcen freizugeben.
Daher ist es wichtig, dass Ihre Anwendung mit minimalen Auswirkungen auf den Endbenutzer und minimaler Wiederherstellungszeit beendet wird. Das bedeutet, dass vor dem Herunterfahren alle zu speichernden Daten gespeichert, alle Netzwerkverbindungen geschlossen, verbleibende Arbeiten erledigt und andere dringende Aufgaben erledigt werden müssen.
In der Praxis bedeutet dies, dass Ihre Anwendung in der Lage sein muss, die SIGTERM-Nachricht zu verarbeiten, das Prozessbeendigungssignal, das das Standardsignal für das Kill-Dienstprogramm auf Unix-Betriebssystemen ist. Nach Erhalt dieser Nachricht sollte die Anwendung heruntergefahren werden.
Sobald Kubernetes beschließt, einen Pod zu beenden, treten eine Reihe von Ereignissen auf. Schauen wir uns jeden Schritt an, den Kubernetes beim Herunterfahren eines Containers oder Pods durchführt.
Nehmen wir an, wir möchten einen der Pods beenden. Zu diesem Zeitpunkt wird kein neuer Datenverkehr mehr empfangen. Die im Pod ausgeführten Container sind davon nicht betroffen, aber der gesamte neue Datenverkehr wird blockiert.
Schauen wir uns den preStop-Hook an, bei dem es sich um einen speziellen Befehl oder eine HTTP-Anfrage handelt, die an Container in einem Pod gesendet wird. Wenn Ihre Anwendung beim Empfang von SIGTERM nicht ordnungsgemäß heruntergefahren wird, können Sie preStop für das ordnungsgemäße Herunterfahren verwenden.
Die meisten Programme werden ordnungsgemäß beendet, wenn sie ein SIGTERM-Signal empfangen. Wenn Sie jedoch Code von Drittanbietern oder ein System verwenden, das Sie nicht vollständig kontrollieren können, ist der preStop-Hook eine hervorragende Möglichkeit, ein ordnungsgemäßes Herunterfahren zu erzwingen, ohne die Anwendung zu ändern.
Nach der Ausführung dieses Hooks sendet Kubernetes ein SIGTERM-Signal an die Container im Pod und teilt ihnen mit, dass die Verbindung bald getrennt wird. Nach Erhalt dieses Signals fährt Ihr Code mit dem Herunterfahrvorgang fort. Dieser Prozess kann das Stoppen langlebiger Verbindungen wie einer Datenbankverbindung oder eines WebSocket-Streams, das Speichern des aktuellen Status und Ähnliches umfassen.
Selbst wenn Sie einen preStop-Hook verwenden, ist es sehr wichtig zu überprüfen, was genau mit Ihrer Anwendung passiert, wenn Sie ihr ein SIGTERM-Signal senden, und wie sie sich verhält, damit keine Ereignisse oder Änderungen im Systembetrieb auftreten, die durch das Herunterfahren eines Pods verursacht werden eine Überraschung für dich.
Zu diesem Zeitpunkt wartet Kubernetes eine bestimmte Zeitspanne namens „terminationGracePeriodSecond“ bzw. den Zeitraum bis zum ordnungsgemäßen Herunterfahren bei Empfang eines SIGTERM-Signals, bevor es weitere Maßnahmen ergreift.
Standardmäßig beträgt dieser Zeitraum 30 Sekunden. Es ist wichtig zu beachten, dass es parallel zum preStop-Hook und dem SIGTERM-Signal läuft. Kubernetes wartet nicht auf das Ende des preStop-Hooks und von SIGTERM. Wenn Ihre Anwendung vor Ablauf des TerminationGracePeriod beendet wird, fährt Kubernetes sofort mit dem nächsten Schritt fort. Stellen Sie daher sicher, dass der Wert dieses Zeitraums in Sekunden nicht kleiner ist als die Zeit, die zum korrekten Herunterfahren des Pods erforderlich ist. Wenn er 30 Sekunden überschreitet, erhöhen Sie den Zeitraum auf den gewünschten Wert in YAML. Im angegebenen Beispiel sind es 60er Jahre.
Und schließlich besteht der letzte Schritt darin, dass Container, wenn sie nach TerminationGracePeriod noch ausgeführt werden, ein SIGKILL-Signal senden und zwangsweise gelöscht werden. Zu diesem Zeitpunkt bereinigt Kubernetes auch alle anderen Pod-Objekte.
Kubernetes beendet Pods aus vielen Gründen. Stellen Sie daher sicher, dass Ihre Anwendung in jedem Fall ordnungsgemäß beendet wird, um einen stabilen Dienst zu gewährleisten.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com