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.
Compliance leicht gemacht: Die ISO27001 als Schlüssel zur Einhaltung gesetzlicher Vorschriften Die Einhaltung gesetzlicher Anforderungen und Datenschutzrichtlinien ist für Unternehmen eine ständige …
ayedo Cloud: Performance-Optimierung für cloud-native Anwendungen Die Leistung cloud-nativer Anwendungen ist ein entscheidender Faktor für den Geschäftserfolg. ayedo Cloud bietet spezialisierte …
Der Einfluss der ISO 27001 Zertifizierung auf den Datenschutz und die Datenintegrität Datenlecks und Cyber-Angriffe sind heutzutage allgegenwärtige Bedrohungen, die Unternehmen jeder Größe betreffen …
Kubernetes hat sich als eine Schlüsseltechnologie für die Verwaltung und den Betrieb von containerisierten Anwendungen etabliert, einschließlich solcher, die in den Bereichen Internet der Dinge (IoT) …
Kubernetes kann einer Software- oder Digitalisierungs-Agentur auf verschiedene Weise helfen, zusätzliche Umsätze mit dem hochverfügbaren Betrieb von Software zu erwirtschaften: Hochverfügbarkeit: …
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →
Unsere Cloud-Experten beraten Sie gerne und individuell.
Wir antworten in der Regel innerhalb weniger Stunden auf Ihre Nachricht.
Zu Gen-Z für E-Mail? Einfach mal Discord versuchen. Unter +49 800 000 3706 können Sie unter Angabe Ihrer Kontaktdaten auch einen Rückruf vereinbaren. Bitte beachten Sie, dass es keine Möglichkeit gibt, uns telefonisch direkt zu erreichen. Bitte gar nicht erst versuchen. Sollten Sie dennoch Interesse an synchroner Verfügbarkeit via Telefon haben, empfehlen wir Ihnen unseren Priority Support.