Best Practices von Kubernetes. Richtig Beenden Deaktivieren

Best Practices von Kubernetes. Erstellen kleiner Container
Best Practices für Kubernetes. Kubernetes-Organisation mit dem Kubernetes
Best Practices-Namespace. Kubernetes-Lebensfähigkeitstest mit Bereitschafts- und Lebendigkeitstests Kubernetes
Best Practices. Konfigurieren von Anforderungen und Ressourcenlimits



Ein wichtiger Punkt beim Betrieb verteilter Systeme ist die Behandlung von Fehlern. Kubernetes hilft dabei, indem es Controller verwendet, die den Status Ihres Systems überwachen und Dienste neu starten, die nicht mehr funktionieren. Kubernetes kann Ihre Anwendungen jedoch zwangsweise herunterfahren, um die allgemeine Systemlebensfähigkeit sicherzustellen. In dieser Reihe werden wir untersuchen, wie Sie Kubernetes dabei unterstützen können, seine Arbeit effizienter zu erledigen und Ausfallzeiten von Anwendungen zu reduzieren.

Vor der Verwendung von Containern wurden die meisten Anwendungen auf virtuellen oder physischen Maschinen ausgeführt. Wenn die Anwendung abstürzte oder abstürzte, dauerte es lange, bis die laufende Aufgabe entfernt und das Programm erneut heruntergeladen wurde. Im schlimmsten Fall musste jemand dieses Problem nachts manuell lösen, zum ungünstigsten Zeitpunkt. Wenn nur 1-2 Arbeitsmaschinen eine wichtige Aufgabe ausführten, war eine solche Fehlfunktion völlig inakzeptabel.
Anstatt manuell neu zu starten, wurde daher die Überwachung auf Prozessebene verwendet, um die Anwendung im Falle einer abnormalen Beendigung 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 Art der Systemfehlerreaktion einfach in die Infrastruktur integriert.

Kubernetes verwendet die Ereignisschleife "Beobachten - Unterschiede festschreiben - Aktionen festschreiben", um sicherzustellen, dass die Ressourcen auf dem Weg von den Containern zu den Knoten selbst betriebsbereit bleiben.



Dies bedeutet, dass Sie die Prozessüberwachung nicht mehr manuell starten müssen. Wenn eine Ressource den Health Check nicht besteht, stellt Kubernetes einfach automatisch einen Ersatz bereit. Kubernetes überwacht nicht nur Ihre Anwendungsabstürze. Es kann mehr Kopien der Anwendung erstellen, um auf mehreren Computern zu arbeiten, die Anwendung zu aktualisieren oder gleichzeitig mehrere Versionen Ihrer Anwendung auszuführen.
Daher gibt es viele Gründe, warum Kubernetes einen vollkommen gesunden Container unterbrechen kann. Wenn Sie beispielsweise Ihre Bereitstellung aktualisieren, stoppt Kubernetes langsam alte Pods, während neue gestartet werden. Wenn Sie einen Knoten trennen, beendet Kubernetes alle Herde in diesem Knoten. Wenn dem Knoten die Ressourcen ausgehen, deaktiviert Kubernetes alle Pods, um diese Ressourcen freizugeben.

Daher ist es sehr wichtig, dass Ihre Anwendung mit minimalen Auswirkungen auf den Endbenutzer und minimaler Wiederherstellungszeit nicht mehr funktioniert. Dies bedeutet, dass vor dem Trennen der Verbindung alle zu speichernden Daten gespeichert, alle Netzwerkverbindungen geschlossen, die verbleibenden Arbeiten abgeschlossen und Zeit für andere dringende Aufgaben bleibt.

In der Praxis bedeutet dies, dass Ihre Anwendung in der Lage sein sollte, die SIGTERM-Nachricht zu verarbeiten - das Prozessbeendigungssignal, das das Standardsignal für das Kill-Dienstprogramm im Betriebssystem der Unix-Familie ist. Nach Erhalt dieser Nachricht sollte die Anwendung die Verbindung trennen.

Nachdem Kubernetes beschlossen hatte, den Pod fertigzustellen, fand eine ganze Reihe von Veranstaltungen statt. Schauen wir uns jeden Schritt an, den Kubernetes unternimmt, wenn ein Container oder eine Feuerstelle fertig ist.

Angenommen, wir möchten einen der Herde fertigstellen. Zu diesem Zeitpunkt wird kein neuer Verkehr mehr empfangen - Container, die im Kamin arbeiten, sind nicht betroffen, aber der gesamte neue Verkehr wird blockiert.



Schauen wir uns den preStop-Hook an - dies ist ein spezieller Befehl oder eine HTTP-Anforderung, die an Container im Herd gesendet wird. Wenn sich Ihre Anwendung beim Empfang von SIGTERM nicht richtig ausschaltet, können Sie preStop verwenden, um das Programm korrekt zu beenden.



Die meisten Programme, die ein SIGTERM-Signal empfangen, schließen ihre Arbeit korrekt ab. Wenn Sie jedoch Code von Drittanbietern oder ein System verwenden, das Sie nicht vollständig steuern können, ist der preStop-Hook eine hervorragende Möglichkeit, ein ordnungsgemäßes Herunterfahren zu bewirken, ohne die Anwendung zu ändern.

Nach dem Ausführen dieses Hooks sendet Kubernetes ein SIGTERM-Signal an die Container im Herd, das sie darüber informiert, dass sie bald getrennt werden. Nachdem Sie dieses Signal erhalten haben, fährt Ihr Code mit dem Herunterfahren fort. Dieser Prozess kann das Beenden langlebiger Verbindungen umfassen, z. B. das Herstellen einer Verbindung zu einer Datenbank oder einem WebSocket-Stream, das Speichern des aktuellen Status und dergleichen.

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, und wie es sich so verhält, dass Ereignisse oder Änderungen im Systembetrieb, die durch das Herunterfahren des Herdes verursacht werden, Sie nicht überraschen.

Zu diesem Zeitpunkt wartet Kubernetes, bevor weitere Maßnahmen ergriffen werden, auf eine bestimmte Zeit, die als terminierungGracePeriodSecond bezeichnet wird, oder auf die Zeitspanne, in der das Gerät ordnungsgemäß heruntergefahren wird, wenn es ein SIGTERM-Signal empfängt.



Standardmäßig beträgt dieser Zeitraum 30 Sekunden. Es ist wichtig zu beachten, dass es parallel zum PreStop-Hook und zum SIGTERM-Signal dauert. Kubernetes wartet nicht auf das Ende des PreStop-Hooks und von SIGTERM. Wenn Ihre Anwendung vor Ablauf der TerminationGracePeriod beendet wird, fährt Kubernetes sofort mit dem nächsten Schritt fort. Stellen Sie daher sicher, dass der Wert dieser Zeitspanne in Sekunden nicht kürzer ist als die Zeit, die der Herd benötigt, um ordnungsgemäß auszuschalten. Wenn er 30 Sekunden überschreitet, erhöhen Sie die Zeitspanne auf den gewünschten Wert in YAML. Im obigen Beispiel sind es 60er Jahre.

Und schließlich der letzte Schritt: Wenn die Container nach Ablauf der TerminationGracePeriod weiterhin funktionieren, senden sie ein SIGKILL-Signal und werden gewaltsam gelöscht. Zu diesem Zeitpunkt bereinigt Kubernetes auch alle anderen Pod-Objekte.



Kubernetes schaltet Herde aus vielen Gründen aus. Stellen Sie daher sicher, dass Ihre Anwendung in jedem Fall korrekt ausgefüllt wird, um einen stabilen Betrieb des Dienstes zu gewährleisten.

Best Practices von Kubernetes. Zuordnung externer Dienste

Ein bisschen Werbung :)

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?