Container zum Klicken

von Andreas Stolzenberger

Wer Kubernetes-Cluster verwaltet, hält sich überwiegend auf der Kommandozeile und im Texteditor auf. An vielen Stellen wäre jedoch ein übersichtliches User Interface recht praktisch. Der Artikel stellt Ihnen mit dem Kubernetes Dashboard, K9s, OpenLens und Octant eine Reihe von GUIs vor, die sich mit jeder Distribution nutzen lassen.

Viele kommerzielle Anbieter offerieren im Bundle mit ihrer Kubernetes-Distribution irgendeine Form von grafischer Benutzeroberfläche – meist sogar Open Source. Alle Varianten beherrschen die Basis-API von Kubernetes und somit lassen sich die diversen UIs in der Regel auch gut mit anderen Distributionen oder individuellen Konstrukten nutzen. Im Folgenden stellen wir eine Reihe von GUIs vor, die sich prinzipiell mit jeder Kubernetes-Version einsetzen lassen.

Für diesen Workshop nutzten wir zum einen ein Single-Node-OpenShift-Setup. Außerdem verwendeten wir mit MicroShift [1] eine abgespeckte Variante von OKD, die auf den Single-Node-Betrieb auf Edge-Devices zielt. MicroShift arbeitet auf Systemen ab 2 GByte RAM und zwei CPUs und unterstützt dabei sowohl die x86-64-Architektur als auch ARM (64 Bit). Für unseren Workshop bedienten wir uns einer CentOS-8-Streams-VM mit acht vCPUs und 16 GByte RAM.

Eine Anleitung, wie Sie MicroShift auf einer EL8-, Centos-Streams-8- oder Fedora-35-Distribution installieren, finden Sie auf der Homepage [2] des Projekts. MicroShift bringt mit dem "Kubevirt-Hostpath-Provisioner" praktischerweise gleich eine Storage-Klasse mit. Darüber generieren Sie somit automatisch die PVs (Persistent Volumes), die einige der hier vorgestellten Tools benötigen. Nutzen Sie ein Kubernetes-Setup ohne Storage Provisioner, müssen sie die passende PVs manuell erstellen.

Kubernetes Dashboard

Vom Kubernetes-Projekt selbst stammt die simple Web-UI "Kubernetes Dashboard" [3]. Sie liefert dem Administrator im Webbrowser einen Überblick über alle Ressourcen im Cluster, stellt Logs dar und erlaubt, eine Shell in laufenden Pods zu nutzen. Sammelt der Cluster die Metriken, etwa CPU, Memory, Pods oder Applikationslasten, ein, lässt sich all dies grafisch im Dashboard darstellen.

Zu den Highlights gehört, dass die Webapplikation Zusammenhänge zwischen den Ressourcen sehr klar darstellt. Klicken Sie etwa auf einen Pod, listet das Dashboard ausführlich die zugehörigen Container samt Images und Environment-Variablen auf. Es zeigt die passenden PVs und ConfigMaps und mit "Kontrolliert von" auch, ob der Pod unter der Kontrolle eines ReplicaSets, StatefulSets und/oder eines Deployments steht. Der Nutzer kann sich mit einem Klick die Logs der Pods anzeigen lassen oder im Browser eine Shell in einem der Container öffnen.

Zwar gibt es eine Sektion im Interface, die "Custom Ressource Definitions" auflistet, in unserem Testlauf tauchten darunter aber nicht alle benutzerdefinierten "Kinds", also Kubernetes-Ressourcen wie "Routes", auf. Diese muss der Administrator weiterhin per CLI verwalten. Zudem reagiert die GUI nur bedingt auf die Auswahl der Display-Sprache. Sowohl die Option "English" als auch "Deutsch" zeigen ein buntes Durcheinander aus teils englischen, teils deutschen Dialogen an.

Die Installation des Dashboards direkt auf dem zu verwaltenden Cluster ist eigentlich recht trivial, denn auf dem GitHub-Repository des Projekts findet sich eine ausführliche YML-Datei namens "aio/deploy/recommended.yaml", die alle nötigen Services, Roles und Deployments deklariert.

Für unseren Aufbau mit MicroShift passt die Vorgabe aber nicht ganz. Zum einen erstellt sich das Dashboard eine ClusterRole, deren Privilegien nicht für den Admin-Zugriff ausreichen. Damit darf das Dashboard nicht auf alle Ressourcen zugreifen – aber genau das möchte der Admin mit der GUI ja erreichen. Daher ändern wir in einer Kopie von "recommen- ded.yaml" einfach im Abschnitt

und weisen damit dem Service-Account "kubernetes-dashboard" die Rolle "cluster-admin" zu.

Seit ein paar Versionen besteht Kubernetes Dashboard zudem vehement darauf, nur noch Zugriffe via HTTPS anstelle HTTP zuzulassen. Das klappt aber nur dann, wenn der Nutzer den Zugang zum Dashboard über ein simples Port-Forwarding nutzt. Bei unserem Praxisversuch funktionieren weder Ingress-Regeln noch eine Route, weil der Name der URL via Reverse-Proxy vom Zertifikat abweicht und der Browser eine Verbindung ablehnt.

Das Problem lässt sich zumindest teilweise beheben, indem Sie den Dashboard-Pod mit anderen Parametern starten. Details dazu entnehmen Sie dem gleichnamigen Kasten. Dann startet das Dashboard auch mit dem HTTP-Protokoll. Allerdings muss der Zugang dann tatsächlich über einen SSL-terminierenden Proxy erfolgen, da sich das Dashboard trotz "enable insecure login" weiterhin weigert, den Admin ohne eine SSL-Verbindung via Token zu authentisieren.

Zusammengefasst lässt sich das Dashboard flott auf dem zu verwaltenden Cluster installieren und gibt im Webbrowser einen guten Überblick, speziell über die Zusammenhänge der Ressourcen. Die Custom Ressource Definitions erscheinen leider nicht immer korrekt. Der SSL-Zwang der neueren Versionen stört in Umgebungen mit Routen und Reverse-Proxies. Besser wäre, die Applikation überließe dem Administrator, wie und wo er eine SSL-Terminierung für die Applikation einsetzt, anstatt SSL vorzuschreiben und in Eigenregie selbstsignierte Zertifikate zu generieren.

K9s

Das nächste Managementtool lässt sich mit einem simplen Satz beschreiben: K9s [4] ist der Norton Commander für Kubernetes. Hier handelt es sich also nicht wirklich um eine GUI, sondern eine klassische TUI (Text UI). Anstelle der Maus nutzt der Administrator hier Tastaturkürzel, um zwischen Ressourcen und Ansichten zu wechseln. Wer mit dem Werkzeug und dessen Tastenbelegung vertraut ist, navigiert schneller durch die Ressourcen seiner Kubernetes-Umgebung als mit jedem anderen verfügbaren Tool oder der Kommandozeile.

Die Open-Source-Software lässt sich auf den verbreiteten Clientplattformen wie macOS, Windows oder Linux installieren. Unter macOS oder Linux nutzen Sie den Paketmanager brew, unter Windows verwenden Sie Chocolatey, um das Tool einzurichten. K9s verwendet eine kubeconfig-Datei, um sich mit einem Cluster zu verbinden. Deren Ort gibt entweder die Umgebungsvariable "KUBECONFIG" an oder sie liegt im Home-Verzeichnis des Nutzers unter ".kube/config".

Enthält die kubeconfig-Datei Informationen zu mehreren Clustern, zeigt K9s diese nach dem Start zur Auswahl an. Zwischen den verschiedenen Ressourcen eines Clusters wechseln Sie mit ":"-Kommandos wie ":pod" oder ":replicaset", wobei das Tool natürlich eine Kommandovervollständigung via Tab-Taste offeriert.

K9s kennt dabei neben den Standardressourcen auch alle installierten CRDs (Custom Ressource Definitions), sodass Nutzer in einem OpenShift/MicroShift-Umfeld via ":route" an die Übersicht zu den Routen kommen.

K9s merkt sich die zuletzt verwendeten Namespaces und lässt den Admin über die Hotkeys 1 bis 5 schnell zwischen den Namespaces wechseln. Die K9s-Kommandozeile erlaubt ferner, in den Ressource-Dateien nach Stichworten zu suchen. Dazu geben Sie statt ":" für ein Kommando einfach ein "/" ein. Tippen Sie beispielsweise "/nginx" ein, erhalten Sie eine Liste aller ausgewählten Ressourcen im aktuellen (oder allen) Namespace, die nginx enthalten.

Wie üblich bei TUI-Tools kann der Nutzer die Hotkeys und das Farbschema nach eigenem Gutdünken modifizieren. K9s verfügt über eine gut dokumentierte Plug-in-Architektur, sodass sich das Tool im Funktionsumfang erweitern lässt. Ein paar sehr nützliche Add-ons gibt es bereits in der Basisversion.

Add-ons für K9s

Das ab Werk vorhandene Add-on "Popeye" scannt den aktuellen Cluster auf mögliche Fehler und Konfigurationsprobleme, ohne dabei aber etwas an dessen Konfiguration zu ändern. Der Report versorgt Sie mit einer langen Liste möglicher Schwachstellen. In unserem Workshopaufbau gab Popeye beispielsweise Warnungen aus, dass Pod-Definitionen ohne Ressourcenlimits oder Securitykontext laufen, dass in einem Pod auf ein Image ohne Tag verwiesen wurde oder dass wir Ports ohne Benennung einsetzen. Auf den ersten Blick wirkte der lange Bericht in unserer eher kleinen Umgebung etwas zu detailliert. Bei genauem Hinsehen mussten wir Popeye allerdings recht geben: Alle diese kleinen Unstimmigkeiten können in einer großen Umgebung früher oder später zu Problemen führen.

"Pulse" hingegen erstellt einen klassischen Klötzchengrafik-Überblick über die Ressourcenverteilung und -auslastung. Letzteres gibt es natürlich nur bei Clustern, die Metriken einsammeln. Natürlich liefern Webtools wie Grafana hier einen wesentlich detaillierteren und genaueren Überblick. Dennoch zeigt die Pulse-UI dem Admin mit wenigen Symbolen sehr schnell, wo es in seinem Cluster Probleme gibt. Mit "xray" wiederum bekommen Sie wie schon beim Kubernetes Dashboard eine hierarchische Übersicht der laufenden Ressourcen mit allen wichtigen Dependencies geliefert.

Gerade weil K9s ohne Maus arbeitet, ist es vielleicht das effizienteste Tool, um Kubernetes-Cluster zu verwalten. Schneller kann der Administrator kaum durch seine Cluster navigieren. Die eingebauten Tools wie Popeye helfen, Probleme im Cluster frühzeitig zu erkennen und zu adressieren. Aber wie üblich gibt es bei einer TUI zwei gespaltene Fraktionen: Diejenigen, die Tools wie K9s lieben, und diejenigen, die sie hassen. Das Werkzeug ist also etwas für Nutzer, die auf Software wie den Norton Commander und seine Open-Source-Klone setzen.

OpenLens

Aus dem Hause Mirantis stammt der populäre Kubernetes-Desktop "Lens" für Windows, macOS und Linux. Der Hersteller selbst bezeichnet Lens gar als "The Kubernetes IDE". Neben der kostenlosen Version ohne Support gibt es eine kommerzielle Variante mit Support vom Hersteller. Lens basiert auf freiem Code und daher gibt es eine freie Upstream-Variante namens "OpenLens" [5].

Diese verlangt im Unterschied zur kostenlosen Version von Lens keinen Login via Mirantis-Account. Wie K9s liest auch OpenLens aus einer kubeconfig-Datei die Zugangsdaten zu den Clustern. Die gefundenen Cluster können Sie an eine Hotbar in der GUI anheften und so schnell zwischen den Ressourcen wechseln.

Das eigentliche Anwendungsfenster nutzt das fast schon klassische Design mit drei Frames. Die linke Seite listet hochkant hierarchisch die Ressourcen des Cluster, rechts oben gibt es die Übersicht der gewählten Ressourcen und darunter die Details zur oben ausgewählten.

Die Detailansicht erlaubt die Nutzung mehrerer Tabs, sodass der Admin beispielsweise zwischen der Logausgabe eines Pods, dessen Ressourcendatei oder einer Shell hin- und herschalten kann. OpenLens integriert den "Monaco Editor" [6], den Editor hinter Visual Studio Code, zum Editieren der Ressourcendateien. Damit kann der Nutzer diese Dateien sehr komfortabel direkt in der GUI anpassen, ohne dass ein separates Fenster aufgeht.

In einem gesonderten Abschnitt listet OpenLens die "Custom Ressources" auf. Allerdings erkennt das Tool beispielsweise die von OpenShift, OKD oder MicroShift verwendeten Routen nicht, was beispielsweise K9s problemlos beherrscht. Auch kann OpenLens nicht die Metriken eines OpenShift/OKD-Clusters abrufen und darstellen. Laut eines Blog-Posts auf der GitHub-Seite des Projekts soll das daran liegen, dass Lens ausschließlich über das HTTP-Protokoll auf die Prometheus-Instanz eines Kubernetes-Clusters zugreift, um Metriken abzurufen.

Der Metrik-Server eines OpenShift/OKD-Setups verwendet aber ausschließlich das HTTPS-Protokoll. K9s und das als Nächstes vorgestellte Octant scheinen allerdings mit dem HTTPS-Zugang zu Prometheus keine Schwierigkeiten zu haben.

Ab der Version 6 offeriert OpenLens eine Funktion, um Helm-Charts zu managen. Der Nutzer hinterlegt dazu Helm-Repositories in der Konfiguration und kann direkt aus dem Helm-Menü heraus Charts ausführen. Die Konfigurationsdatei des Charts erscheint zuvor im Editor, sodass Sie alle nötigen Parameter unmittelbar eingeben können.

Auch OpenLens verfügt mit "Extensions" über eine Plug-in-Architektur. Bei unseren Praxisversuchen schnitt die aktuell aber nicht so gut ab. Lediglich ein Community-Plug-in, das eine wabernde Ressource-Map anzeigt, funktioniert. Eine sinnvolle Extension wie "Kubescape", die einen Funktionsumfang wie Popeye für K9s liefern soll, friert das OpenLens-Fenster regelmäßig ein und die Anwendung lässt sich nur noch über den Taskmanager beenden.

Insgesamt kann OpenLens mit seiner hübschen, aufgeräumten Three-Frames-UI und dem integrierten Editor punkten. Somit verdient es sich durchaus den Beinamen "Kubernetes UI". Das Tool lässt sich einfach und intuitiv bedienen und läuft flott. Aber im Vergleich zu K9s fehlen hier und da ein paar Funktionen.

Octant

Bei Octant [7] handelt es sich um die WebGUI von VMware Tanzu. Das Open-Source-Tool funktioniert aber auch stand-alone, um andere Kubernetes-Ressourcen zu verwalten. Anders als Kubernetes Dashboard läuft Octant jedoch nicht auf dem Kubernetes-Setup selbst. Sie installieren das Tool auf seiner Workstation unter Windows, macOS oder Linux. Dort liest es die lokale kubeconfig-Datei aus und startet dann auf 127.0.0.1:7777 einen Webserver.

Die WebGUI unterteil Octant prinzipiell in drei Bereiche: "Applications View" fokussiert die Darstellung auf definierte Anwendungen und zeigt die Relationen der Ressourcen (Deployments, Secrets, Replicasets, Pods et cetera) zueinander. Allerdings funktioniert der dabei verwendete "Ressource Viewer" nur auf ausgewachsenen Kubernetes-Installationen mit einem laufenden Autoscaler-Dienst. In unserem Setup zeigt Octant beispielsweise die Ressourcenabhängigkeiten des OpenShift/OKD-Clusters, jedoch nicht die von MicroShift.

"Cluster-Overview" zeigt die Ressourcen des Kubernetes-Setups selbst, wie CRDs, Nodes, Cluster Roles oder auch PVs. Diese Sektion soll dem Administrator helfen, den Cluster an sich zu verwalten. "Namespace Overview" schließlich zeigt die Ressourcen innerhalb der Application-Namespaces an. Dabei erweist sich der "Summary"-Tab als besonders hilfreich. Er listet alle Ressourcen eines Pods oder Replica-Sets auf und zeigt dabei gleich an, welche Parameter diese Ressource aus welchen Secrets oder Configmaps bezieht.

Diese ausführliche Darstellung hat natürlich eine Schattenseite. Gerade bei aufwendigen Ressourcen wirkt das Fenster völlig überfrachtet und lässt die Übersicht vermissen. Eine Option, bei der sich Ressourcendetails wie in einer Baumansicht ein- und ausklappen ließen, wäre hier wünschenswert. Dass die GUI so eine Funktion durchaus beherrscht, zeigt der Tab "Metadata". Hier fächern Sie die Objekte innerhalb einer Ressourcendefinition hierarchisch auf und sehen Details ein.

In unserem Aufbau funktioniert diese Ansicht allerdings nicht korrekt. In einem AWX-Rollout behauptet die Metadaten-Ansicht des laufenden AWX-Pods, dass die Felder "f:image" unter "spec.containers" für die vier Container innerhalb des PODs leer wären. Der YAML-Quelltext zeigte diese jedoch korrekt an – damit ist die Metadaten-Ansicht praktisch nutzlos:

Wie OpenLens hat auch Octant Tabs für die Logansicht, eine Shell im gewählten Container oder einen eingebundenen Webeditor (ebenfalls Microsofts Monaco-Editor) im Angebot. Und wie die anderen Werkzeuge auch versorgt Octant den Admin mit einer Schnittstelle für Plug-ins. Die Auswahl hält sich aber noch in Grenzen. Das im Test installierte Helm-Plug-in zeigt beispielsweise nur die bereits installierten Charts. Es bietet aber keine Option, neue Charts aus einem Repository einzurichten.

Weiterhin fällt auf, dass Octant deutlich langsamer ans Werk geht, als das bei OpenLens oder K9s der Fall ist. Speziell wenn der Administrator auf Ressourcen mit vielen Inhalten zugreift, lässt sich Octant viel Zeit. Das Werkzeug listet Custom-Ressources in einem eigenen Menü problemlos auf. Wie aber schon bei OpenLens zeigt Octant keine OpenShift- oder MicroShift-spezifischen "Routes" an. Das kann von den hier aufgeführten Applikationen nur K9s. Zu den Stärken von Octant gehört vor allem die ausführliche "Summary View". Im Gegenzug fehlt es dem Werkzeug damit etwas an Übersicht.

Fazit

Den Vergleich der Kubernetes-GUIs gewinnt ein Tool, das eigentlich gar keine GUI ist: K9s. Das Werkzeug überzeugt sowohl in Sachen Performance als auch beim Funktionsumfang und der Kompatibilität zu den getesteten Umgebungen. Ein textgesteuertes Interface ist aber nicht jedermanns Sache. Wer lieber mit einer richtigen GUI und der Maus ans Werk geht, der ist mit OpenLens bestens beraten. Hier gefällt vor allem die Übersicht und der IDE-Ansatz mit integriertem Code-Editor. Negativ fallen in unserem Workshop die Inkompatibilitäten zu den verwendeten OKD, OpenShift- und MicroShift-Umgebungen auf.

Für simple Setups reicht das Kubernetes Dashboard. Aber gerade bei kleinen Umgebungen will der Administrator vielleicht nicht Ressourcen des Kubernetes-Nodes mit einem Managementtool belegen. Hier erscheint eine rein clientbasierte Lösung wie OpenLens oder K9s besser. Octant zeigt gut Ansätze mit einer starken Detailansicht, muss aber noch etwas an der Übersicht und der Performance feilen. Weil es sich auf Kubernetes-Services wie den Autoscaler oder die Metriken verlässt, eignet es sich eher für größere Umgebungen – wobei hier dann wieder die Performanceprobleme deutlicher stören.

GUIs für Kubernetes