Kubernetes-Monitoring in der Praxis: Cluster-Health, Pod-Metriken und sinnvolle Alarme konfigurieren

Grüner Programmiercode auf einem dunklen Bildschirm – Bild von Markus Spiske via Pexels

Kubernetes ist heute die Standardplattform für containerbasierte Workloads – von kleinen Startups bis zu Enterprise-Umgebungen mit Hunderten von Nodes. Mit der Komplexität der Plattform wachsen auch die Anforderungen an das Monitoring erheblich. Ein einfacher HTTP-Check auf den Cluster-Endpunkt reicht nicht aus: Der API-Server kann erreichbar sein, während einzelne Deployments fehlschlagen, Nodes unter Speicherdruck stehen oder Pods in Neustartschleifen gefangen sind.

Dieser Artikel beschreibt, welche Metriken für ein stabiles Kubernetes-Monitoring wirklich relevant sind, wie Alarme sinnvoll konfiguriert werden und wo externe Monitoring-Werkzeuge wertvolle Ergänzungen zu internen Cluster-Metriken sind.

Die drei Beobachtungsebenen im Kubernetes-Monitoring

Ein vollständiges Kubernetes-Monitoring deckt drei Ebenen ab:

Infrastruktur-Ebene: Node-Zustand, CPU, Arbeitsspeicher, Festplatten-I/O und Netzwerk-Bandbreite der zugrunde liegenden Maschinen.
Kubernetes-Ebene: Pod-Status, Deployment-Zustand, ReplicaSet-Verfügbarkeit, CrashLoopBackOff-Ereignisse und PersistentVolume-Nutzung.
Applikations-Ebene: HTTP-Antwortzeiten, Fehlerquoten, Durchsatz und custom Business-Metriken der deployten Dienste.

Viele Teams starten mit der Applikations-Ebene und vernachlässigen die darunter liegenden Schichten. Das Ergebnis: Incidents manifestieren sich erst auf der Oberfläche, wenn der Schaden bereits entstanden ist.

Kritische Metriken auf Node-Ebene

CPU- und Memory-Pressure

Nodes unter dauerhafter CPU-Last oder Speicherdruck reagieren verlangsamt – mit direkten Auswirkungen auf alle Pods des betroffenen Nodes. Besonders gefährlich ist Memory-Pressure: Sobald der Node-Kernel den OOM-Killer aktiviert, werden Pods ohne Vorwarnung beendet. Alarme für Memory-Druck sollten bei 80 % Auslastung greifen, nicht erst wenn Pods bereits gekillt werden. Auch kurzfristige Memory-Spitzen können kritisch sein, wenn sie mit anderen Lastspitzen zusammenfallen.

Disk-Pressure und Inode-Auslastung

Container-Logs, temporäre Dateien und lokale Image-Layer füllen Festplatten schneller, als Teams oft erwarten. Disk-Pressure ist ein häufiger und oft unterschätzter Grund für Node-Instabilität in Produktionsumgebungen. Neben dem Prozentsatz des belegten Speicherplatzes sollte auch die Inode-Auslastung überwacht werden – sie kann unabhängig vom freien Speicherplatz erschöpft sein, besonders bei Workloads, die viele kleine Dateien erzeugen.

Node-Readiness

Ein Node im Zustand NotReady ist ein kritisches Ereignis: Neue Pods werden nicht auf diesen Node geplant, und laufende Pods können in Termination-Schleifen geraten. Dieser Zustand muss sofort eskalieren – ohne Verzögerung, ohne Zusammenfassen mit anderen Alarmen. Jede Minute ohne Reaktion kann sich direkt auf die Nutzerverfügbarkeit auswirken.

Pod- und Deployment-Monitoring

CrashLoopBackOff frühzeitig erkennen

Ein Pod im CrashLoopBackOff-Zustand startet immer wieder neu – Kubernetes wartet zwischen den Versuchen mit exponentiell wachsenden Zeitabständen. Das Muster ist ein verlässlicher Hinweis auf Konfigurationsprobleme, fehlende Abhängigkeiten oder Fehler im Container-Startprozess. Alarme sollten ab dem zweiten Neustart innerhalb kurzer Zeit auslösen, nicht erst nach mehreren Minuten ununterbrochener Neustarts.

Deployment-Rollout-Status

Ein steckengebliebener Rollout – wenn eine neue Deployment-Version nicht vollständig ausgerollt wird – wird oft erst bemerkt, wenn Nutzer Probleme melden. Der Grund kann ein fehlgeschlagener Readiness-Check der neuen Version sein, ein fehlendes Secret oder eine Ressourcenengpass im Cluster. Das Werkzeug kube-state-metrics liefert präzise Informationen darüber, ob ein Deployment seinen gewünschten Zustand erreicht hat. Diese Metrik sollte bei jedem Deployment-Vorgang aktiv überwacht werden.

Pending-Pods und Scheduling-Fehler

Pods im Zustand Pending, die nicht geplant werden können, sind ein häufig übersehenes Signal. Die Ursachen sind vielfältig: fehlende Ressourcen im Cluster, PodAffinity-Konflikte, Taint/Toleration-Konfigurationsfehler oder nicht verfügbare PersistentVolumeClaims. Ein Alarm für Pods, die länger als wenige Minuten im Pending-Zustand verbleiben, gehört zu den wichtigsten Ergänzungen in jedem Kubernetes-Monitoring-Setup – besonders in Umgebungen mit Autoscaling, wo neue Nodes erst bereitgestellt werden müssen.

Bewährte Werkzeuge für Kubernetes-Monitoring

Prometheus und kube-state-metrics

Prometheus ist das De-facto-Standard-Monitoring-System für Kubernetes. In Kombination mit dem kube-state-metrics-Exporter liefert es detaillierte Metriken über Cluster-Zustand, Deployment-Status und Ressourcennutzung. Grafana als Visualisierungsschicht ist die natürliche Ergänzung – mit einer aktiven Community, die vorgefertigte Dashboards für alle gängigen Kubernetes-Szenarien anbietet.

Für die Alarmierung auf Basis von Prometheus empfehlen sich Prometheus Alertmanager-Regeln in Kombination mit klar definierten Eskalationspfaden: Wer wird bei welchem Alarm benachrichtigt, und über welchen Kanal?

Externe Uptime-Überwachung als zweite Sicherheitsebene

Prometheus läuft selbst innerhalb des Clusters. Wenn der gesamte Cluster oder ein kritischer Netzwerkbereich nicht erreichbar ist, fällt auch das interne Monitoring aus. Externe HTTP-Monitoring-Lösungen, die Endpunkte von außerhalb des Clusters prüfen, sind daher eine wichtige Ergänzung. Sie erkennen Ausfälle, die von innen unsichtbar bleiben: Routing-Probleme, Ausfall des Ingress-Controllers, DNS-Fehler. Heartbeat-Monitoring ergänzt diesen Schutz für kritische Cluster-Batch-Jobs, die regelmäßig ein Signal senden müssen.

Metrics Server für Ressourcenverwaltung

Der Kubernetes Metrics Server liefert aktuelle CPU- und Memory-Auslastung auf Node- und Pod-Ebene und ist die Grundlage für den Horizontal Pod Autoscaler. Ohne korrekt konfigurierte Resource Requests und Limits ist zuverlässiges Autoscaling nicht möglich; Monitoring ohne diese Grundlage liefert entsprechend unzuverlässige Alarme. Resource Requests und Limits sollten für jeden Dienst explizit und realistisch definiert werden.

Alarme sinnvoll konfigurieren und Alert-Fatigue vermeiden

Der häufigste Fehler beim Kubernetes-Monitoring ist ein Alarmsystem, das zu viele Ereignisse eskaliert. Jedes Deployment, jeder Pod-Neustart, jede kurze Lastspitze – wenn all das zu Alarm führt, entsteht Alert-Fatigue, und wirklich kritische Ereignisse werden im Rauschen übersehen.

Bewährte Einteilung nach Dringlichkeit:

Sofortalarm ohne Verzögerung: Node NotReady, komplettes Deployment ausgefallen, Cert-Expiry innerhalb 24 Stunden, kritischer PVC nicht gebunden.
Alarm nach anhaltendem Zustand (5–10 Minuten): CrashLoopBackOff, Memory-Auslastung über 85 %, Pending Pods ohne Verbesserung.
Kein Alarm, nur Dashboard-Anzeige: Einzelne Pod-Neustarts bei Deployments, kurzfristige CPU-Spitzen innerhalb normaler Parameter.

SLO-basiertes Alerting ergänzt regelbasierte Alarme sinnvoll: Statt auf einzelne Metriken zu reagieren, wird das Gesamtfehlerbudget des Dienstes beobachtet – und erst alarmiert, wenn das Budget in einem kritischen Tempo abbrennt. Das reduziert Alarm-Rauschen erheblich und fokussiert das On-Call-Team auf echte Nutzerauswirkungen.

Fazit: Drei Ebenen, klare Prioritäten

Kubernetes-Monitoring erfordert Tiefe auf allen drei Ebenen: Infrastruktur, Plattform und Applikation. Die technischen Werkzeuge – Prometheus, kube-state-metrics, Grafana – sind ausgereift und gut dokumentiert. Die eigentliche Herausforderung liegt in der sorgfältigen Konfiguration von Alarmschwellwerten und Eskalationspfaden: was eskaliert wann, wer wird informiert, und welche Reaktion ist erwartet? Externe Monitoring-Checks ergänzen das interne Cluster-Monitoring als unabhängige Sicherheitsebene. Wer diese Schichten konsequent aufbaut, erkennt Kubernetes-Incidents bevor sie Nutzer erreichen.

Bildquelle: Markus Spiske via Pexels