Best Practices von Kubernetes. Kubernetes Lebensfähigkeitstest mit Bereitschafts- und Lebendigkeitstests

Best Practices von Kubernetes. Erstellen kleiner Container
Best Practices für Kubernetes. Kubernetes-Organisation mit einem Namespace



Verteilte Systeme können schwierig zu verwalten sein, da sie viele bewegliche veränderbare Elemente enthalten und alle ordnungsgemäß funktionieren müssen, um die Funktionalität des Systems sicherzustellen. Wenn eines der Elemente ausfällt, muss das System es erkennen, umgehen und reparieren, und dies alles muss automatisch erfolgen. In dieser Kubernetes Best Practices-Reihe erfahren Sie, wie Sie Bereitschafts- und Lebendigkeitstests konfigurieren, um die Lebensfähigkeit eines Kubernetes-Clusters zu testen.

Integritätsprüfung Mit der Integritätsprüfung können Sie dem System auf einfache Weise mitteilen, ob Ihre Anwendungsinstanz ausgeführt wird oder nicht. Wenn eine Instanz Ihrer Anwendung nicht funktioniert, sollten andere Dienste nicht darauf zugreifen oder Anforderungen an sie senden. Stattdessen sollte die Anforderung an eine andere Instanz der Anwendung gesendet werden, die bereits ausgeführt wird oder später gestartet wird. Darüber hinaus sollte das System Ihre Anwendung auf verlorene Funktionalität zurücksetzen.

Standardmäßig sendet Kubernetes Datenverkehr an den Pod, wenn alle Container in den Herden ausgeführt werden, und lädt die Container neu, wenn sie abstürzen. Für den Anfang kann dieses Standardverhalten des Systems recht gut sein, aber Sie können die Zuverlässigkeit Ihrer Produktbereitstellung durch benutzerdefinierte Integritätsprüfungen erhöhen.



Glücklicherweise können Sie dies mit Kubernetes ganz einfach tun, sodass es keine Ausreden gibt, solche Überprüfungen zu ignorieren. Kubernetes bietet zwei Arten von Health Check-Tests an. Es ist wichtig, die Unterschiede in den einzelnen Anwendungen zu verstehen.

Der Readiness Readiness Test soll Kubernetes mitteilen, dass Ihre Anwendung für den Datenverkehr bereit ist. Bevor der Dienst Datenverkehr an den Pod senden kann, muss Kubernetes überprüfen, ob die Verfügbarkeitsprüfung erfolgreich ist. Wenn der Bereitschaftstest fehlschlägt, sendet Kubernetes keinen Datenverkehr mehr an den Pod, bis der Test erfolgreich ist.

Der Liveness Viability Test teilt Kubernetes mit, ob Ihre Anwendung aktiv oder tot ist. Im ersten Fall lässt Kubernetes ihn in Ruhe, im zweiten Fall entfernt er die tote Kapsel und ersetzt sie durch eine neue.

Stellen wir uns ein Szenario vor, in dem Ihre Anwendung 1 Minute benötigt, um sich aufzuwärmen und auszuführen. Ihr Dienst wird erst gestartet, wenn die Anwendung vollständig geladen und gestartet wurde, obwohl der Workflow bereits begonnen hat. Außerdem treten Probleme auf, wenn Sie den Umfang dieser Bereitstellung auf mehrere Kopien erhöhen möchten, da diese Kopien erst dann Datenverkehr erhalten sollten, wenn sie vollständig bereit sind. Standardmäßig sendet Kubernetes jedoch unmittelbar nach dem Start der Prozesse im Container Datenverkehr.

Mit dem Bereitschaftstest wartet Kubernetes, bis die Anwendung vollständig gestartet ist, und erst danach kann der Dienst Datenverkehr an eine neue Kopie senden.



Stellen wir uns ein anderes Szenario vor, in dem eine Anwendung für eine lange Zeit einfriert und die Bearbeitung von Anforderungen beendet. Da der Prozess weiterhin ausgeführt wird, berücksichtigt Kubernetes standardmäßig, dass alles in Ordnung ist, und sendet weiterhin Anforderungen an den nicht funktionierenden Pod. Bei Verwendung von Liveness erkennt Kubernetes jedoch, dass die Anwendung keine Anforderungen mehr bearbeitet, und startet standardmäßig einen nicht funktionierenden Pod neu.



Überlegen Sie, wie Sie Bereitschaft und Vitalität testen können. Es gibt drei Testmethoden: HTTP, Befehl und TCP. Sie können jeden von ihnen zur Überprüfung verwenden. Die gebräuchlichste Benutzertestmethode ist eine HTTP-Sonde.

Auch wenn Ihre Anwendung kein HTTP-Server ist, können Sie in Ihrer Anwendung einen einfachen HTTP-Server erstellen, um mit dem Liveness-Test zu interagieren. Danach pingt Kubernetes den Ping an den Pod. 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.



Bei Tests mit Command führt Kubernetes den Befehl in Ihrem Container aus. Wenn der Befehl mit einem Exit-Code von Null zurückgegeben wird, wird der Container als fehlerfrei markiert. Andernfalls wird der Container als "krank" markiert, wenn die Exit-Statusnummer zwischen 1 und 255 liegt. Diese Testmethode ist nützlich, wenn Sie den HTTP-Server nicht starten können oder möchten, aber einen Befehl ausführen können, der den Zustand Ihrer Anwendung überprüft.



Der letzte Überprüfungsmechanismus ist der TCP-Test. Kubernetes versucht, eine TCP-Verbindung am angegebenen Port herzustellen. Wenn dies möglich ist, wird der Behälter als gesund angesehen, wenn nicht, ist er nicht lebensfähig. Diese Methode kann nützlich sein, wenn Sie ein Skript verwenden, in dem das Testen mit einer HTTP-Anforderung oder Befehlsausführung nicht sehr gut funktioniert. Die Hauptdienste für die Überprüfung mit TCP sind beispielsweise gRPC oder FTP.



Tests können auf verschiedene Arten mit verschiedenen Parametern konfiguriert werden. Sie können festlegen, wie oft sie ausgeführt werden sollen, wie hoch die Schwellenwerte für Erfolg und Misserfolg sind und wie lange auf Antworten gewartet werden soll. Weitere Informationen finden Sie in der Dokumentation zum Bereitschaftstest. Es gibt jedoch einen sehr wichtigen Punkt beim Einrichten des Liveness-Tests - die anfängliche Einstellung der initialDelaySeconds-Testverzögerung. Wie bereits erwähnt, führt der Fehler dieses Tests zu einem Neustart des Moduls. Daher müssen Sie sicherstellen, dass der Test erst gestartet wird, wenn die Anwendung betriebsbereit ist. Andernfalls wird der zyklische Neustart gestartet. Ich empfehle die Verwendung der P99-Startzeit oder der durchschnittlichen Startzeit der Anwendung aus dem Puffer. Vergessen Sie nicht, diesen Wert als einzustellenda die Startzeit Ihrer Anwendung schneller oder langsamer wird.

Die meisten Experten werden bestätigen, dass Health Check eine obligatorische Prüfung für jedes verteilte System ist, und Kubernetes ist keine Ausnahme. Die Verwendung der Integritätsprüfung der Dienste gewährleistet zuverlässige und betriebsbereite Kubernetes und macht keine Arbeit für Benutzer.

Wird sehr bald fortgesetzt ...

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 wir für Sie erfunden haben: 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?