Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 8 Min.

Kubernetes-Monitoring: Passgenau


Linux Magazin Sonderheft - epaper ⋅ Ausgabe 1/2019 vom 21.02.2019

In Cloud-Native-Umgebungen stoßen klassische Monitoring-Tools an ihre Grenzen, wenn sie kurzlebige Objekte wie Container überwachen. Diese Lücke schließt Prometheus, das Kubernetes dank der konzeptionellen Ähnlichkeit, des einfachen Aufbaus und einer weitreichenden Automatisierung passgenau ergänzt.


Containercluster mit Prometheus überwachen

Artikelbild für den Artikel "Kubernetes-Monitoring: Passgenau" aus der Ausgabe 1/2019 von Linux Magazin Sonderheft. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin Sonderheft, Ausgabe 1/2019

Kubernetes [1] erleichtert es Admins enorm, Container-basierte Infrastrukturen zu verteilen. Sie müssen sich im Prinzip keine Gedanken mehr darüber machen, wo Applikationen laufen oder ob ausreichend Ressourcen bereitstehen. Wollen sie aber eine optimale Leistung ...

Weiterlesen
epaper-Einzelheft 11,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin Sonderheft. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 1/2019 von Alles zu seiner Zeit. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Alles zu seiner Zeit
Titelbild der Ausgabe 1/2019 von Wie Cloud Native möglich wurde und was Container damit zu tun haben Die bessere Cloud?. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Wie Cloud Native möglich wurde und was Container damit zu tun haben Die bessere Cloud?
Titelbild der Ausgabe 1/2019 von Container unter oder über Open Stack Zusammenspiel. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Container unter oder über Open Stack Zusammenspiel
Titelbild der Ausgabe 1/2019 von Container-Management:Schlau verwaltet. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Container-Management:Schlau verwaltet
Titelbild der Ausgabe 1/2019 von Rumpf-Betriebssysteme: Nachwuchshelden. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Rumpf-Betriebssysteme: Nachwuchshelden
Titelbild der Ausgabe 1/2019 von Containersicherheit: Die Krux mit den Lecks. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Containersicherheit: Die Krux mit den Lecks
Vorheriger Artikel
Netz in Kubernetes: Redebedarf
aus dieser Ausgabe
Nächster Artikel Kubernetes-Praxis: Lernfabrik
aus dieser Ausgabe

Kubernetes [1] erleichtert es Admins enorm, Container-basierte Infrastrukturen zu verteilen. Sie müssen sich im Prinzip keine Gedanken mehr darüber machen, wo Applikationen laufen oder ob ausreichend Ressourcen bereitstehen. Wollen sie aber eine optimale Leistung sicherstellen, kommen sie meist nicht daran vorbei, die Applikationen, die Container, in denen sie laufen, und Kubernetes selbst zu überwachen.

Wie Prometheus funktioniert, lässt sich unter[2] nachlesen, der aktuelle Artikel wirft ein Licht auf die Zusammenarbeit mit Kubernetes. Dank seiner eingebauten Service Discovery holt sich Prometheus selbstständig über das Kubernetes-API Informationen über die Containerplattform, die laufenden Container, Dienste und Anwendungen. Der Admin muss die Konfiguration von Prometheus nicht ändern, wenn Pods starten oder sterben oder wenn neue Knoten im Cluster auftauchen: All dies erkennt Prometheus.

Sehr erhebend

Neben üblichen Daten wie CPU-Auslastung, Speichernutzung oder Festplattendurchsatz interessieren in einer Kubernetes-Umgebung auch die Metriken von Containern, Pods, Deployments und den laufenden Anwendungen. Der Artikel will zeigen, wie Admins mit Prometheus und Grafana am einfachsten Informationen über ihren Kubernetes-Cluster sammeln und visualisieren. Eine Demo-Umgebung liefert Eindrücke davon, welche Einblicke in eine Kubernetes-Installation Prometheus gewährt.

Die Konfiguration von Prometheus orientiert sich dabei am offiziellen Beispiel[3] . Beim Abfragen der Metriken über das Kubernetes-API genügt beispielsweise der Auszug aus Listing 1. Und schon lassen sich dank der Service Disco-very in Prometheus eine Menge Metriken abrufen, wie Abbildung 1 zeigt.

Der Autor

Michael Kraus ist Senior Consultant für Open-Source-Monitoring bei Con-Sol in München. Seit 2005 entwickelt und betreut er die Monitoring-Umgebungen mit Nagios und seinen Nachfolgern. Sein Hauptaugenmerk gilt der Integration neuer Komponenten in ein sinnvolles Monitoring — nur Open-Source-Software sollte es sein.

Abbildung 1: Mit ein paar Handgriffen und dem Kubernetes-API spürt der Admin verschiedene Metriken auf.


Etikettiert

Der wohl größte Vorteil im Zusammenspiel von Prometheus und Kubernetes dürfte aber der Support für Label sein. Sie sind in Kubernetes die einzige Möglichkeit, gezielt auf Pods, Services und andere Objekte zuzugreifen oder diese zu identifizieren. Es ist daher wichtig, dass Prometheus diese Label erkennt und beibehält. Die Service Discovery der Software legt diese Informationen temporär in so genannten Meta Label ab. Mit Hilfe von Relabeling-Regeln wandelt Prometheus diese dann in gültige Prometheus-Label um und verwirft die Meta Label, sobald es die Überwachungsziele erzeugt hat.

Den Relabeling-Prozess beschreibt ein Blogpost[4] im Detail. Die Regeln sehen zum Beispiel aus wie in Listing 2. Am Ende kennt Prometheus dann die Label, die auch Kubernetes seinen Nodes, Applikationen und Services zuordnet.

Prom Night

Mit der mächtigen Abfragesprache Prom QL[5] und anhand dieser Label definieren Admins Graphen oder Alarme. So definiert Kubernetes die Label aus Listing 3, die eine daraus resultierende Prometheus-Metrik quasi erbt:

my_app_metric{app="myapp ", mylabel="myva lue", […]}

Prometheus erzeugt für jedes weitere Label eine eigene Zeitreihe. Jedes Label fügt der Metrik »my_app_metric« eine weitere Dimension hinzu, die Prometheus wiederum als separate Zeitreihe speichert. Die Software kommt bereits jetzt mit Millionen von Zeitreihen zurecht und kann Kubernetes-Umgebungen mit Tausenden Knoten abdecken.

Abbildung 2: Das Minikube-Dashboard zeigt Informationen zum Cluster auf Basis seines Namespace an.


Von Dauer oder flüchtig?

Prometheus wird am besten im zu überwachenden Kubernetes-Cluster installiert. Mit Persistent Volumes[6] oder Stateful Sets[7] verfügt Kubernetes über Möglichkeiten, Daten dauerhaft zu behalten. Vor der Installation sollte der Administrator überlegen, wie lange er die Daten in Prometheus vorhalten möchte, und den Platzbedarf anhand[8] ermitteln.

Ausprobiert

Um die oben ausgeführten Informationen zu veranschaulichen, wird der Artikel demonstrieren, wie ein Admin auf Basis von Minikube[9] einen eigenen kleinen Kubernetes-Cluster mit Prometheus-Aufsatz laufen lässt. Minikube bietet die einfachste Möglichkeit, Kubernetes auf seinem eigenen Rechner zu testen, egal ob dieser Linux, OS X oder Windows verwendet.

Wer die Schritte nachvollziehen möchte, findet unter[10] eine entsprechende Installationsanleitung. Einen neuen Kubernetes-Cluster erzeugt der Befehl »minikube start«, je nach Basissystem setzt Minikube noch ein installiertes Virtualbox oder »kubectl« voraus.

Vollständige Listings der im Artikel gezeigten Auszüge bietet das Linux-Magazin online[11] an. Das betrifft vor allem die Yaml-Files mit den Kubernetes-Definitionen (»*.yml«): Der Nutzer entpackt sie in ein Arbeitsverzeichnis, um sie später mit »kubectl« an Kubernetes zu senden. Die mit den Yaml-Dateien erzeugten Inhalte speichert Kubernetes intern und erzeugt daraus entsprechende Objekte wie Namespaces, Deployments oder Services.

Namens-Tag

Um die Ressourcen einzelner User oder eine Nutzergruppe auf einem physischen Cluster voneinander zu isolieren, verwendet Kubernetes Namespaces. Für das Beispielprojekt erzeugt der Admin den Namespace »monitoring«: kubectl create ‑f 00‑monitoring‑namespace. yml

Die mit Kubernetes 1.6 eingeführte Role Based Access Control (RBAC) erfordert die Anlage eines Service-Accounts mit entsprechenden Clusterrollen, die es ihm erlauben, die notwendigen Informationen aus dem Kubernetes-API auszulesen. Entsprechend dem offiziellen Beispiel[12] legt er es an:

kubectl create ‑f 01‑rbac.yml

Will er einfach nachvollziehen, was in dem kleinen Kubernetes-Cluster passiert, startet der Anwender die Admi-nistrationsoberfläche über »minikube dashboard«. Hier wählt er dann den Namespace »monitoring« wie es Abbildung 2 zeigt.

Der nächste Schritt widmet sich dann schon Prometheus. Die Software gibt es als offizielles Docker-Image[13] , allerdings ohne jede Konfiguration. Um nicht für jede Änderung ein neues Image bauen zu müssen, packt der Admin die Kubernetes-Konfiguration als Datenobjekt »prometheus.yml« in eine Config Map[14] mit dem Namen »prometheus‑configmap «.

Die Config Map kann er dann unabhängig ändern, löschen oder neu anlegen:

kubectl create ‑f 02‑prometheus‑configmap. yml

So genannte Deployments[15] liefern Deklarationen, um Pods und Replica-Sets zu aktualisieren. Das Kubernetes-Deployment für Prometheus (Listing 4) bindet die gerade angelegte Config Map als neues Volume mit dem Namen »prometheus‑volume‑config « per Volume-Mount in den Pfad »/etc/prometheus/ prometheus.yml« ein. Das stellt eine Verbindung zwischen Prometheus und seiner Konfiguration her:

kubectl create ‑f 03‑prometheus‑deployment. yml

Das Verzeichnis, das die Prometheus-Datenbank speichert, konfiguriert der Admin ebenfalls als »volume«, konkret als »emptyDir«. Es verwirft die Daten beim Neustart des Prometheus-Pod, für ein produktives Setup sollte er hier besser persistente Volumes verwenden. Fehlt noch ein passender Dienst für Prometheus, um einfach auf die laufende Prometheus-Instanz zuzugreifen:

kubectl create ‑f 04‑prometheus‑service.yml

Der Service lässt sich dann etwa über »kubectl« auf den Schirm rufen (Listing 5). An dieser Stelle der Hinweis, dass Minikube Services mitunter als »pending« (noch ausstehend) anzeigt. Keine Sorge, sie funktionieren trotzdem.

Ausschau halten

Anwendungen, die Metriken im Prometheus-Format bereitstellen, findet die Monitoring-Software auch automatisch – allerdings im Moment auch Pods und Services, die keine passenden Metriken liefern. Um nur die gewünschten Endpunkte zu finden, kann der Admin bestimmte Annotations im Key-Value-Format verwenden, die auch ein Beispiel in der Dokumentation näher beschreibt (Listing 6,[3] ).

Abbildung 3: Dashboards, etwa Grafana, helfen beim Visualsieren der beim Monitoring gesammelten Daten.


Da in dieser Demo solche Anmerkungen nicht auftauchen, wird die nächste Komponente – der »node_exporter«[16] – ganz automatisch gefunden. Er erhebt Daten über die Leistung der Clusterknoten, etwa zur Speichernutzung, zum Netzwerkdurchsatz oder zur CPU-Auslastung. Will sich der Administrator nicht selbst darum kümmern, dass die Software auf jedem Knoten läuft, startet er den »node_exporter« als ein so genanntes Daemon Set[17] . Dieser Schritt stellt schlicht sicher, dass auf jedem Knoten eine eigene Instanz von »node_exporter« läuft: Sobald ein neuer Knoten hinzukommt, ruft Kubernetes dort vollautomatisch eine neue Instanz auf:

kubectl create ‑f 05‑node‑exporter.yml

Damit der »node_exporter « allerdings Zugriff auf sämtliche Informationen des Hostsystems erhält, muss ihn der Admin mit erweiterten Rechten ausstatten, was eine Ergänzung in seiner Yaml-Datei erfordert:

securityContext: privileged: true

Damit greift die Instanz des »node_exporter « auf Ressourcen des Hosts zu und liest etwa dessen »/proc«-Dateisystem aus. Wie das geht, zeigt Listing 7.

Am Ziel

Nach diesen wenigen Schritten ist Prometheus einsatzbereit und stellt nach dem Aufruf über

minikube service prometheus ‑‑namespace=monitoring

eine Menge verschiedener Metriken bereit. Grafana[18] verschafft dem Admin schließlich mit Hilfe grafischer Mittel einen ansehnlichen und informativen Überblick über den gesamten Kubernetes-Cluster:

kubectl create ‑f 06‑grafana‑deployment.yml minikube service grafana ‑‑namespace=monitoring

Beim Einrichten von Grafana wird automatisch eine Datenquelle für Prometheus anlegt und es werden, ebenfalls ohne Zutun des Benutzers, zwei nützliche Dashboards für Kubernetes ([19] ,[20] ) importiert.

Hat sich der Systemverwalter mit dem Benutzernamen »admin« und dem Passwort »pass« angemeldet, wählt er aus dem angebotenen Drop-down-Menü die eben erstellten Dashboards aus und kann alsdann ausgiebig erkunden, welche Informationen der Minikube-Cluster herausrücken kann. Diesen Schritt illustriert anschaulich die Abbildung 3.

Auf der Grafana-Site[18] wartet inzwischen eine Reihe von Dashboards rund um Kubernetes auf neugierige Anwender[21] . Hier ist jedoch in vielen Fällen einfach Ausprobieren angesagt: Mitunter scheinen die Entwickler eigene, abweichende Relabeling-Regeln zu verwenden, dann kann es sein, dass ganze Bereiche des Dashboards leer bleiben. Da das Anpassen der Abfragen ein ziemlich aufwändiges Unterfangen sein kann, eignen sich diese Dashboards doch eher als ein guter Startpunkt für selbst geschriebene Versionen.

Abbildung 4: Am Ende des kleinen Experiments zeigt das Dashboard von Minikube verschiedenste Werte zu Kubernetes an.


Was noch?

Bis zu diesem Zeitpunkt hat der Admin ja schon eine ganze Menge an Informationen über den Kubernetes-Cluster zusammengesammelt, aber es geht da immer noch ein Stückchen weiter. Ein interessantes Unterprojekt von Kubernetes heißt beispielsweise »kube‑state‑metrics«[22] :

kubectl create ‑f 07‑kube‑state‑metrics‑deployment.yml

Dieses Projekt holt sich ebenfalls aus dem Kubernetes-API Informationen über vorhandene Objekte und generiert daraus selbstständig neue Metriken. Diese stellt es dann gleich in einer für Prometheus kompatiblen Form bereit[23] . Auf diese Weise liefert es dem Administrator zum Beispiel Hinweise, falls Nodes keine neuen Pods mehr akzeptieren wollen (sie sind dann »unschedulable«), oder auf Pods, die auf der Abschussliste stehen. Ein anschaulicher Überblick über das komplette Monitoring in einem solchen Kubernetes-Dashboard ist in der Abbildung 4 zu sehen.

Fazit

Die hier verwendete Demo-Umgebung vermittelt einen Eindruck davon, wie der Admin seinen Kubernetes-Cluster überwachen kann. Diverse Metriken informieren ihn darüber, was aktuell im Cluster geschieht. Weiteres Feintuning ist darüber hinaus noch möglich: Der Admin kann das produktive Monitoring-System noch um den Alertmanager erweitern und sollte das persistente Speichern von Daten berücksichtigen.

Will er diese Schritte nicht auf jedem Cluster manuell durchführen, kann ihm der Prometheus-Operator ([24] ,[25] ) helfen, mit dem er ohne großen Aufwand ein produktionsreifes Kubernetes-Monitoring installiert.(kki) n

Infos

[1] Kubernetes: [https://kubernetes.io]

[2] Michael Kraus, „Licht ins Dunkel“: Linux-Magazin 06/ 17, S. 28, [http://www.linux-magazin.de/Ausgaben/2017/06/Prometheus]

[3] Beispiel aus der Kubernetes-Dokumentation: [https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml]

[4] Mehr zu Relabeling: [https://www.robustperception.io/life-of-a-label/]

[5] Prom QL: [https://prometheus.io/docs/querying/basics/]

[6] Persistent Volumes: [https://kubernetes.io/docs/concepts/storage/persistent-volumes/]

[7] Stateful Sets: [https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/]

[8] Prometheus Storage: [https://prometheus.io/docs/prometheus/latest/storage/#operational-aspects]

[9] Minikube: [https://github.com/kubernetes/minikube]

[10] Minikube installieren: [https://github.com/kubernetes/minikube#installation]

[11] Listings zum Artikel: [http://www.linux-magazin.de/static/listings/magazin/2017/08/kubernetes-monitoring/]

[12] RBAC: [https://github.com/prometheus/prometheus/blob/master/documentation/examples/rbac-setup.yml]

[13] Prometheus-Docker-Image: [https://hub.docker.com/r/prom/prometheus/]

[14] Config Map: [https://kubernetes.io/docs/tasks/configure-pod-container/configmap/]

[15] Deployments: [https://kubernetes.io/docs/concepts/workloads/controllers/deployment/]

[16] »node_exporter«-Image: [https://hub.docker.com/r/prom/node-exporter/]

[17] Daemon Set: [https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/]

[18] Grafana: [https://grafana.com]

[19] »node_exporter«-Dashboard: [https://grafana.com/dashboards/5174]

[20] Kubernetes Pod-Dashboard: [https://grafana.com/dashboards/1621]

[21] Kubernetes-Dashboards: [https://grafana.com/dashboards?dataSource=prometheus&search=Kubernetes]

[22] »kube‑state‑metrics«: [https://github.com/kubernetes/kube-state-metrics]

[23] Metriken: [https://github.com/kubernetes/kube-state-metrics/tree/master/Documentation]

[24] Prometheus-Operator: [https://github.com/coreos/prometheus-operator]

[25] Doku zum Prometheus-Operator: [https://github.com/coreos/prometheus-operator/tree/master/Documentation]


© gajus, 123RF