Anders als früher setzt die Anwendungsentwicklung heute nicht mehr auf große Monolithen, sondern präferiert Verbünde aus Kleinstprogrammen. Innerhalb eines solchen Verbunds hat jede einzelne Applikation nur eine einzige Aufgabe, um die sie sich kümmert. Im Hinblick auf ihre Wartung und ihren Betrieb sind solche Anwendungen viel anspruchsvoller als ihre monolithischen Vorgänger. So erklärt sich der Aufstieg der Container- Orchestrierer: Kubernetes & Co. erlauben es, über eine Flotte von physischen Systemen Container strukturiert zu verteilen. Faktisch wären Container ohne Orchestrierer produktiv nicht sinnvoll nutzbar, denn der Managementaufwand wäre viel zu hoch. Das bedeutet aber freilich auch, dass in Setups dieser Art diverse Ebenen zu überwachen sind und dass Monitoring hier viel mehr Teile und Aspekte überwachen muss als in konventionellen Umgebungen.
Das Kubernetes-Monitoring sollten Sie sich in drei Ebenen vorstellen. Die erste Ebene umfasst das Blech, denn "Serverless Computing" zum Trotz funktioniert auch Kubernetes nur mit Servern unter der Haube. Und wie in konventionellen Umgebungen wollen die überwacht und gepflegt sein, ebenso wie die Infrastruktur, die zum Betrieb der Server notwendig ist.
Ebene zwei umfasst Kubernetes selbst, sprich alle Softwarekomponenten, die für den Kubernetes-Betrieb notwendig sind, also im weitesten Sinne noch immer Infrastrukturmonitoring. Wo früher Prozesse wie Webserver oder Mailserver im Fokus des Monitorings standen, überwachen wir nun Kubernetes, das dann die Container betreibt, in denen Dienste wie Webserver und Mailserver laufen. Die dritte Ebene umfasst schließlich die Applikation selbst, also eben jenen Workload, der innerhalb der orchestrierten Container läuft. Aus Sicht des Monitorings ist dieser Teil der komplizierteste: Anders als das Blech ist er hochdynamisch und für ein
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.