You build it, we run it
Testen Sie ayedo Fleet 30 Tage kostenlos.
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.
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.
Testen Sie ayedo Fleet 30 Tage kostenlos.
Unsere Container-Experten beraten Sie gerne und individuell.
✉ hello@ayedo.de · ☎ +49 681 3875 3330
Wir antworten in der Regel innerhalb weniger Stunden auf Ihre Nachricht.