Verteilte Systeme können schwierig zu verwalten sein, da sie über viele bewegliche und sich ändernde Elemente verfügen, die alle ordnungsgemäß funktionieren müssen, damit das System funktioniert. Wenn eines der Elemente ausfällt, muss das System dies erkennen, umgehen und beheben, und das alles muss automatisch erfolgen. In dieser Kubernetes Best Practices-Reihe erfahren Sie, wie Sie Readiness- und Liveness-Tests einrichten, um den Zustand eines Kubernetes-Clusters zu testen.
Health Check ist eine einfache Möglichkeit, dem System mitzuteilen, ob Ihre Anwendungsinstanz ausgeführt wird oder nicht. Wenn Ihre Anwendungsinstanz ausgefallen ist, sollten andere Dienste nicht darauf zugreifen oder Anfragen an sie senden. Stattdessen muss die Anfrage an eine andere Instanz der Anwendung gesendet werden, die bereits ausgeführt wird oder später gestartet wird. Darüber hinaus sollte das System die verlorene Funktionalität Ihrer Anwendung wiederherstellen.
Standardmäßig beginnt Kubernetes mit dem Senden von Datenverkehr an einen Pod, wenn alle Container innerhalb der Pods ausgeführt werden, und startet Container neu, wenn sie abstürzen. Dieses Standardsystemverhalten mag für den Anfang ausreichend sein, aber Sie können die Zuverlässigkeit Ihrer Produktbereitstellung verbessern, indem Sie benutzerdefinierte Plausibilitätsprüfungen verwenden.
Glücklicherweise ist dies mit Kubernetes ganz einfach möglich, sodass es keine Entschuldigung gibt, diese Überprüfungen zu ignorieren. Kubernetes bietet zwei Arten von Gesundheitsprüfungen, und es ist wichtig, die Unterschiede in der Verwendung der einzelnen Arten zu verstehen.
Der Bereitschaftstest soll Kubernetes mitteilen, dass Ihre Anwendung für die Verarbeitung von Datenverkehr bereit ist. Bevor einem Dienst erlaubt wird, Datenverkehr an einen Pod zu senden, muss Kubernetes überprüfen, ob die Bereitschaftsprüfung erfolgreich ist. Wenn der Bereitschaftstest fehlschlägt, sendet Kubernetes keinen Datenverkehr mehr an den Pod, bis der Test erfolgreich ist.
Der Liveness-Test teilt Kubernetes mit, ob Ihre Anwendung aktiv oder tot ist. Im ersten Fall lässt Kubernetes es in Ruhe, im zweiten Fall löscht es den toten Pod und ersetzt ihn durch einen neuen.
Stellen wir uns ein Szenario vor, in dem Ihre Anwendung 1 Minute zum Aufwärmen und Starten benötigt. Ihr Dienst wird erst dann funktionieren, wenn die Anwendung vollständig geladen ist und ausgeführt wird, obwohl der Workflow bereits gestartet ist. Außerdem treten Probleme auf, wenn Sie diese Bereitstellung auf mehrere Kopien skalieren möchten, da diese Kopien keinen Datenverkehr empfangen sollten, bis sie vollständig bereit sind. Standardmäßig beginnt Kubernetes jedoch mit dem Senden von Datenverkehr, sobald Prozesse im Container beginnen.
Bei Verwendung des Bereitschaftstests wartet Kubernetes, bis die Anwendung vollständig ausgeführt wird, bevor es dem Dienst erlaubt, Datenverkehr an die neue Kopie zu senden.
Stellen wir uns ein anderes Szenario vor, in dem die Anwendung für längere Zeit hängen bleibt und keine Bearbeitungsanfragen mehr bearbeitet werden. Während der Prozess weiter ausgeführt wird, geht Kubernetes standardmäßig davon aus, dass alles in Ordnung ist, und sendet weiterhin Anfragen an den nicht funktionierenden Pod. Bei Verwendung von Liveness erkennt Kubernetes jedoch, dass die Anwendung keine Anfragen mehr bedient, und startet den toten Pod standardmäßig neu.
Schauen wir uns an, wie Bereitschaft und Lebensfähigkeit getestet werden. Es gibt drei Testmethoden: HTTP, Command und TCP. Sie können jedes davon zur Überprüfung verwenden. Die gebräuchlichste Methode zum Testen eines Benutzers ist eine HTTP-Probe.
Auch wenn Ihre Anwendung kein HTTP-Server ist, können Sie in Ihrer Anwendung dennoch einen einfachen HTTP-Server erstellen, um mit dem Liveness-Test zu interagieren. Danach beginnt Kubernetes, den Pod anzupingen, und wenn die HTTP-Antwort im Bereich von 200 oder 300 ms liegt, wird angezeigt, dass der Pod fehlerfrei ist. Andernfalls wird das Modul als „fehlerhaft“ markiert.
Bei Befehlstests führt Kubernetes den Befehl in Ihrem Container aus. Wenn der Befehl mit einem Null-Exit-Code zurückkehrt, wird der Container als fehlerfrei markiert. Andernfalls wird der Container beim Empfang einer Exit-Statusnummer von 1 bis 255 als „krank“ markiert. Diese Testmethode ist nützlich, wenn Sie keinen HTTP-Server ausführen können oder wollen, aber einen Befehl ausführen können, der den Zustand Ihrer Anwendung überprüft.
Der letzte Überprüfungsmechanismus ist der TCP-Test. Kubernetes wird versuchen, eine TCP-Verbindung auf dem angegebenen Port herzustellen. Wenn dies möglich ist, gilt der Behälter als gesund; andernfalls gilt er als unbrauchbar. Diese Methode kann nützlich sein, wenn Sie ein Szenario verwenden, in dem das Testen mit einer HTTP-Anfrage oder der Befehlsausführung nicht sehr gut funktioniert. Die Hauptdienste für die Verifizierung mittels TCP wären beispielsweise gRPC oder FTP.
Tests können auf verschiedene Arten mit unterschiedlichen Parametern konfiguriert werden. Sie können angeben, wie oft sie ausgeführt werden sollen, wie hoch die Erfolgs- und Fehlerschwellenwerte sind und wie lange auf Antworten gewartet werden soll. Weitere Informationen finden Sie in der Dokumentation zu den Readiness- und Liveness-Tests. Es gibt jedoch einen sehr wichtigen Punkt beim Einrichten des Liveness-Tests – die anfängliche Einstellung der Testverzögerung initialDelaySeconds. Wie bereits erwähnt, führt ein Fehlschlagen dieses Tests dazu, dass das Modul neu gestartet wird. Sie müssen also sicherstellen, dass die Tests erst dann beginnen, wenn die Anwendung betriebsbereit ist, da sie andernfalls ständig neu gestartet werden muss. Ich empfehle die Verwendung der P99-Startzeit oder der durchschnittlichen Anwendungsstartzeit aus dem Puffer. Denken Sie daran, diesen Wert anzupassen, wenn die Startzeit Ihrer Anwendung schneller oder langsamer wird.
Die meisten Experten werden bestätigen, dass Health Checks eine obligatorische Prüfung für jedes verteilte System sind, und Kubernetes bildet da keine Ausnahme. Der Einsatz von Service Health Checks gewährleistet einen zuverlässigen, störungsfreien Betrieb von Kubernetes und ist für Benutzer mühelos.
Demnächst geht es weiter...
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