Verteilte Systeme können aufgrund vieler beweglicher und veränderlicher Elemente schwer zu verwalten sein, da alle diese Elemente einwandfrei 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 automatisch reparieren. In dieser Serie 'Kubernetes Best Practices' lernen wir, wie man Readiness- und Liveness-Tests einrichtet, um die Lebensfähigkeit eines Kubernetes-Clusters zu überprüfen.
Health Check ist eine einfache Möglichkeit, der System zu signalisieren, ob eine Instanz Ihrer Anwendung funktioniert oder nicht. Wenn eine Instanz Ihrer Anwendung nicht funktioniert, sollten andere Dienste nicht darauf zugreifen oder Anfragen an sie senden. Stattdessen sollte die Anfrage an eine andere Instanz der Anwendung gesendet werden, die bereits läuft oder später gestartet wird. Darüber hinaus sollte das System Ihrem Anwendung die verlorene Betriebsfähigkeit zurückgeben.
Standardmäßig beginnt Kubernetes damit, den Traffic an den Pod zu senden, wenn alle Container innerhalb der Pods gestartet sind, und startet die Container neu, wenn sie abstürzen. Für den Anfang kann dieses standardmäßige Verhalten des Systems ausreichend sein, jedoch können Sie die Zuverlässigkeit Ihrer Produktbereitstellung erhöhen, indem Sie benutzerdefinierte Gesundheitsprüfungen verwenden.
Glücklicherweise ermöglicht Kubernetes dies recht einfach, sodass es keine Entschuldigung für das Ignorieren solcher Prüfungen gibt. Kubernetes bietet zwei Arten von Gesundheitsprüfungen an, und es ist wichtig, die Unterschiede bei der Anwendung jeder einzelnen zu verstehen.
Der Readiness-Test dient dazu, Kubernetes über die Bereitschaft Ihrer Anwendung zu informieren, Traffic zu bedienen. Bevor der Service den Traffic an den Pod senden darf, muss Kubernetes sicherstellen, dass die Readiness-Prüfung erfolgreich ist. Fällt der Readiness-Test aus, wird Kubernetes den Traffic an den Pod stoppen, bis die Prüfung erfolgreich bestanden wird.
Der Liveness-Test informiert Kubernetes darüber, ob Ihre Anwendung aktiv oder inaktiv ist. Im ersten Fall lässt Kubernetes sie in Ruhe, im zweiten Fall entfernt es den inaktiven Pod und ersetzt ihn durch einen neuen.
Stellen Sie sich ein Szenario vor, in dem Ihre Anwendung eine Minute braucht, um hochgefahren und zu starten. Ihr Service beginnt nicht zu arbeiten, bis die Anwendung vollständig geladen und gestartet ist, obwohl der Arbeitsablauf bereits begonnen hat. Zudem werden Sie Probleme haben, wenn Sie diese Bereitstellung auf mehrere Kopien skalieren möchten, da diese Kopien keinen Traffic erhalten sollten, bis sie vollständig betriebsbereit sind. Standardmäßig wird Kubernetes jedoch sofort nach dem Start der Prozesse innerhalb des Containers mit der Versendung von Traffic beginnen.
Bei Verwendung des Readiness-Tests wird Kubernetes warten, bis die Anwendung vollständig gestartet ist, und erst dann dem Service erlauben, Traffic an 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 ausgeführt wird, wird Kubernetes standardmäßig davon ausgehen, dass alles in Ordnung ist, und weiterhin Anfragen an den nicht funktionierenden Pod senden. Mit Liveness kann Kubernetes jedoch feststellen, dass die Anwendung keine Anfragen mehr bearbeitet, und wird standardmäßig den nicht funktionierenden Pod neu starten.
Betrachten wir die Methoden zur Testung von Bereitschaft und Lebensfähigkeit. Es gibt drei Möglichkeiten zur Testung: HTTP, Command und TCP. Für die Überprüfung können Sie jede dieser Methoden verwenden. Die häufigste Methode für Benutzer-Tests ist der HTTP-Probe.
Selbst wenn Ihre Anwendung kein HTTP-Server ist, können Sie trotzdem einen leichten HTTP-Server in Ihrer Anwendung einrichten, um mit dem Liveness-Test zu interagieren. Anschließend beginnt Kubernetes, den Pod anzupingen, und wenn die HTTP-Antwort im Bereich von 200 oder 300 ms liegt, bedeutet dies, dass der Pod "gesund" ist. Andernfalls wird das Modul als "ungesund" markiert.
Für Tests verwendet Command Kubernetes einen Befehl innerhalb Ihres Containers. Wenn der Befehl mit einem Null-Exit-Code zurückgegeben wird, wird der Container als gesund gekennzeichnet. Andernfalls, bei einem Exit-Status zwischen 1 und 255, wird der Container als "krank" markiert. Diese Testmethode ist hilfreich, 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 über den angegebenen Port herzustellen. Gelingt dies, wird der Container als gesund angesehen; gelingt es nicht, als lebensunfähig. Diese Methode kann nützlich sein, wenn Sie ein Skript verwenden, bei dem Tests über HTTP-Anfragen oder die Ausführung von Befehlen nicht gut funktionieren. Zum Beispiel werden gRPC oder FTP häufig als Hauptdienste für die TCP-Überprüfung verwendet.
Tests können auf verschiedene Weise mit unterschiedlichen Parametern konfiguriert werden. Sie können angeben, wie häufig sie ausgeführt werden sollen, welche Erfolg- und Misserfolgsschwellen gelten 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 bei der Konfiguration des Liveness-Tests – die anfängliche Verzögerung bei der Ausführung der Tests, initialDelaySeconds. Wie bereits erwähnt, wird ein fehlerhaftes Bestehen dieses Tests zu einem Neustart des Moduls führen. Daher müssen Sie sicherstellen, dass die Tests erst beginnen, wenn die Anwendung betriebsbereit ist, da sie ansonsten in einer endlosen Neustartschleife gefangen ist. Ich empfehle, die P99-Startzeit oder die durchschnittliche Startzeit der Anwendung aus dem Puffer zu verwenden. Vergessen Sie nicht, diesen Wert anzupassen, sobald sich die Startzeit Ihrer Anwendung beschleunigt oder verlangsamt.
Die meisten Fachleute stimmen zu, dass Health Checks eine obligatorische Prüfung für jedes verteilte System sind, und Kubernetes bildet da keine Ausnahme. Die Verwendung von "Health Checks" für Services gewährleistet den zuverlässigen und fehlerfreien Betrieb von Kubernetes und ist für die Benutzer problemlos.
Die Fortsetzung kommt 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 Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber
Quelle: habr.com
