Monitoring & Alarme
Zuerst zwei ehrliche Feststellungen. Ein Test-Cluster hat keinen Monitoring-Stack – das ist mit ein Grund, warum er 49 € kostet. Und auf jedem Cluster gilt: Die Plattform liest weder die Logs noch die Daten deiner Anwendungen; sie beobachtet den Cluster, nicht das, was darin läuft.
Jeder Cluster: Gesundheit in der Konsole
Abschnitt betitelt „Jeder Cluster: Gesundheit in der Konsole“Die Konsole zeigt für jeden Cluster und zu jedem Zeitpunkt:
- die vier Health-Conditions, die Gardener pflegt – API-Server erreichbar, Control Plane gesund, alle Nodes ready, System-Komponenten gesund – samt Grund, wenn eine davon es nicht ist;
- die letzte Operation (Erstellen, Reconcile, Wartung, Ruhezustand) mit Status und Fortschritt;
- Warnungen, bevor sie beißen: eine Version, die bald abläuft, ein Zertifikat, das seinem Datum nahekommt, ein Webhook, der ein Aufwecken blockieren würde;
- das Aktivitätsprotokoll: wer wann was geändert hat.
Diese Ansicht kommt von der Plattform, nicht aus deinem Cluster – sie bleibt also nützlich, wenn genau der Cluster das ist, was gerade weg ist. Sie zeigt den letzten bekannten Zustand und dass er stehengeblieben ist.
Produktions-Cluster: ein Monitoring-Stack
Abschnitt betitelt „Produktions-Cluster: ein Monitoring-Stack“Ein Produktions-Cluster trägt neben seiner Control Plane einen Monitoring-Stack – Prometheus und Dashboards –, mit dem die Plattform ihn betreibt: API-Server-Latenz und -Verfügbarkeit, Node- und Pod-Zahlen, Kapazität, etcd-Gesundheit. Das ist es, was uns ein Problem sehen lässt, bevor du es siehst.
Zwei Wege, ihn selbst zu nutzen:
- Föderiere die Control-Plane-Metriken des Clusters in dein eigenes Prometheus, Grafana oder SaaS-Monitoring. Frag den Support nach dem Föderations-Endpunkt und seinem Credential; er ist auf deinen Cluster beschränkt.
- Scrape im Cluster. Node- und Workload-Metriken gehören dir ohnehin: Betreibe dein eigenes Prometheus im Cluster, wie auf jedem Kubernetes-Cluster, den du administrierst.
Ein Vorbehalt, den man aussprechen sollte: Control-Plane-Metriken, die du in ein Prometheus innerhalb desselben Clusters föderierst, überleben es nicht, wenn dieser Cluster ausfällt. Halte die Kopie, die dir wichtig ist, außerhalb.
Private Cluster: die Metriken des Gateways
Abschnitt betitelt „Private Cluster: die Metriken des Gateways“Auf einem privaten Cluster exportiert das NAT-Gateway eigene Metriken – up, NAT-Durchsatz, Auslastung der Verbindungstabelle, abgelehnte und erlaubte ausgehende Pakete, Zustand der Allow-List – auf seiner privaten Adresse. Der Monitoring-Stack eines Produktions-Clusters scrapt sie und trägt Alarmregeln für ein Gateway, das down ist, eine Firewall, die nicht durchsetzt, eine Verbindungstabelle über 80 %, Denials und eine veraltete Allow-List. Jedes Prometheus, das du im Cluster betreibst, kann denselben Endpunkt scrapen. Du kannst den Metrik-Endpunkt außerdem hinter TLS und Basic Auth für einen externen Poller öffnen, aus Netzen, die du auflistest.
Alarme für deinen Cluster erreichen dein Team per E-Mail, an die Adressen, die du am Cluster hinterlegst. Gardener versendet ausschließlich E-Mail; eine Slack- oder PagerDuty-Route baust du dir aus deinem eigenen Prometheus. Alarme brauchen den Monitoring-Stack und sind damit ein Feature des Produktions-Clusters.
Die Plattform hält die Events des Clusters und sein Aktivitätsprotokoll vor. Sie aggregiert nicht die Logs deiner Pods. Auf einem privaten Cluster gehen die Firewall- und Flow-Logs des Gateways an einen Collector, den du innerhalb deines eigenen Netzwerks benennst – sie erreichen die Plattform nie, die nur Zähler führt.
Was ein Test-Cluster nicht hat
Abschnitt betitelt „Was ein Test-Cluster nicht hat“Kein Prometheus, keine Dashboards, keine E-Mail-Alarme. Die Gesundheitsansicht der Konsole ist alles, was es gibt – und für Dev, Staging und CI reicht das. Wenn du Alarmierung auf einem Cluster brauchst, mach ihn zu einem Produktions-Cluster.