Was ist der Unterschied zwischen einer Liveness Probe und einer Readiness Probe?

Eine fehlschlagende Liveness Probe lässt das kubelet den Container neu starten, sie ist also für einen Prozess, der hängt und sich nicht selbst erholen kann. Eine fehlschlagende Readiness Probe nimmt den Pod aus den Service-Endpoints, sodass er keinen Traffic mehr bekommt, lässt ihn aber laufen. Startup Probes decken langsam bootende Apps ab, damit ein langer Start nicht die Liveness auslöst. Liveness sollte den Prozess selbst prüfen, nicht seine Dependencies.

Readiness beantwortet kann dieser Pod gerade Traffic annehmen, Liveness beantwortet ist dieser Prozess nicht mehr zu retten. Fällt Readiness aus, nimmt der Endpoints Controller den Pod aus dem Service, der Traffic stoppt, und der Pod läuft weiter und kann sich erholen. Fällt Liveness aus, killt das kubelet den Container und startet ihn neu. Der Fehler, den ich am häufigsten sehe, ist ein Liveness-Endpoint, der Datenbank und Cache prüft. Dann wackelt die Datenbank dreißig Sekunden, alle Replicas fallen gleichzeitig durch die Liveness, das komplette Deployment startet neu, und jetzt hast du einen kalten Cache und eine Thundering Herd zusätzlich zum ursprünglichen Problem. Liveness prüft also nur, ob der Prozess antwortet, und Dependency-Checks gehören in die Readiness, weil vorübergehender Traffic-Verlust behebbar ist. Für einen Service, der neunzig Sekunden zum Aufwärmen braucht, ergänze ich eine Startup Probe mit großzügigem Failure Threshold, damit Liveness erst greift, wenn er oben ist. Readiness treibt außerdem Rolling Updates, also sorge ich dafür, dass sie zu Beginn des Shutdowns auf not ready kippt, bevor der Prozess keine Verbindungen mehr annimmt.