11 Juni 2026

Wie funktioniert Container-Health-Checking in Kubernetes?

Container-Health-Checking in Kubernetes ist ein automatisiertes System, das kontinuierlich den Zustand von Containern überwacht und bei Problemen entsprechende Maßnahmen einleitet. Kubernetes nutzt verschiedene Probe-Typen wie Liveness, Readiness und Startup Probes, um sicherzustellen, dass Container ordnungsgemäß funktionieren und Anwendungen verfügbar bleiben.

Fehlgeschlagene Health-Checks führen zu unvorhersehbaren Ausfallzeiten

Wenn Container-Health-Checks falsch konfiguriert oder gar nicht implementiert sind, bleiben defekte Container unentdeckt im Cluster aktiv und verursachen sporadische Anwendungsausfälle. Benutzer erhalten Fehlermeldungen, Transaktionen schlagen fehl und der Support wird mit schwer nachvollziehbaren Problemen überlastet. Die Lösung liegt in der präzisen Konfiguration von Liveness und Readiness Probes, die automatisch defekte Container erkennen und neu starten.

Aggressive Health-Check-Parameter verursachen instabile Cluster

Zu kurze Timeouts und niedrige Failure-Schwellenwerte führen dazu, dass gesunde Container fälschlicherweise als defekt erkannt und unnötig neu gestartet werden. Dies erzeugt eine Kaskade von Neustarts, die das gesamte System destabilisiert und die Performance drastisch verschlechtert. Verwenden Sie realistische Timeout-Werte basierend auf der tatsächlichen Startup-Zeit Ihrer Anwendungen und implementieren Sie Startup Probes für langsam startende Container.

Was ist Container-Health-Checking in Kubernetes?

Container-Health-Checking in Kubernetes ist ein Mechanismus zur automatischen Überwachung des Zustands von Containern durch verschiedene Probe-Typen. Das System erkennt defekte Container, startet sie neu oder entfernt sie aus dem Load Balancing, um die Anwendungsverfügbarkeit sicherzustellen.

Kubernetes führt diese Checks regelmäßig durch und reagiert basierend auf den Ergebnissen. Bei fehlgeschlagenen Liveness Probes wird der Container neu gestartet, während fehlgeschlagene Readiness Probes dazu führen, dass der Container temporär aus dem Service-Load-Balancing entfernt wird. Startup Probes bieten zusätzlichen Schutz für Container mit längeren Initialisierungszeiten.

Das Health-Checking erfolgt auf Container-Ebene innerhalb von Pods und ist essenziell für selbstheilende Systeme. Ohne ordnungsgemäße Health-Checks können defekte Container unentdeckt bleiben und Benutzeranfragen an nicht funktionsfähige Instanzen weiterleiten.

Welche Arten von Health-Probes gibt es in Kubernetes?

Kubernetes bietet drei Arten von Health-Probes: Liveness Probes erkennen defekte Container und starten sie neu, Readiness Probes bestimmen, ob Container bereit für Traffic sind, und Startup Probes schützen langsam startende Container vor vorzeitigen Neustarts.

Liveness Probes überwachen kontinuierlich, ob ein Container ordnungsgemäß funktioniert. Bei wiederholten Fehlschlägen startet Kubernetes den Container automatisch neu. Diese Probes sind besonders wichtig für Anwendungen, die in einen nicht behebbaren Zustand geraten können.

Readiness Probes prüfen, ob ein Container bereit ist, Anfragen zu bearbeiten. Container mit fehlgeschlagenen Readiness Probes werden temporär aus dem Service-Endpoint entfernt, bleiben aber weiterhin aktiv. Dies verhindert, dass nicht bereite Container Traffic erhalten.

Startup Probes wurden speziell für Container mit langen Initialisierungszeiten entwickelt. Sie deaktivieren Liveness und Readiness Probes während der Startup-Phase und verhindern so vorzeitige Container-Neustarts bei langsam startenden Anwendungen.

Wie konfiguriert man Liveness Probes richtig?

Liveness Probes werden durch die Definition von Probe-Parametern wie initialDelaySeconds, periodSeconds, timeoutSeconds und failureThreshold in der Pod-Spezifikation konfiguriert. Der Probe-Typ kann HTTP GET, TCP Socket oder Command Execution sein.

Bei HTTP-basierten Liveness Probes sollten Sie einen dedizierten Health-Endpoint verwenden, der den tatsächlichen Anwendungszustand widerspiegelt. Vermeiden Sie Endpoints, die externe Abhängigkeiten prüfen, da diese zu falschen Neustarts führen können:

  • initialDelaySeconds: Wartezeit vor dem ersten Check (typisch 30-60 Sekunden)
  • periodSeconds: Intervall zwischen Checks (empfohlen 10-30 Sekunden)
  • timeoutSeconds: Timeout pro Check (meist 1-5 Sekunden)
  • failureThreshold: Anzahl fehlgeschlagener Checks vor Neustart (typisch 3-5)

Für TCP Socket Probes geben Sie Port und optional die IP-Adresse an. Command-basierte Probes führen Befehle im Container aus und bewerten den Exit-Code. Stellen Sie sicher, dass die Probe-Logik schnell ausführbar ist und keine ressourcenintensiven Operationen durchführt.

Wann sollte man Readiness Probes verwenden?

Readiness Probes sollten immer verwendet werden, wenn Container eine Initialisierungsphase haben oder von externen Abhängigkeiten wie Datenbanken abhängen. Sie verhindern, dass nicht bereite Container Traffic erhalten und verbessern so die Benutzererfahrung.

Implementieren Sie Readiness Probes besonders in folgenden Szenarien: bei Anwendungen mit Datenbankverbindungen, die Zeit zum Aufbau benötigen, bei Services mit umfangreichen Caching-Mechanismen oder wenn Container externe APIs oder Konfigurationsdateien laden müssen. Die Probe sollte alle kritischen Abhängigkeiten prüfen, die für die ordnungsgemäße Anfragenbearbeitung erforderlich sind.

Im Gegensatz zu Liveness Probes können Readiness Probes externe Abhängigkeiten einbeziehen. Wenn beispielsweise die Datenbankverbindung fehlschlägt, ist es sinnvoll, den Container als nicht bereit zu markieren, anstatt ihn neu zu starten. Dies ermöglicht eine automatische Wiederherstellung, sobald die Abhängigkeiten wieder verfügbar sind.

Was sind häufige Fehler beim Health-Checking?

Häufige Fehler beim Health-Checking umfassen zu aggressive Timeout-Einstellungen, die Verwendung derselben Probe für Liveness und Readiness und das Fehlen von Startup Probes bei langsam startenden Anwendungen. Diese Probleme führen zu instabilen Deployments und unnötigen Container-Neustarts.

Ein kritischer Fehler ist die Verwendung zu kurzer initialDelaySeconds-Werte. Wenn Container länger zum Starten benötigen als konfiguriert, werden sie sofort nach dem Start als defekt erkannt und neu gestartet, was zu endlosen Restart-Schleifen führt. Messen Sie die tatsächliche Startup-Zeit Ihrer Anwendung und addieren Sie einen Sicherheitspuffer.

Weitere häufige Probleme sind die Prüfung externer Abhängigkeiten in Liveness Probes, was zu Neustarts führt, obwohl der Container selbst funktionsfähig ist, und die Verwendung ressourcenintensiver Health-Check-Operationen, die die Anwendungsperformance beeinträchtigen. Außerdem vergessen viele Entwickler, die Probe-Konfigurationen für verschiedene Umgebungen anzupassen.

Wie überwacht man Health-Check-Status in Kubernetes?

Health-Check-Status werden über kubectl-Befehle, Kubernetes Events und Monitoring-Tools überwacht. Der Befehl kubectl describe pod zeigt aktuelle Probe-Status und Fehlerhistorien, während kubectl get events Health-Check-bezogene Ereignisse auflistet.

Verwenden Sie kubectl describe pod podname für detaillierte Informationen über Probe-Ausfälle, einschließlich der letzten Fehlermeldungen und Zeitstempel. Das Conditions-Feld zeigt den aktuellen Readiness-Status, während der Restart-Count auf wiederholte Liveness-Probe-Ausfälle hinweist.

Für produktive Umgebungen sollten Sie Monitoring-Lösungen wie Prometheus mit Kubernetes-Metriken implementieren. Diese sammeln Health-Check-Metriken automatisch und ermöglichen Alerting bei häufigen Probe-Ausfällen. Container-Logs liefern zusätzliche Einblicke in die Ursachen von Health-Check-Problemen und sollten zentral gesammelt und analysiert werden.

Wie credativ® bei Container-Health-Checking in Kubernetes unterstützt

Wir bei credativ® unterstützen Sie bei der optimalen Implementierung und Überwachung von Container-Health-Checking in Ihren Kubernetes-Umgebungen. Unser Expertenteam hilft Ihnen dabei, robuste und zuverlässige Health-Check-Strategien zu entwickeln:

  • Analyse und Optimierung bestehender Health-Check-Konfigurationen
  • Implementierung maßgeschneiderter Probe-Strategien für Ihre Anwendungsarchitektur
  • Einrichtung umfassender Monitoring- und Alerting-Systeme
  • Schulungen für Ihre Teams zu Best Practices im Container-Health-Checking
  • 24/7 Support bei kritischen Health-Check-Problemen

Kontaktieren Sie uns für eine individuelle Beratung zu Ihrer Kubernetes-Health-Check-Strategie und profitieren Sie von unserer langjährigen Erfahrung im Open Source-Umfeld.

Ähnliche Artikel

Kategorien: credativ® Inside

über den Autor

Peter Dreuw

Head of Sales & Marketing

zur Person

Peter Dreuw arbeitet seit 2016 für die credativ GmbH und ist seit 2017 Teamleiter. Seit 2021 ist er Teil des Management-Teams als VP Services der Instaclustr. Mit der Übernahme durch die NetApp wurde seine neue Rolle "Senior Manager Open Source Professional Services". Im Rahmen der Ausgründung wurde er Mitglied der Geschäftsleitung als Prokurist. Sein Aufgabenfeld ist die Leitung des Vertriebs und des Marketings. Er ist Linux-Nutzer der ersten Stunden und betreibt Linux-Systeme seit Kernel 0.97. Trotz umfangreicher Erfahrung im operativen Bereich ist er leidenschaftlicher Softwareentwickler und kennt sich auch mit hardwarenahen Systemen gut aus.

Beiträge ansehen


Beitrag teilen: