Die PostgreSQL-Datenbank hat Probleme: Latenz verzehnfacht. API-Pods reagieren in acht Sekunden statt in zweihundert Millisekunden. Die HTTP-Liveness-Prüfung läuft nach drei Sekunden ab. Kubernetes startet die Pods neu – Verbindungsverlust, kalter Cache, neuer Sturm auf die Datenbank. Der Vorfall wird zu einer Kaskade, wenn die Anwendung damit zufrieden gewesen wäre, vorübergehend aus dem Load Balancer entfernt zu werden.
Sonden sind das Thermometer, anhand dessen das Kubelet entscheidet: Datenverkehr senden, warten oder killen. Wenn sie schlecht reguliert sind, verwandeln sie die Verschlechterung in eine Katastrophe. Das Szenario kommt häufig vor, weil Tutorials eine einzelne „/health“-Probe für alle Rollen kopieren – und weil Liveness konfiguriert wird, bevor das Team den Unterschied zur Bereitschaft versteht.
Die gute Nachricht: Eine gut kalibrierte Sonde kostet einen halben Arbeitstag. Das Schlechte: Eine aggressive Untersuchung kann stundenlange Crashloops kosten und einen Datenbankfehler verschlimmern, der selbst hätte behoben werden können.
Lebendigkeit, Bereitschaft, Startup: drei unterschiedliche Signale
| Sonde | Wirkung | Frage |
|---|---|---|
| Bereitschaft | Aus Dienst entfernen | „Kann ich jetzt Traffic empfangen?“ » |
| Lebendigkeit | Starten Sie den Pod neu | „Ist der Prozess ohne Wiederherstellung tot? » |
| Startup | Blockiert andere beim Start | „Ist der Startvorgang der Anwendung abgeschlossen?“ » |
Klassischer Fehler: Nur eine „/health“-URL für alle drei Rollen. Unter Last versagt die Bereitschaft und die Lebendigkeit tötet – doppelte Bestrafung. Readiness sollte den Pod aus dem Datenverkehr entfernen, wenn eine Abhängigkeit langsam ist; Liveness sollte nur dann eingreifen, wenn der Prozess tatsächlich stecken bleibt und nicht nur langsam.
Der Neustart eines langsamen Pods beschleunigt eine gesättigte Datenbank nicht – es führt zu Chaos.
Für eine Bereitstellung ohne anfängliche Liveness reichen häufig Bereitschaft und Prometheus-Benachrichtigungen aus. Fügen Sie Lebendigkeit hinzu, wenn Sie „langsam, aber lebendig“ klar von „tot ohne Erholung“ unterscheiden.
Timeouts, Zeitraum und Fehlerschwelle kalibrieren
Drei Parameter bestimmen die Aggressivität:
- timeoutSeconds muss unter normaler Last 99 Perzentil überschreiten – nicht unter idealer Laborlast.
- periodSeconds legt die Häufigkeit der Überprüfungen fest; Zu aggressiv vervielfacht die Unfallbelastung.
- failureThreshold × period = Verzögerung vor Aktion; Bei drei Ausfällen alle zehn Sekunden verbleiben 30 Sekunden bis zum Neustart.
Beispiel: Wenn Ihre Schnittstelle unter normaler Last in 400 ms bei Perzentil 99 reagiert, lässt ein Timeout von drei Sekunden einen komfortablen Spielraum. Wenn die Basis langsamer wird und das 99. Perzentil auf sechs Sekunden ansteigt, versagt die Bereitschaft – aber die Lebendigkeit sollte nicht töten, solange der Prozess noch reagiert.
Endpunktgesundheit: getrennt, live und betriebsbereit
Separate Steuerelemente in Ihrer Anwendung:
- /health/live: Der Prozess antwortet – keine starken Basisaufrufe.
- /health/ready: Datenbank erreichbar, Hot-Cache, Migrationen abgeschlossen.
Setzen Sie keinen teuren Basisanruf in die Liveness. Wenn PostgreSQL nicht verfügbar ist, sollten alle Pods nicht in die Absturzschleife geraten – die Bereitschaft reicht aus, sie während des Ausfalls aus dem Dienst zu entfernen.
Konfigurieren Sie eine startupProbe mit dreißig Fehlern alle zehn Sekunden, wenn der Startvorgang länger als dreißig Sekunden dauert: Dadurch bleiben fünf Minuten Startzeit ohne unerwünschte Lebendigkeit. Unverzichtbar für Java-Anwendungen, Startmigrationen oder das Laden eines großen Caches.
Probes und europäisch verwaltetes Kubernetes
Bei verwalteten Kubernetes OVHcloud, Scaleway Kapsule oder anderen europäischen Angeboten verwaltet die Kontrollebene die Sonden auf der Kubelet-Seite – Ihre Verantwortung liegt weiterhin für den Inhalt der Kontrolle und deren Last.
Wachsamkeitspunkte:
- Nebencontainer, die die Startlatenz erhöhen;
- Niedrige Prozessorlimits führen zu Zeitüberschreitungen unter Last;
- Verwechslung zwischen der Steuerung des externen Lastverteilers und der Pod-Sonde – zwei unterschiedliche Mechanismen.
Vergleichen Sie Kubernetes-Angebote über das Verzeichnis und den Vergleich. Wenn Sie die Bereitstellung in einem kleinen Cluster durchführen, lesen Sie auch Kubernetes: Brauchen Sie es wirklich?, bevor Sie einem übergroßen Stack die Komplexität der Sonden hinzufügen.
Beobachtbarkeit: Neustarts und Tests korrelieren
Nützliche Vorfallmetriken:
- Zähler pro Bereitstellung neu starten;
- „Ungesunde“ Ereignisse in „kubectl beschreiben Pod“;
– Kubelet-Protokolle zum Zeitpunkt des Neustarts.
Empfohlenes Runbook: if crashloop – Liveness vorübergehend deaktivieren, nachdem bestätigt wurde, dass der Prozess kein Zombie ist; Beheben Sie die Grundursache (langsame Basis, erschöpfter Pool); Reaktivierung mit gelockerten Schwellenwerten. Deaktivieren Sie niemals die Liveness in der Produktion, ohne parallel zur Verfügbarkeit zu warnen.
Die Korrelation von Neustarts und Basislatenz in der Produktion offenbart oft eine übermäßig aggressive Untersuchung – und keinen Anwendungsfehler. Informationen zur Instrumentierung des 99-Perzentils vor dem Festlegen von Zeitüberschreitungen finden Sie unter Prometheus-Metriken.
Der Gipfel: Neustart als fauler Reflex
Eine nützliche Sonde entfernt den Datenverkehr. Ein Lazy-Probe startet neu und hofft, dass das Problem behoben wird. Der Unterschied liegt in der Live/Ready-Trennung, den auf realen Messungen kalibrierten Timeouts und der Disziplin, eine in einem Forum gefundene Konfiguration nicht zu kopieren, ohne sie an Ihre Auslastung anzupassen.
Entscheide dich und gehe ohne blinden Fleck voran
Innerhalb eines halben Tages können Sie die Sonden wieder in den Dienst der Stabilität stellen:
- Implementieren Sie separate Live- und Ready-Endpunkte – Live ohne Basisaufruf, bereit mit kritischen Abhängigkeiten.
- Konfigurieren Sie eine StartupProbe, wenn der Startvorgang länger als 30 Sekunden dauert. Ohne sie beendet Liveness die Anwendung, bevor der Startvorgang abgeschlossen ist.
- Legen Sie Zeitüberschreitungen fest vom 99. Perzentil, gemessen unter normaler Last – keine Standardeinstellung für das Tutorial.
- Test in der Vorproduktion mit simulierter Basensättigung: Pods müssen NotReady bestehen, nicht CrashLoopBackOff.
- Korrelation von Neustarts und Basislatenz in der Produktion; Passen Sie den FailureThreshold an, bevor Sie Replikate hinzufügen.
- Vergleichen Sie die Kubernetes-Angebote über das Verzeichnis, wenn Sie auf einen europäischen verwalteten Cluster migrieren.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Lebendigkeit und Bereitschaft?
Readiness entfernt den Pod aus dem Dienst, ohne ihn zu beenden – geeignet, wenn eine Abhängigkeit vorübergehend nicht verfügbar ist. Liveness startet den Container neu; Behalten Sie es für unheilbare Blockaden auf. Eine Verwechslung der beiden führt zu unnötigen Neustarts während einer vorübergehenden Verschlechterung.
Warum verursacht meine Lebendigkeit einen Crashloop?
Zu kurze Zeitüberschreitungen, langsamer Endpunkt unter Last oder Steuerung, die dieselbe gesättigte Datenbank durchläuft. Das Kubelet tötet die Kapsel, während die Bereitschaft ausreichen würde. Lockern Sie die Schwellenwerte oder verschieben Sie die Grundlinienkontrolle auf „Nur Bereitschaft“.
Wofür wird „startupProbe“ verwendet?
Es verzögert die Lebendigkeit und Bereitschaft während langer Startvorgänge – Migrationen, Cache, Remote-Verbindungen. Ohne sie beendet Liveness die Anwendung, bevor der Startvorgang abgeschlossen ist. Konfigurieren Sie es, sobald ein Pod länger als 30 Sekunden braucht, um betriebsbereit zu sein.
HTTP oder Exec für eine Sonde?
HTTP auf einem leichtgewichtigen Anwendungsendpunkt ist vorzuziehen. Exec- oder TCP-Socket überprüfen den Geschäftszustand kaum; Reservieren Sie sie als letzten Ausweg, wenn HTTP nicht verfügbar ist.
Ein nützlicher Test unterbricht den Datenverkehr – ein langsamer Test startet neu und hofft, dass das Problem behoben wird.