Storage-Containerisierung Kubernetes braucht Observability
Anbieter zum Thema
Kubernetes vereinfacht die Bereitstellung, Skalierung und Verwaltung von Anwendungen, ist aber komplex in der Installation, Konfiguration und Verwaltung. Darüber hinaus nimmt die Komplexität des Software-Stacks zu. Ebenso steigt die Anzahl der erfassbaren Metriken erheblich. Daher erfordert die Migration eines Systems zu containerisierten Microservices und Kubernetes mehr Transparenz im Produktionscode.

Wurde vor der Migration noch auf ein Monitoring-Tool gesetzt, um den Überblick über mögliche Probleme zu behalten, zeigt sich danach schnell, dass das nicht mehr ausreicht. Denn containerisierte Systeme wie Kubernetes stellen neue Herausforderungen an das Monitoring im Vergleich zu Rechenumgebungen auf Basis virtueller Maschinen. Dazu gehören unter anderem die kurzlebige Natur von Containern, eine höhere Dichte von Objekten, Diensten und Metriken innerhalb eines bestimmten Knotens sowie der Fokus auf Diensten und nicht auf Maschinen. Um diese Herausforderungen zu meistern, braucht es Observability. Und nein, das ist kein Schreibfehler, denn Observability und Monitoring sind unterschiedlicher, als viele denken. Sie haben ungefähr so viel gemeinsam wie „Super Mario Bros.“ und „Minecraft“.
Zu komplex
„Super Mario Bros.“ ist ein einfaches Jump-’n’-Run-Videospiel mit den immer gleichen Stufen, Leveln und Gegnern. Egal, vor welchem Gerät man sitzt, die Abläufe sind immer gleich. Bei diesem Spiel können Daten einfach gesammelt werden, und man kann sich einen guten Überblick vom Zustand verschaffen. Es gibt beispielsweise eine klar festgelegte Spanne möglich erreichbarer Punkte. Erreicht man plötzlich mehr Punkte, als in der Spanne eigentlich möglich, stimmt mit dem Spiel etwas nicht. Zur Überprüfung dieser Metriken würde ein einfaches Monitoring-Tool ausreichen.
„Minecraft“ hingegen ist viel komplexer, denn es ist darauf ausgelegt, zu erkunden, zu erforschen und zu erschaffen. Die Spielwelt ist vermeintlich grenzenlos; rein theoretisch könnte eine Spielwelt wie von „Super Mario Bros.“ hier sogar noch eingefügt werden. Das System ist zu komplex, um einfach nur Daten zu sammeln und ausschließlich vordefinierte Metriken auszuwerten. Die schiere Masse an möglichen Interaktionen oder Unbekannten ist so groß, dass sie zu komplex für ein Monitoring-Tool ist. Gleiches gilt für containerisierte Microservices, die auf Kubernetes laufen – denn auch diese sind unglaublich komplex. Genau deshalb braucht es also Observability-Tools.
In der Praxis
Da monolithische Anwendungen in Microservices umgewandelt und mit Kubernetes orchestriert werden, ändern sich die Anforderungen an die Überwachung dieser Anwendungen. Zunächst muss die Instrumentierung zur Erfassung von Anwendungsdaten auf Container-Ebene erfolgen, und zwar in großem Umfang und über Tausende von Endpunkten hinweg. Da Kubernetes-Workloads standardmäßig flüchtig sind und jederzeit gestartet oder gestoppt werden können, muss die Anwendungsüberwachung dynamisch sein und die Kubernetes-Labels und -Namensräume kennen. Ein konsistenter Satz von Regeln oder Warnungen muss auf alle Pods – neue und alte – angewendet werden.
Bei der Entwicklung neuer oder der Überarbeitung bestehender Anwendungen sollte Observability in jedem Fall berücksichtigt werden. Die Beibehaltung einer gemeinsamen Ebene von Basismetriken, die für alle Anwendungen und Infrastrukturen gilt, während gleichzeitig benutzerdefinierte Metriken integriert werden, ist äußerst wünschenswert. Das Hinzufügen einer neuen Metrik auf der Grundlage von Benutzerfeedback sollte nicht dazu führen, dass der Überwachungs-Stack komplett umgebaut werden muss.
:quality(80)/images.vogel.de/vogelonline/bdb/1786000/1786028/original.jpg)
Open Source der Cloud Native Computing Foundation zum virtuellen Storage-Management
Storage in Container-Umgebungen – Kubernetes mit OpenEBS
Überblick behalten
Observability ist für das Verständnis der Beziehungen zwischen der Infrastruktur, Kubernetes und den Anwendungsdiensten entscheidend. Es werden viele Fragen auftauchen, und um diese zu beantworten, muss Kubernetes mit Anwendungsdaten korreliert, Daten über Kubernetes-Cluster hinweg aggregiert oder Daten für jeden Kubernetes-Dienst isoliert werden. Manchmal zum Beispiel funktioniert die Kubernetes-Wiederherstellung so gut, dass die Ursache nicht isoliert werden kann, um schnell auf einen Vorfall zu reagieren. Zum Beispiel könnte Kubernetes eine Anwendung neu starten, und niemand würde es bemerken, dass einige der Container aufgrund eines Speicherlecks mehrfach abgestürzt sind. Trotzdem sollte der Administrator darüber Bescheid wissen. Um den Überblick zu behalten, sollten die Kubernetes-Knoten und einzelne Pods mithilfe von Dashboards überwacht werden und alle Dienste der Anwendung mit Last, Durchsatz, Anwendungsfehlern und andere Metriken einsehbar sein.
Observability bietet Ingenieuren ein vollständiges Bild und alle Informationen, die zur Leistungssteigerung und Verbesserung von sowohl der Stabilität als auch der Ausfallsicherheit von Anwendungen, Kubernetes-Komponenten und der zugrunde liegenden Infrastruktur notwendig sind. Am Ende wirkt sich ein gutes Observability-Tool positiv auf den gesamten Software-Stack und damit auch das gesamte Geschäft aus.
*Der Autor: Frederik Bijlsma, Senior Director Sales Central EMEA bei VMware Tanzu.
(ID:47981216)