Kubernetes-Monitoring mit Instana (Teil 1)

Einführung: Weshalb Kubernetes und Instana?

Cloud- oder cloud-ähnliche Dienste bedienen bekanntermaßen das “As a Service”-Prinzip. Egal ob “Software”, “Function” oder “Platform as a Service”, meist steckt eine containerbasierte Infrastruktur dahinter.
Dabei ist es unerheblich, ob diese Container auf Bare Metal oder über einen zwischengeschalteten Hypervisor bereitgestellt werden. Ob Docker, rkt oder LXC/LXD zum Einsatz kommen – das Prinzip bleibt gleich:
Applikationen in einer isolierten Umgebung skalierbar deployen, und das so oft und flexibel wie möglich.

Docker und Co.

Container haben dank Werkzeugen wie Docker die IT-Landschaft revolutioniert und Cloud-Infrastrukturen erst denkbar gemacht. Umsetzbar wurden diese erst durch hohe Automatisierungsgrade und Kulturen wie DevOps, Scrum, Lean etc.
Im Grunde ist alles viel flexibler, dynamischer und auch ein Stück weit volatiler geworden.

Die Komplexität

Um dieses Potential auf der Seite der Infrastruktur nutzbar machen zu können, wurden Lösungen wie Kubernetes nötig.
Diese kümmern sich um Provisionierung, Skalierung und Koordinierung von Containern.
Kubernetes managed dabei teilweise tausende Container und ihre dazu notwendige Infrastruktur (z. B. Service Discovery, Routing, Load Balancing uvm.).

Die Probleme

Zusammengefasst kann man sagen, dass die Softwareentwicklung sowie der Betrieb von IT-Infrastruktur mit einem hohen Grad an Automatisierung und Dynamik geschehen. Doch was tun, wenn mal etwas nicht so rund läuft, wie es soll? Genau dafür hat man eben Überwachungswerkzeuge, die Alarm schlagen, wenn bestimmte Werte wie CPU oder RAM Auslastung oder Netzwerk / Storage Auslastung etc. über oder unter bestimmte Grenzwerte geraten. Stichwort Monitoring.

Statisches Monitoring in dynamischen Umgebungen?

Klassische Lösungen für Server-Monitoring beschäftigen sich mit Servern, ob als virtuelle Maschine oder Bare Metal. Die klassische Überwachung ist dabei ziemlich statisch: Es gibt Server, einzelne Services und deren Metriken.
Mit klassischen Servern war keine hohe Dynamik notwendig, denn jeder Server hatte seine besondere Bedeutung und definierten Aufgabenbereich. Man konnte die Metriken der bekannten Komponenten auswerten und bei Bedarf Alarm schlagen.

So weit, so gut und richtig. Jedoch kommt bei dieser Form des Monitorings die Frage auf, ob diese Werte in einer dynamischen Umgebung überhaupt noch aussagekräftig sind. Bedeutet eine hohe CPU-Auslastung ein Server- oder Service-Problem? Ist es überhaupt ein Problem oder läuft alles noch wie gewohnt und die Werte sind mit Skalierung (z. B. durch Kubernetes) zu lösen?

Rückblickend betrachtet war das ein valider Ansatz. Aber spätestens durch den breiten Einsatz von Containern und dem Weg zu hyperkonvergenter Infrastruktur verwischen die bisher klaren Grenzen zwischen Hard- und Software.

Natürlich wäre es fatal, Systemmetriken wie CPU, RAM, Storage oder Netzwerk etc. zu vernachlässigen. Jedoch müssen diese über den gesamten Verbund (Cluster, Rechenzentrum, Cloud etc.) betrachtet werden. Ansonsten läuft man Gefahr, den Wald vor lauter Bäumen nicht mehr zu sehen.
Zusätzlich gilt es bei einer serviceorientierten Architektur eben auch die Services selbst zu überwachen.

Und genau hier kann sich Application-Performance-Management-(APM-)Software wie Instana von den klassischen Monitoring-Lösungen absetzen. Instana ist eine Software für Application Performance Management, welches in dieser Konsequenz die Überwachung von Infrastruktur enthält.

Da Kubernetes der derzeitige De-facto-Standard im Cloud-Umfeld ist, werde ich eine einfache Kubernetes-Umgebung – mittels Minikube – installieren, den Instana Agent sowie die von Instana bereitgestellte Demo-Applikation “Robot Shop” deployen. Dieses Beispiel soll uns nachher als Spielfeld für das Monitoring dienen.

Vorbereitung

Fangen wir mit der Einrichtung einer einfachen Kubernetes-Umgebung an. Um das Rad nicht neu zu erfinden, nutze ich den Guide von Kubernetes für Minikube (Minikube , bzw. Minikube Install ).

Minikube Install

Der Anleitung folgende ist Minikube mittels ein paar Kommandos im Terminal schnell installiert.

→ Anmerkung: Ich habe Minikube in Version 1.3.1 verwendet, da mit 1.4.0 Probleme auftraten. Zusätzlich benutze ich Kubernetes 1.15.3, weil es bei Helm 2.14.x und Kubernetes 1.16 zu Inkompatibilitäten kommt, was wiederum manuelle Anpassungen an den Services erforderlich macht. (siehe https://github.com/helm/helm/issues/6374 )

Als Hardware-Plattform nutze ich eine AWS EC2 mit T3.xLarge sizing als Spot Instance.

Minikube wird direkt auf die EC2-Instanz installiert, da es sich hierbei ohnehin um eine virtualisierte Umgebung handelt.
$ curl -sLo minikube https://storage.googleapis.com/minikube/releases/v1.3.1/minikube-linux-amd64 && chmod +x minikube && sudo install minikube /usr/local/bin/

Minikube ist installiert und die Umgebung kann mit “minikube start” erstellt werden.
$ minikube start --vm-driver=none --kubernetes-version='1.15.3'

Da Instana bereits ein Helm Chart für den Agent zur Verfügung stellt, will ich dieses auch nutzen. Deshalb wird Helm auch noch installiert und eingerichtet.

Die Installation erfolgt über ein Installationsskript, gefolgt von der Initialisierung von Helm, das alle nötigen Komponenten installiert.
curl -L https://git.io/get_helm.sh | bash helm init

Damit wären die wichtigsten Komponenten installiert und gestartet. Was nun noch fehlt ist das Monitoring.

Instana Agent Deployment

Der Agent kann anschließend über das Helm chart direkt in Kubernetes deployed werden.
Hierzu muss man lediglich die bereits vordefinierten Kommandos aus der Instana Management Konsole (Web-Übersicht) kopieren und in der Konsole einfügen.

Wurde der Agent erfolgreich deployed, so erscheint die soeben installierte Kubernetes-Umgebung auf der Map-Ansicht in Instana nach wenigen Minuten.
Der Name K8s-Cluster wird durch den Parameter agent.zone definiert und kann entsprechend frei vergeben werden. Der Einfachheit halber wurden die Voreinstellungen seitens Instana direkt übernommen.

Bereits jetzt hat der Instana Agent mittels AutoDiscovery-Technologie erkannt, dass das System, auf dem der Agent läuft, eine AWS -EC2-Instanz ist.
Ebenso hat er die laufende Kubernetes-Umgebung und die laufenden Docker-Container erkannt.
Dadurch, dass Kubernetes erkannt wurde und der Instana Agent seine Sensoren entsprechend selbstständig installiert und aktiviert hat, können wir ab sofort Kubernetes-Metriken in Instana anzeigen.

Nur: Wer betreibt denn schon eine leere Kubernetes-Umgebung? Genau, niemand.

Deployment der Beispielapplikation “Robot Shop”

Um die ganze Umgebung mit ein wenig Leben zu füllen, liegt es nahe, eine oder mehrere Applikationen zu deployen. Idealerweise erzeugt man noch ein wenig Last, denn nur so kann man eine produktiv genutzte Applikation ansatzweise realistisch simulieren.

Für Testzwecke gibt es im Instana-Repository die Anwendung “Robot Shop” (https://github.com/instana/robot-shop ) – eine kleine Webshop-Simulation mit einem praktischen Lastgenerator.

Also Repository klonen, Namespace erzeugen und deployen!
$ git clone https://github.com/instana/robot-shop.git [...] $ cd robot-shop/ $ kubectl create namespace robot-shop $ kubectl -n robot-shop apply -f K8s/descriptors [...]$

Schalten wir nun noch den Lastgenerator hinzu und sehen, wie sich die Umgebung mit Leben füllt:
$ kubectl -n robot-shop apply -f K8s/load-deployment.yaml

In einem Zeitraum von ca einer halben Stunde sind etwas mehr als 11000 Requests durch den Lastgenerator auf den Robot Shop eingegangen. Während dieser Zeit kann man sich die Kubernetes-Daten in Ruhe aus der Nähe betrachten.

Sehen wir uns nur ganz kurz die anderen, für sich selbst sprechenden Übersichten und Metriken an:

Fazit: Produktionstaugliches Monitoring in fünf Minuten?

Es ist kaum zu glauben, aber ein produktionstaugliches Monitoring ist damit innerhalb von fünf Minuten aufgesetzt und konfiguriert.

Ich sehe meine Service-Requests, die Latenzen, Performance-Leaks, fehlerhafte und erfolgreiche Requests, ganze Aufrufketten und die dazugehörigen Ereignisse.
Instana gestaltet die Integration der zu überwachenden Komponenten (Hosts, Kubernetes, Container, Applikationen) so, dass man als Anwender nahezu keinen Aufwand bei der Einrichtung und dem Betrieb hat.

Dabei muss man ganz klar die Vorzüge des AutoDiscoverys (https://docs.instana.io/core_concepts/auto_discovery/ ) hervorheben, was einem eine Menge Zeit und Arbeit abnimmt – und gerade Zeit ist in unserem Business immer knapp.
Beliebige, auf Java basierende Software kann in der Regel ohne weiteres Zutun automatisch instrumentiert werden.
Neben Java unterstützt Instana natürlich auch noch eine stetig wachsende Liste an anderen Sprachen, Frameworks und Technologien.

Im zweiten Teil der Blog-Serie werde ich auf die einzelnen Metriken und Informationen eingehen, die das Tool uns liefert.

Wenn Du Instana unter vollem Funktionsumfang ausprobieren möchtest, ist unter diesem Link eine 14tägige Trial verfügbar:

Instana Trial