Was passiert, wenn die Liveness-Prüfung in Kubernetes fehlschlägt?

Wenn der Pod den Liveness-Test nicht besteht, führt Kubernetes die im Manifest des Pods angegebene Aktion aus. Standardmäßig wird der Container neu gestartet.

Mögliche Aktionen bei einem Fehler im Liveness-Test:

• Neustart: Neustart des Containers im Pod. Diese Aktion ist die Standardeinstellung.
• Keine: Kubernetes ergreift keine Maßnahmen bei einem Fehler im Liveness-Test. Der Container bleibt in seinem aktuellen Zustand (Running oder Crashing).
• Befehl ausführen: Ausführen eines bestimmten Befehls im Container. Wenn der Befehl mit einem Rückgabewert ungleich Null endet, gilt der Liveness-Test als fehlgeschlagen.

Szenario mit der Standardaktion (Neustart):

1. kubelet auf dem Knoten überprüft regelmäßig den Container mittels des Liveness-Tests.
2. Die Bedingung des Liveness-Tests ist nicht erfüllt (z.B. HTTP-Server antwortet nicht, Befehl endet mit Fehler).
3. kubelet registriert den Fehler des Tests.
4. Nach einer bestimmten Anzahl von Fehlschlägen (konfiguriert durch die Parameter failureThreshold, initialDelaySeconds, periodSeconds, timeoutSeconds) erkennt kubelet, dass der Container defekt ist.
5. kubelet sendet das Signal SIGKILL an den defekten Container.
6. Der Container wird beendet.
7. kubelet startet den Container im selben Pod neu.
8. Der Liveness-Test wird fortgesetzt.

Es ist wichtig, den Liveness-Test vom Readiness-Test zu unterscheiden. Der Readiness-Test bestimmt, ob der Container bereit ist, Traffic zu empfangen. Ein Fehler im Readiness-Test führt dazu, dass der Service keinen Traffic an diese Pod-Instanz sendet, aber der Container wird nicht neu gestartet. Ein Fehler im Liveness-Test zeigt eine Fehlfunktion an und erfordert einen Neustart.

# Beispiel für einen Liveness-Test in spec.containers
containers:
  - name: my-container
    image: my-image:latest
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15 # Verzögerung vor dem ersten Test
      periodSeconds: 20      # Intervall zwischen den Tests
      timeoutSeconds: 5       # Wartezeit auf Antwort
      failureThreshold: 3     # Anzahl der Fehlschläge vor Neustart