LivenessProbe und ReadinessProbe anschaulich erklärt.
Probes sind Checks, die das Kubelet einer Node in oder gegen einen Pod ausführt um dessen Status zu überprüfen.
Mit Hilfe der Probes kann zum Beispiel überprüft werden, ob der Container auf einen bestimmten Port lauscht oder ob Programme, die im Container ausgeführt werden, einen bestimmten Exit-Code zurückgeben.
Das Ergebnis einer Probe wird vom Kubelet interpretiert und triggert bestimmte Lifecycle-Events eines Pods. Schlägt eine Probe zum Beispiel fehl kann das ein Signal für das Kubelet sein den Pod neuzustarten.
Übliche Prüfungen, die mit Hilfe von Probes durchgeführt werden um den Status eines Pods zu bestimmen sind unter anderem:
Ein Service sorgt dafür, dass eine Anfrage (z.B. ein HTTP-Request, der durch den Ingress reinkommt) einen Pod erreicht der bereit ist eine Anfrage zu verarbeiten. Diese “Bereitschaft” kann mit Liveness- und Readiness Probes ermittelt werden. Ist ein Pod nicht “Ready” wird dieser aus dem Service Objekt, das sich wie ein kleiner, cluster-interner Loadbalancer verhält, entfernt und erst wieder hinzugefügt wenn dieser bereit ist Anfrage zu verarbeiten. Ist ein Pod nicht “Live” wird er (bzw. der relevante Container des Pods) neugestartet.
Die Liveness und Readiness eines Pods wird durch verschiedene Probes bestimmt, die im Folgenden näher erklärt werden.
Die StartupProbe prüft ob ein Pod überhaupt startet. Erst wenn dies der Fall ist wird eine Liveness- bzw. ReadinessProbe durchgeführt.
Schlägt die StartupProbe fehl, wird der Container neu gestartet.
Viele Anwendungen, insbesondere Langzeit-Prozesse, können sich während Ihrer Laufzeit aufhängen ohne zu terminieren. In diesen Fällen hilft nur ein Neustart des Prozesses um seine übliche Funktionalität wiederherzustellen.
Die LivenessProbe prüft, z.B. durch den Aufruf eines HTTP- oder TCP-Endpoints im Container, ob ein Container sich aufgehängt hat oder live ist.
Schlägt die LivenessProbe fehl, wird der Container neu gestartet.
Manchmal sind Anwendungen zwar funktional (d.h. der Prozess tut fehlerfrei seinen Dienst), aber dennoch nicht in der Lage Anfragen zu bedienen. Das kann z.B. daran liegen, dass eine externe Abhängigkeit wie eine Datenbank nicht verfügbar ist.
In solchen Fällen will man den Prozess eigentlich nicht neu starten, sondern nur verhindern, dass er Anfragen erhält, da er sie ohnehin nicht bearbeiten kann.
Die ReadinessProbe prüft, ob ein Container bereit (also ready) ist externe Anfragen korrekt zu verarbeiten. Ist dies nicht der Fall, wird Kubernetes keine Anfragen an diesen Pod durch ein Service Object zulassen. Der Container wird nicht neu gestartet, aber er erhält auch keine Anfragen mehr.
Liveness und Readiness Probes sollten für jede Anwendung individuell konfiguriert werden. Die Standardeinstellungen sind nicht für jeden Dienst geeignet.
Hat Ihre Anwendung eine lange Startup-Zeit bevor der Container live ist (also der Haupt-Prozess läuft), z.B. weil beim Container-Start eine größere Menge Daten geladen werden muss, konfigurieren Sie eine ausreichend großzügige StartupProbe um zu verhindern, dass der Container frühzeitig durch die LivenessProbe abgeschossen wird.
Die LivenessProbe ruft üblicherweise einen HTTP-Endpoint wie z.B. /health im Container auf, um festzustellen ob der Container live ist. Diese Probe sollte lediglich die korrekte Funktionsweise des Prozesses attestieren aber nicht auf externe Abhängigkeiten wie Datenbanken prüfen. Haben Sie zum Beispiel php und nginx im gleichen Container laufen um eine API bereitzustellen, dann sollte die LivenessProbe lediglich die korrekte Funktionsweise von nginx wiedergeben (d.h. der Webserver beantwortet Anfragen).
Im Falle unserer PHP Anwendung nutzen Sie die ReadinessProbe dafür zu prüfen, ob die Anwendung fachlich korrekt funktioniert: kann eine Verbindung zur Datenbank aufgebaut werden, ist Redis erreichbar, werden alle statischen Assets korrekt geladen, etc. Fehlgeschlagene ReadinessProbes führen nicht zum Container-Neustart, sodass externe Abhängigkeiten zur Laufzeit des Containers wiederhergestellt werden können.
Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.
Wer Anwendungen produktiv betreibt, braucht keine schönen Dashboards, sondern harte Daten. Performance-Probleme entstehen nie dann, wenn Zeit für Debugging ist. Sie kommen genau dann, wenn Systeme …
Die Frage stellt sich immer wieder. Entwicklerteams liefern Features, optimieren Releases, bauen saubere Architekturen — und dann hängen sie trotzdem noch in der Infrastruktur. Kubernetes-Cluster …
Die meisten IIoT-Projekte scheitern nicht an den Maschinen. Die Sensorik läuft. Die Steuerungen liefern Daten. Die Netzwerke übertragen Pakete. Das Problem beginnt eine Ebene höher: Die Daten landen …
Softwareentwicklung endet nicht beim Code Wer heute Applikationen für Kunden entwickelt, steht schnell vor dem nächsten Thema: Wie wird die Software produktiv betrieben? Wo laufen Staging und …
Warum IT und OT zusammenwachsen müssen In modernen Industrieumgebungen entstehen an der Schnittstelle zwischen Produktion und Unternehmens-IT zunehmend komplexe Datenströme. Produktionsanlagen, …
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →