Kubernetes Monitoring vom Cluster bis zum Code

Was ist Kubernetes Monitoring?

Kubernetes Monitoring bezeichnet die kontinuierliche Erfassung und Auswertung von Telemetriedaten aus Kubernetes-Clustern: Control Plane, Nodes, Pods, Container und die darin laufenden Anwendungen. Es soll jederzeit drei Fragen beantworten: Ist der Cluster gesund, erhalten die Workloads die Ressourcen, die sie brauchen, und funktionieren die Services, auf die sich Ihre Nutzer verlassen?

Kubernetes macht das anspruchsvoller als klassisches Host-Monitoring. Pods leben nur kurz, IP-Adressen ändern sich, Workloads skalieren automatisch, und ein einzelner Request durchläuft oft Dutzende Container auf verschiedenen Nodes. Statische Dashboards, die auf Hostnamen basieren, stoßen hier schnell an Grenzen. Wirksames Kubernetes Monitoring setzt deshalb auf Labels und Metadaten, automatische Erkennung und die Korrelation von Metriken, Logs, Events und Traces.

Warum Kubernetes Monitoring wichtig ist

Kubernetes ist auf Selbstheilung ausgelegt, und genau das kann Probleme verdecken. Ein Container, der alle paar Minuten wegen OOMKilled neu startet, löst womöglich nie einen Ausfall-Alarm aus, verursacht aber fehlgeschlagene Requests und steigende Latenzen. Ein falsch gesetztes CPU-Limit drosselt einen kritischen Service, während der Node scheinbar kaum ausgelastet ist. Ohne Transparenz fallen solche Fehler erst auf, wenn sich Kunden beschweren.

Gutes Kubernetes Monitoring hilft Platform-Teams, Cluster stabil und effizient zu betreiben, zeigt Entwicklern, wie sich ihr Code in Produktion verhält, und liefert Führungskräften belastbare Daten für Kapazitäts- und Budgetplanung.

Wichtige Kubernetes-Metriken und Signale

Bewährt hat sich eine Gliederung nach Ebenen: Für Ressourcen eignet sich die USE-Methode (Utilization, Saturation, Errors), für Services die RED-Methode (Rate, Errors, Duration).

• Control Plane: Latenz und Fehlerrate des API-Servers, Leader-Wechsel und Disk-Sync-Dauer in etcd, wartende Pods im Scheduler.
• Nodes: CPU- und Speicherauslastung, Disk- und Inode-Druck, Netzwerkfehler sowie Node Conditions wie NotReady oder MemoryPressure.
• Pods und Container: Neustarts, OOM Kills, CPU-Throttling, Memory Working Set im Verhältnis zum Limit, fehlschlagende Readiness- und Liveness-Probes.
• Workloads: gewünschte gegenüber verfügbaren Replicas, Rollout-Fortschritt, fehlgeschlagene Jobs und Skalierungsaktivität des HPA.
• Anwendungen: Request-Rate, Fehlerrate und Latenz pro Service, idealerweise aus Distributed Traces.
• Events und Logs: Scheduling-Fehler, Image-Pull-Fehler, Evictions und Fehler in Anwendungslogs mit Pod- und Namespace-Metadaten.

So funktioniert Kubernetes Monitoring mit Obseria

Obseria wird mit einem einzigen Helm Chart installiert. Der Obseria Agent läuft als DaemonSet und erfasst Node- und Container-Metriken, Container-Logs, Kubernetes Events, Profile und Traces. Betreiben Sie bereits einen OpenTelemetry Collector oder nutzen OpenTelemetry SDKs, nimmt Obseria diese Daten nativ per OTLP an. Die meisten Teams sehen ihre ersten Traces nach rund 15 Minuten.

Obseria TopoGraph erstellt eine Live-Karte aus Clustern, Namespaces, Workloads und Service-Abhängigkeiten, sodass jedes Signal seinen Kontext mitbringt. Startet ein Pod neu, sehen Sie das zugehörige Deployment, den letzten Rollout, die Logs vor dem Absturz und die betroffenen nachgelagerten Services. Obseria Intelligence nutzt diese Topologie für kausale Analysen und führt agentische Untersuchungen durch, die mit einer nachvollziehbaren Beweiskette enden statt mit einer Sammlung korrelierter Charts.

Alle Daten landen in Obseria Lake, einem indexfreien Lakehouse. Sie fragen sie flexibel mit OQL, PromQL oder SQL ab:

fetch logs
| filter k8s.namespace == "checkout" and level == "error"
| summarize count(), by:{k8s.pod.name}

Mit Obseria Pipeline verwerfen Sie unnötige Debug-Logs, maskieren personenbezogene Daten und routen Daten bereits beim Ingest. Gefilterte Daten kosten nur die Ingestion.

Best Practices für Kubernetes Monitoring

1. Einheitlich labeln. Nutzen Sie Standard-Labels für Team, Service, Version und Umgebung, damit Daten gruppiert und klar zugeordnet werden können.
2. Auf Symptome alarmieren. Pagen Sie bei SLO-Burn-Rates und nutzerseitigen Fehlern; Node- und Pod-Warnungen gehören in Tickets oder Dashboards.
3. Requests und Limits prüfen. Vergleichen Sie tatsächlichen Verbrauch mit Requests, um Verschwendung, Throttling und OOM Kills zu vermeiden.
4. Deployments korrelieren. Markieren Sie Rollouts, damit Regressionen direkt nach einem Release sichtbar werden.
5. Service-übergreifend tracen. Metriken zeigen, dass etwas langsam ist; Traces zeigen, wo.
6. Datenvolumen steuern. Filtern und samplen Sie beim Ingest, damit die Monitoring-Kosten mit dem Nutzen wachsen und nicht mit der Clustergröße.