Was ist der Unterschied zwischen einer Liveness Probe und einer Readiness Probe, und was machen Leute damit falsch?

Eine Readiness Probe steuert, ob ein Pod Traffic bekommt, eine Liveness Probe steuert, ob das Kubelet den Container neu startet. Der klassische Fehler ist, Liveness auf eine Downstream-Dependency zeigen zu lassen, sodass eine langsame Datenbank jeden Pod in einer Schleife neu startet und aus einem Teilausfall einen Totalausfall macht. Liveness sollte nur prüfen, dass der Prozess lebt und nicht deadlocked ist. Für langsam startende Anwendungen nimm eine Startup Probe.

Readiness entscheidet, ob der Pod in den Service-Endpoints steht, Liveness entscheidet, ob das Kubelet den Container killt und neu startet. Der Fehler, den ich real gesehen habe, war ein Team, dessen Liveness-Endpoint die Datenbank geprüft hat. Die Datenbank wurde langsam, jeder Pod hat ungefähr gleichzeitig die Liveness verfehlt, das ganze Deployment ging in eine Restart-Schleife, und statt degradierter Lesezugriffe hatten wir gar nichts mehr, plus eine Thundering Herd kalter Verbindungen beim Hochkommen. Liveness sollte fast langweilig sein: Kann der Prozess einen trivialen Handler bedienen, hängt die Event Loop nicht. Alles zu Dependencies gehört in die Readiness, denn einen Pod aus der Rotation zu nehmen ist reversibel und billig. Das andere, was ich immer prüfe, ist das Timing. Braucht die App 45 Sekunden zum Warmlaufen der Caches, nimm entweder eine Startup Probe oder setz initialDelaySeconds und failureThreshold passend, sonst hast du eine Maschine gebaut, die niemals fertig booten kann.