35 Implementierung von Probes und Health Checks in Kubernetes

Configure Liveness, Readiness and Startup Probes

In Kubernetes sind Probes definierte Mechanismen, die verwendet werden, um den Status eines Pods zu überprüfen. Sie bestimmen, ob eine Anwendung innerhalb eines Containers korrekt läuft. Es gibt drei Arten von Probes: Liveness Probes, Readiness Probes und Startup Probes.

Liveness Probes überprüfen, ob eine Anwendung innerhalb eines Containers noch läuft. Wenn diese Probes fehlschlagen, wird der kubelet-Prozess den Container neu starten, in der Annahme, dass er nicht mehr reagiert.

Readiness Probes bestimmen, ob ein Container bereit ist, Anfragen zu bearbeiten. Wenn ein Container nicht ready ist, werden keine Anfragen über den Kubernetes Service zu diesem Container geleitet.

Startup Probes sind speziell dafür konzipiert, zu erkennen, ob eine Anwendung länger zum Starten benötigt. Diese verhindern, dass Liveness und Readiness Probes eingreifen, bevor die Anwendung vollständig hochgefahren ist.

Zur Implementierung der Probes werden Konfigurationsoptionen im Pod-Specification File definiert. Probes können HTTP-Get-Anfragen, TCP-Socket-Verbindungen oder spezifische Befehle, die im Container ausgeführt werden, verwenden, um den Status zu überprüfen.

Eine korrekte Implementierung der Probes ist entscheidend für die Aufrechterhaltung der Zuverlässigkeit und Verfügbarkeit von Anwendungen in Kubernetes. Sie tragen wesentlich zur Automatisierung der Fehlerbehandlung und zu einem robusten Systemverhalten bei.

# Beispiel für LivenessProbe mit httpGet
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: up
      value: true

# Beispiel für LivenessProbe mit tcpSocket
livenessProbe:
  tcpSocket:
    port: 8080

# Beispiel für LivenessProbe mit exec
livenessProbe:
  exec:
    command:
    - cat
    - /app/is_alive.txt

35.1 Startup Probe in Kubernetes

Startup Probes sind Gesundheitschecks in Kubernetes, die überprüfen, ob ein Container erfolgreich gestartet ist. Sie unterscheiden sich von Liveness und Readiness Probes dadurch, dass sie ausschließlich während des Startvorgangs aktiv sind. Dies ist besonders nützlich für Anwendungen, die längere Startzeiten benötigen.

Die korrekte Implementierung von Startup Probes erhöht die Stabilität und Verfügbarkeit langsam startender Dienste, indem sie optimale Startzeiten sicherstellt und bei Bedarf einen Neustart der Anwendung veranlasst.

35.1.1 Verwendung von Startup Probes

Startup Probes sind nützlich in Situationen, in denen eine Anwendung einen komplexen Startvorgang hat, der mehr Zeit in Anspruch nehmen kann, als eine typische Liveness Probe erlaubt. Ohne eine Startup Probe könnte der Kubelet fälschlicherweise annehmen, dass der Container nicht reagiert und ihn neu starten, was den Startvorgang weiter verzögert.

Hier ist ein typisches Szenario, in dem Startup Probes verwendet werden:

• Eine Anwendung benötigt mehrere Minuten, um Daten aus einer externen Datenquelle zu laden.
• Eine Liveness Probe könnte den Startvorgang als fehlgeschlagen betrachten, da die Anwendung nicht innerhalb der erwarteten Zeit reagiert.
• Eine Startup Probe gibt der Anwendung ausreichend Zeit, um den Initialisierungsprozess abzuschließen, bevor Liveness Probes aktiviert werden.

35.1.2 Konfigurationsbeispiel

Die Konfiguration einer Startup Probe erfolgt im Pod-Manifest. Hier ist ein Beispiel für eine Startup Probe, die eine HTTP-GET-Anfrage verwendet:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example/image
    ports:
    - containerPort: 8080
    startupProbe:
      httpGet:
        path: /up
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30

Das bedeutet, dass die Anwendung bis zu 150 Sekunden (30 x 5) nach dem ersten Verzögerungsintervall hat, um zu starten, bevor der Container neu gestartet wird.

35.1.3 Vorteile der Verwendung von Startup Probes

• Verhindert vorzeitige Neustarts: Stellt sicher, dass Anwendungen, die langsam starten, nicht vorzeitig als fehlgeschlagen markiert und neu gestartet werden.
• Anpassbare Kontrolle: Ermöglicht Entwicklern, spezifische Startbedingungen für ihre Anwendungen zu definieren.
• Verbesserte Stabilität: Reduziert die Wahrscheinlichkeit instabiler Zustände durch kontinuierliche Neustarts während der Anwendungsinitialisierung.

35.1.4 Beispiel mit nginx

Nginx hat standardmäßig keinen spezifischen Health-Check-Endpunkt. Normalerweise antwortet Nginx auf alle Anfragen an den Server mit der entsprechenden Konfiguration, sofern der Dienst läuft. Sie können jedoch einfach einen Health-Check-Endpunkt in Nginx definieren, indem Sie eine bestimmte Location in der Konfigurationsdatei (nginx.conf) einrichten.

35.1.4.1 Schritt 1: Konfigurieren Sie Nginx

Fügen Sie eine location-Direktive in Ihrer server-Konfiguration hinzu, die speziell für Health-Checks vorgesehen ist:

server {
    listen 80;
    server_name localhost;

    location /up {
        access_log off;
        return 200 'nginx is healthy\n';
    }

    # ... weitere Konfiguration ...
}

Diese location blockiert den Zugriff auf den Pfad /up und gibt einfach einen 200 OK Status mit einer Nachricht zurück, was angibt, dass Nginx läuft und gesund ist.

35.1.5 Schritt 2: Erstellen Sie eine Startup Probe für Nginx in Kubernetes

Angenommen, Sie haben die obige Nginx-Konfiguration in einem Container laufen, könnten Sie folgende Startup Probe für diesen Container in Ihrem Kubernetes-Pod-Spezifikation definieren:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
    startupProbe:
      httpGet:
        path: /up
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30

In diesem Beispiel wird die Startup Probe den /healthz Endpunkt Ihres Nginx-Servers überprüfen. Nach einer Anfangsverzögerung von 10 Sekunden prüft die Probe alle 5 Sekunden, ob Nginx gestartet ist. Wenn Nginx innerhalb von 30 Versuchen nicht reagiert, nimmt Kubernetes an, dass ein Fehler vorliegt, und wird entsprechende Maßnahmen ergreifen.

Diese Konfiguration könnte hilfreich sein, wenn Sie eine Nginx-Instanz in einem Container haben, der eine signifikante Zeit zum Starten benötigt, beispielsweise aufgrund einer langen Initialisierung oder weil er auf abhängige Dienste wartet.

35.2 Readiness Probe in Kubernetes

Readiness Probes werden in Kubernetes verwendet, um zu überprüfen, ob ein Container bereit ist, Traffic zu empfangen. Sie sind von Liveness Probes zu unterscheiden, welche lediglich prüfen, ob ein Container noch aktiv ist. Readiness Probes sind dafür zuständig, den Netzwerkverkehr zu Containern zu leiten, die einsatzbereit sind und korrekt arbeiten.

Diese Prüfungen sind für die Verkehrslenkung zu Anwendungen in einem Kubernetes-Cluster von großer Bedeutung. Sie steigern die Zuverlässigkeit und Stabilität von Services, indem sie garantieren, dass nur vollständig hochgefahrene und funktionsfähige Container Anfragen erhalten.

35.2.1 Zweck einer Readiness Probe

Der Hauptzweck der Readiness Probe ist es sicherzustellen, dass ein Pod nicht in den Service-Endpunkten erscheint, bevor er tatsächlich bereit ist, Anfragen zu verarbeiten. Dies verhindert, dass eingehender Verkehr zu einem Container geleitet wird, der noch mit dem Starten seiner Anwendung oder dem Laden von großen Datenmengen beschäftigt ist.

35.2.2 Readiness Probe Konfiguration

Readiness Probes können über verschiedene Methoden konfiguriert werden:

• HTTP GET: Kubernetes führt eine HTTP-GET-Anfrage an den Container durch.
• TCP Socket: Kubernetes versucht, eine TCP-Verbindung zum Container herzustellen.
• Exec Command: Kubernetes führt einen Befehl im Container aus, und der Status des Containers hängt vom Exit-Code des Befehls ab.

Hier ist ein Beispiel für eine Readiness Probe mit einer HTTP-GET-Anfrage in einer Pod-Spezifikation:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app-container
    image: my-app:latest
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      successThreshold: 1
      failureThreshold: 3

In diesem Beispiel prüft Kubernetes, ob der Container bereit ist, indem eine HTTP-GET-Anfrage an den Endpunkt /ready auf Port 8080 gesendet wird. Nach einer Anfangsverzögerung von 5 Sekunden wird die Probe alle 5 Sekunden ausgeführt. Der Container gilt nach einer erfolgreichen Antwort als bereit. Wenn die Probe dreimal fehlschlägt, wird der Container aus den Service-Endpunkten entfernt.

35.2.3 Beispiel mit einem Custom Script

Manchmal muss die Bereitschaft eines Containers mit spezifischeren Bedingungen geprüft werden. Hierfür kann man ein Skript verwenden, das als Exec Command ausgeführt wird. Angenommen, Sie haben ein Skript check-ready.sh, das überprüft, ob bestimmte Bedingungen erfüllt sind:

apiVersion: v1
kind: Pod
metadata:
  name: custom-app
spec:
  containers:
  - name: custom-app-container
    image: custom-app:latest
    readinessProbe:
      exec:
        command:
        - /bin/bash
        - -c
        - /path/to/check-ready.sh
      initialDelaySeconds: 10
      periodSeconds: 5
      successThreshold: 1
      failureThreshold: 5

In diesem Szenario führt der Kubelet das Skript check-ready.sh im Container aus. Wenn das Skript mit einem Exit-Code von 0 (Null) endet, gilt der Container als bereit. Andernfalls wird er nach fünf fehlgeschlagenen Versuchen als nicht bereit betrachtet.

35.2.4 Best Practices

• Leichte Endpunkte: Die Endpunkte für Readiness Probes sollten schnell und effizient sein, um keine unnötigen Ressourcen zu verbrauchen.
• Angemessene Schwellen: initialDelaySeconds, periodSeconds und failureThreshold sollten so konfiguriert werden, dass sie der tatsächlichen Startzeit und Stabilität Ihrer Anwendung entsprechen.
• Komplexität vermeiden: Vermeiden Sie komplexe Logik in Readiness Probes, die zu falschen Positiven oder Negativen führen könnte.

35.3 Liveness Probe in Kubernetes

Liveness Probes in Kubernetes prüfen, ob eine Anwendung in einem Container noch adäquat funktioniert. Bei einem Fehlschlag der Probe initiiert Kubernetes einen Neustart des Containers, um den Service wiederherzustellen.

Diese Proben sind zentral für die Aufrechterhaltung der Anwendungsverfügbarkeit in einem Kubernetes-Cluster, indem sie die Selbstheilung von Diensten durch automatische Neustarts bei Fehlverhalten ermöglichen.

35.3.1 Funktion von Liveness Probes

Ein Container, der nicht mehr reagiert oder in einer Endlosschleife feststeckt, kann normalerweise durch einen Neustart behoben werden. Liveness Probes helfen Kubernetes zu identifizieren, wann ein Neustart erforderlich ist.

35.3.2 Methoden für Liveness Probes

Wie bei Readiness Probes gibt es auch für Liveness Probes verschiedene Methoden:

• HTTP GET: Kubernetes sendet eine HTTP-GET-Anfrage an den Container.
• TCP Socket: Kubernetes versucht, eine TCP-Verbindung mit dem Container herzustellen.
• Exec Command: Kubernetes führt einen Befehl im Container aus und beurteilt den Status des Containers anhand des Exit-Codes des Befehls.

35.3.3 Konfigurationsbeispiel

Ein einfaches Beispiel für eine Liveness Probe mit einer HTTP-GET-Anfrage in einer Pod-Spezifikation sieht wie folgt aus:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: myapp:1.0
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 15
      timeoutSeconds: 2
      periodSeconds: 5
      failureThreshold: 3

In diesem Beispiel führt Kubernetes 15 Sekunden nach dem Containerstart eine Liveness Probe durch. Die Probe wird alle 5 Sekunden wiederholt. Nach drei fehlgeschlagenen Versuchen in Folge wird der Container neu gestartet.

35.3.4 Beispiel mit einem benutzerdefinierten Skript

Hier ist ein Beispiel, in dem eine Liveness Probe ein benutzerdefiniertes Skript im Container ausführt:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: myapp:1.0
    livenessProbe:
      exec:
        command:
        - /bin/bash
        - -c
        - /path/to/check-liveness.sh
      initialDelaySeconds: 30
      periodSeconds: 10

Das Skript /path/to/check-liveness.sh wird im Container ausgeführt, um zu überprüfen, ob die Anwendung noch lebt. Wenn das Skript einen Exit-Status von 0 zurückgibt, wird angenommen, dass die Anwendung in Ordnung ist. Wenn das Skript mit einem anderen Status endet, wird der Container als nicht mehr lebendig betrachtet und neu gestartet.

35.3.5 Best Practices

• Nicht zu aggressive Probes: Setzen Sie initialDelaySeconds und periodSeconds so, dass Ihre Anwendung genügend Zeit hat, sich von temporären Problemen zu erholen.
• Ressourcenschonend: Gestalten Sie Ihre Health Checks so, dass sie die Ressourcen des Containers nicht über Gebühr beanspruchen.
• Logik der Anwendung: Stellen Sie sicher, dass die Probes tatsächlich sinnvoll überprüfen, ob Ihre Anwendung lebt und arbeitet.