Verteilte Systeme sind schwer zu verwalten, weil es viele bewegliche, veränderbare Elemente gibt, die alle ordnungsgemäß funktionieren müssen, um die Funktionalität des Systems zu gewährleisten. Wenn eines der Elemente ausfällt, muss das System es erkennen, umgehen und reparieren, und all das muss automatisch geschehen. In dieser Reihe von 'Kubernetes Best Practices' erfahren wir, wie man Readiness- und Liveness-Tests einrichtet, um die Lebensfähigkeit des Kubernetes-Clusters zu überprüfen.
Health Check ist eine einfache Methode, um dem System mitzuteilen, ob Ihre Anwendungsinstanz funktioniert oder nicht. Wenn Ihre Anwendungsinstanz nicht funktioniert, sollten andere Services nicht auf sie zugreifen oder Anfragen an sie senden. Stattdessen sollte die Anfrage an eine andere Anwendungsinstanz gesendet werden, die bereits läuft oder später gestartet wird. Darüber hinaus muss das System Ihrer Anwendung die verloren gegangene Betriebsfähigkeit wiederherstellen.
Standardmäßig beginnt Kubernetes, den Datenverkehr an ein Pod zu senden, wenn alle Container innerhalb der Pods gestartet sind, und startet die Container neu, wenn sie abstürzen. Zu Beginn kann dieses Standardverhalten der Systeme ausreichend sein, jedoch können Sie die Zuverlässigkeit der Bereitstellung Ihres Produkts verbessern, indem Sie benutzerdefinierte Gesundheitsprüfungen verwenden.
Glücklicherweise ermöglicht es Kubernetes, dies ziemlich einfach zu tun, sodass es keine Entschuldigung für das Ignorieren solcher Überprüfungen gibt. Kubernetes bietet zwei Arten von Health Check-Tests, und es ist wichtig, die Unterschiede in der Anwendung von jedem zu verstehen.
Der Readiness-Test dient dazu, Kubernetes darüber zu informieren, ob Ihre Anwendung bereit ist, den Datenverkehr zu verarbeiten. Bevor Kubernetes dem Service erlaubt, den Datenverkehr an das Pod zu senden, muss es sicherstellen, dass der Readiness-Test erfolgreich ist. Wenn der Readiness-Test fehlschlägt, wird Kubernetes aufhören, den Datenverkehr an das Pod zu senden, bis die Überprüfung erfolgreich verläuft.
Der Liveness-Test informiert Kubernetes darüber, ob Ihre Anwendung lebt oder tot ist. Im ersten Fall lässt Kubernetes sie in Ruhe, im zweiten entfernt es das tote Pod und ersetzt es durch ein neues.
Stellen wir uns ein Szenario vor, in dem Ihre Anwendung zum Aufwärmen und Starten eine Minute benötigt. Ihr Dienst wird nicht aktiv, bis die Anwendung vollständig geladen und gestartet ist, obwohl der Arbeitsablauf bereits begonnen hat. Zudem werden Sie Probleme haben, wenn Sie die Skalierung dieses Deployments auf mehrere Kopien erhöhen möchten, da diese Kopien keinen Traffic erhalten sollen, solange sie nicht vollständig bereit sind. Standardmäßig wird Kubernetes jedoch sofort mit dem Senden von Traffic beginnen, sobald die Prozesse innerhalb des Containers gestartet werden.
Bei der Verwendung des Readiness-Tests wird Kubernetes warten, bis die Anwendung vollständig gestartet ist, und erst dann erlaubt es dem Dienst, Traffic auf die neue Kopie zu senden.
Stellen wir uns ein anderes Szenario vor, in dem die Anwendung für längere Zeit einfriert und keine Anfragen mehr bearbeitet. Da der Prozess weiterhin läuft, wird Kubernetes standardmäßig annehmen, dass alles in Ordnung ist, und weiterhin Anfragen an das nicht funktionierende Pod senden. Aber mit Liveness wird Kubernetes feststellen, dass die Anwendung keine Anfragen mehr bearbeitet, und standardmäßig das nicht funktionierende Pod neu starten.
Betrachten wir, womit die Bereitschaft und Lebensfähigkeit getestet wird. Es gibt drei Möglichkeiten zum Testen – HTTP, Command und TCP. Sie können jede davon zur Überprüfung verwenden. Der gebräuchlichste Weg eines benutzerdefinierten Tests ist der HTTP-Probe.
Selbst wenn Ihre Anwendung kein HTTP-Server ist, können Sie einen schlanken HTTP-Server innerhalb Ihrer Anwendung erstellen, um mit dem Liveness-Test zu interagieren. Danach beginnt Kubernetes, das Pod zu pingen, und wenn die HTTP-Antwort im Bereich von 200 oder 300 ms liegt, bedeutet dies, dass das Pod „gesund“ ist. Andernfalls wird das Modul als „ungesund“ markiert.
Für Tests führt Kubernetes mithilfe von Command den Befehl innerhalb Ihres Containers aus. Wenn der Befehl mit einem Null-Exit-Code zurückkehrt, wird der Container als gesund markiert. Andernfalls wird der Container bei einem Exit-Status von 1 bis 255 als "krank" angesehen. Diese Testmethode ist nützlich, wenn Sie keinen HTTP-Server starten können oder möchten, aber in der Lage sind, einen Befehl auszuführen, der die "Gesundheit" Ihrer Anwendung überprüft.
Der letzte Prüfmechanismus ist der TCP-Test. Kubernetes versucht, eine TCP-Verbindung zum angegebenen Port herzustellen. Wenn dies gelingt, gilt der Container als gesund, andernfalls als nicht funktionsfähig. Diese Methode kann nützlich sein, wenn Sie ein Szenario verwenden, in dem das Testen über eine HTTP-Anfrage oder das Ausführen eines Befehls nicht gut funktioniert. Zum Beispiel werden gRPC oder FTP die Hauptdienste für die Überprüfung über TCP sein.
Tests können auf verschiedene Arten mit unterschiedlichen Parametern konfiguriert werden. Sie können angeben, wie oft sie ausgeführt werden sollen, welche Schwellenwerte für Erfolg und Misserfolg gelten und wie lange auf Antworten gewartet werden soll. Detailliertere Informationen finden Sie in der Dokumentation zu Readiness- und Liveness-Tests. Es gibt jedoch einen sehr wichtigen Punkt bei der Konfiguration des Liveness-Tests – die initiale Verzögerung für das Testen initialDelaySeconds. Wie ich erwähnt habe, führt ein fehlgeschlagener Test zu einem Neustart des Moduls. Daher müssen Sie sicherstellen, dass das Testen nicht beginnt, bis die Anwendung bereit ist, sonst wird sie in einer Restart-Schleife feststecken. Ich empfehle, die P99-Startup-Zeit oder die durchschnittliche Startup-Zeit der Anwendung aus dem Puffer zu verwenden. Denken Sie daran, diesen Wert anzupassen, wenn die Startup-Zeit Ihrer Anwendung schneller oder langsamer wird.
Die meisten Fachleute werden bestätigen, dass Health Checks eine obligatorische Prüfung für jedes verteilte System sind, und Kubernetes bildet da keine Ausnahme. Die Verwendung von Gesundheitsprüfungen für Dienste gewährleistet einen zuverlässigen und ausfallsicheren Betrieb von Kubernetes und ist für die Benutzer mühelos.
Fortsetzung erfolgt in Kürze…
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
