Autor: Fabian Peter
Veröffentlicht: 01.07.2023
Lese-Dauer: 3 Minuten

Kubernetes: Liveness und Readiness Probes erklärt

Wissenswertes

Basiswissen

Wie kommt eine externe Anfrage zu einem Container?

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 ReadinessProbes 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.

Der Unterschied zwischen StartupProbe, LivenessProbe und ReadinessProbe

StartupProbe

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.

LivenessProbe

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.

ReadinessProbe

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 konfigurieren

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.