Rund um Container hat sich ein großer Softwaremarkt entwickelt. Da die Basissoftware Open Source ist, bieten zahlreiche Hersteller Add-ons an, die meist für Kubernetes fehlende Zusatzfunktionen implementieren – zum Beispiel Backups, mehr Security, umfangreiche Netzwerkfunktionen und natürlich ein bequemes GUI-basiertes Managementtool. Obwohl der größte Teil des Kubernetes-Managements auf der Verarbeitung von YAML-Dateien beruht, sind grafische Werkzeuge unschlagbar, um sich einen Überblick über alle Cluster-Ressourcen zu verschaffen.

Portainer ist ein solches Managementtool, das im Webbrowser läuft und ursprünglich eine GUI für Docker und Swarm war, aber mit Version 2.0 sein Tätigkeitsfeld auf Kubernetes ausgeweitet hat. Portainer versucht das Management dieser Cloudumgebungen zu vereinheitlichen, indem es eigene Konzepte wie "Applications" und "Stacks" verwendet, die hinter den Kulissen auf den Container-Plattformen umgesetzt werden. Wie ein Blogbeitrag auf der Firmenhomepage verrät, kommt Portainer auch zum Einsatz, um auf dem Roboterhund Spot von Boston Dynamics containerisierte Software zu deployen.

Portainer ist als Community-Version unter Open-Source-Lizenz verfügbar wie auch als Enterprise-Subscription, die über den Support hinaus ein paar Features mehr mitbringt, etwa ein flexibleres Rollenmanagement. Im Folgenden schauen wir uns die Enterprise-Version in Version 2.0.2 etwas näher an. Die Community-Version liegt seit Februar in Release 2.1 vor, das Version 3 der Docker-Compose-Files unterstützt.

Wenig überraschend wird Portainer auch als Container installiert. Für Docker bietet die Dokumentation einen einfachen Commandline-Aufruf, der den Container mit ein paar Optionen startet. Neben dem als Datenspeicher verwendeten Volume ist es wichtig, den lokalen Docker-Socket in dem Container zu mounten, denn darüber kommuniziert Portainer mit dem Docker-Daemon. In Docker Swarm lässt sich Portainer als sogenannter Stack ausrollen, der über eine YAML-Datei definiert wird, die es auf der Website zum Download gibt.

Die Installation auf Kubernetes kann über ein auf der Website zu findendes YAML-File erfolgen oder mit dem Paketmanager Helm. Aus Portainer-Sicht ist eine solche Installation "lokal", denn Portainer läuft ja im Cluster. Für das Remote-Management von Clustern bietet Portainer darüber hinaus einen Agenten, der im Cluster zu installieren ist. So kann dann zum Beispiel Portainer, das als lokaler Container in Docker läuft, auch eine entfernte Kubernetes-Installation managen.

Per Default ist die Portainer-GUI auf Port 9000 erreichbar. Wer das ändern möchte, muss den Container mit einem anderen lokalen Port für die GUI starten. Nach der erstmaligen Eingabe der URL "http://Server:9000/" wurden wir zum Anlegen eines neuen Admin-Kontos plus Passwort aufgefordert. Alternativ ist es möglich, sich mit dem vom Apache-Webserver bekannten htpasswd-Tool einen Hash zu erzeugen und ihn mit "--admin-password" an das Startkommando des Containers anzuhängen. Das ist allemal sicherer, als eine nach außen offene Web-GUI anzubieten und dort den Admin-User anzulegen, aber auch deutlich umständlicher. Als dritte Alternative lässt sich das Klartextpasswort auch in einer Datei hinterlegen, die hinter dem Schalter "--admin-password-file" folgt.

Nach dem ersten Login bot uns Portainer die Auswahl der zu managenden Umgebung ("Endpoint") an: eine lokale Docker-Installation, eine lokale Kubernetes-Umgebung oder die Verbindung zu einem Portainer-Agenten. Danach verbindet sich Portainer zur gewählten Umgebung und zeigt das Dashboard mit einer Übersicht der verwalteten Instanz an. Hier blendet Portainer auch News über neue Releases ein, die aber nicht unbedingt berücksichtigen, welche Version installiert ist. So kann es gut sein, dass ein Hinweis zum Update auf Version 2.0.1 erscheint, obwohl bereits Version 2.0.2 installiert ist.

Nach dem Anlegen des Users und dem Einrichten eines Endpoints landeten wir in der Web-GUI, in der auf der linken Seite das Menü zu sehen war. Hier besteht eine Zweiteilung globaler Einstellungen ("Settings") und Endpoint-spezifischer Menüpunkte wie "Applications", "Configurations" und so weiter. Leider ist die Menüstruktur nicht unbedingt intuitiv und die Bedienung wird dadurch erschwert, dass immer nur ein Menüpunkt ausgeklappt ist. Klickten wir auf einen anderen, klappte der alte wieder ein und die Unterpunkte verschwanden. Das führte zu dem Effekt, dass wir uns wiederholt fragten, wo nochmal bestimmte Einstellungen zu finden waren.

Im Settings-Menü finden sich die Einstellungen für die Portainer- und Cluster-Admins. Dort fügen die Verantwortlichen andere Admin-User ebenso hinzu wie Benutzer, die später auf dem Cluster nur Anwendungen betreiben dürfen. Leider sind die Seiten, auf denen die entsprechenden Dinge bearbeitet werden, oft recht rudimentär ausgestaltet und es fehlt beispielsweise in der Listenansicht ein Edit-Button für das aufgelistete Objekt. Dann muss erst auf die Ansicht navigiert und dort der Edit-Button gesucht werden.

Bei den Usern gibt es weder in der Liste noch auf der User-Seite selber eine Möglichkeit zum Bearbeiten: keine Rechte, keine Rollen oder eine Möglichkeit, zu einem User eine Datenquelle wie LDAP anzugeben. Ein weiterer Schalter vergibt Adminrechte, das war's. Wer einem Benutzer eine Rolle zuweisen möchte, aber auch nicht etwa unter dem Rollen-Menü, sondern über die Endpoints, auf die sich die Rollen alle beziehen. Um einen Benutzer also etwa mit den Rechten "Endpoint Administrator" oder "Regular User" auszustatten, muss der Portainer-Admin auf die "Endpoints" wechseln und in der Liste hinter dem Endpoint auf den Link "Manage Access" klicken. Anschließend darf er ein Access-Objekt anlegen, das einen Benutzer oder eine Gruppe mit einer ausgewählten Rolle verbindet. Die vier Rollen sind fix vorgegeben und lassen sich nicht bearbeiten oder ergänzen.

Analog zur Konfiguration der Endpoint-Permissions lassen sich auch die Resource Pools auf Benutzer und Gruppen mappen. Sie enthalten die Limits an Speicher und CPU, die zugehörige Anwendungen verbrauchen dürfen. Durch eine solche Zuweisung des Resource Pools lassen sich im Endeffekt die Ressourcen begrenzen, die ein "Regular User" bei einem Endpoint verbrauchen darf. Darüber hinaus gibt es Beschränkungen für die Zahl der externen Loadbalancer, die im Public-Cloud-Fall ja Kosten verursachen, sowie Storage-Quotas. Grundsätzlich unterstützt Portainer die Authentifizierung per LDAP, Active Directory und einen OAuth-Provider. Die Enterprise-Version bietet darüber hinaus noch eine vereinfachte "One Click Configuration".

Die erste Anlaufstelle für normale User, die Container-Anwendungen betreiben wollen, ist das Applications-Menü. Dort lässt sich eine "Anwendung" starten, was eine Reihe von Containern, Volumes und Konfiguration umfasst, die je nach darunter befindlichem Container-Management-System unterschiedlich umgesetzt wird. Die Settings-Menüpunkte, die User wegen mangelnder Rechte nicht benutzen dürfen, sind dann ausgeblendet. Für User von Docker (Swarm) ergibt sich ein leicht anderes Bild, denn hier stehen die "Stacks" und Container im Zentrum, Applications gibt es hier nicht.

Leider bietet die aktuelle Enterprise-Version von Portainer bei Kubernetes-Endpoints keine Vorlagen für verbreitete Anwendungen, wie es sie im Docker-Modus "App Templates" gibt. Derzeit muss sich der Anwender mit der Eingabe eines Docker-Image-Namens begnügen. Die restlichen Details der App bestimmen Fragen wie die Deployment-Art (auf einem oder mehreren Nodes), die Anzahl der Replicas, angebundene IP-Adressen, Volumes und so weiter. Hier sind nicht alle GUI-Elemente ausgereift und selbsterklärend. Wollten wir im Test zum Beispiel beim Anlegen einer neuen Applikation auch gleich ein neues Volume erstellen, hatte der Button "Create new Volume" keine Funktion. Beim Speichern der App wurde das neue Volume dann aber angelegt.

Beim Anlegen einer Anwendung erschien sogleich die Meldung "Created successfully", doch das hat nicht viel zu bedeuten. Es ist nämlich möglich, dass etwa der nötige Container nicht läuft. Hier ist es also angesagt, sich selbst noch einmal alle Details der App anzusehen und den Status der Container noch einmal gesondert zu überprüfen. Übersichtlicher wäre es, in der Liste der laufenden Applications diejenigen farblich hervorzuheben, bei denen etwas nicht stimmt.

Die Mount-Punkte der Volumes in einer Applikation lassen sich nicht nachträglich ändern. Dazu muss ein neues Volume angelegt und das alte gelöscht werden, was natürlich damit einhergeht, dass alle Daten auf dem Volume weg sind. Manuell ließen sich die Daten migrieren, indem eine temporäre Application zum Einsatz kommt, die Zugriff auf beide Volumes hat und dann die Daten vom einem in das andere kopiert.

Es ist nicht möglich, in Portainer die YAML-Dateien zu ändern, die zu den Kubernetes-Ressourcen gehören. Auch das wäre eigentlich eine Mindestanforderung an ein Kubernetes-Admin-Tool, denn gerade wenn die GUI es nicht erlaubt, alle Facetten von Cluster-Ressourcen zu verändern, sollte dann als Notnagel noch die Bearbeitung der YAML-Konfiguration vorhanden sein. Dies ist zum Beispiel in der Kubernetes-IDE Lens möglich, die beim gegenwärtigen Entwicklungsstand auch nicht erlaubt, jedes Feature zu bearbeiten. Der eingebaute YAML-Editor bietet sogar einen rudimentären Syntax-Check. Hier könnte sich Portainer eine Scheibe abschneiden.

Portainer kann seine Herkunft aus der Docker-Welt nicht verleugnen. Begriffe wie "Stack" stammen von dort und sind für Kubernetes eher untypisch. Auch "Applications" findet sich nicht unter den Kubernetes-Ressourcen, wenngleich die Kubernetes-Distribution OpenShift von Red Hat auch "Apps" kennt, die im Wesentlichen das Gleiche sind wie die Applications von Portainer: Eine Sammlung von Ressourcen, typischerweise in einem Namespace, die zu einer containerisierten Anwendung gehören. Neben der Definition der Container und Volumes kann dazu auch die Konfiguration gehören, die Portainer in ConfigMaps speichert. Dann gibt es in Kubernetes noch die Secrets, um beispielsweise TLS-Zertifikate zu speichern. Portainer versammelt beide Arten von Daten unter dem Begriff "Configuration", die es in den Formen "sensitive" (Secrets) und "non-sensitive" (ConfigMaps) gibt.

Die Auswahl, ob als Typ einer "Anwendung" ein Kubernetes-Deployment-Objekt oder ein DaemonSet zum Einsatz kommt, verbirgt sich in Portainer hinter den Begriffen "Replicated" und "Global". Leider gibt es hier keine Hinweise auf den Zusammenhang, den sich der Kubernetes-Anwender selbst zusammenreimen muss. Da Portainer nicht auf Kubernetes spezialisiert ist, sondern auch Docker und den Azure Container Service unterstützt, muss es hier Kompromisse bei der Begrifflichkeit und der Bedienung geben.

Es gibt auch keine Möglichkeit, irgendwelche Objekte in Portainer zu kopieren, was ein Tool, das ein grafisches Arbeiten mit solchen Objekten ermöglichen soll, natürlich wenig komfortabel macht: Wer zwei ähnliche Anwendungen deployen möchte, kann nicht etwa die Konfiguration der einen unter einem anderen Namen neu speichern und dann editieren. In dem Fall muss der Anwender jedes Mal neu anfangen – oder wieder den Weg über die Kommandozeile gehen und dort in ein paar Sekunden eine YAML-Datei kopieren. Hier hat Portainer noch deutlich Luft nach oben.

Vermutlich wird es kaum jemals eine Kubernetes-GUI geben, die alle möglichen Einstellungen der komplexen Software abbildet. Dadurch würde jeder Einstellungsdialog so komplex, dass ein YAML-File demgegenüber vorzuziehen wäre. Am besten eignet sich eine GUI deshalb dafür, Nicht-Admin-Usern in einem vorgegebenen Rahmen die Bereitstellung und Konfiguration ihrer Dienste auf einem Cluster zu erlauben. Der Anwendungsfall für Admins dürfte dagegen darin liegen, sich ohne viel Tippen ein Übersicht über konfigurierte und laufende Kubernetes-Ressourcen zu verschaffen.

Da der Kubernetes-Support noch neu ist, müssen wir den Entwicklern wohl nachsehen, dass es in der GUI noch Verbesserungspotenzial gibt. Gerade die Möglichkeit, Objekte kopieren und bearbeiten zu können, und als letzter Ausweg für Power-User die Möglichkeit, YAML zu editieren, sollten in künftigen Versionen nicht fehlen. Ansonsten wird es spannend sein, ob und wie Portainer die mehr Erfolg versprechende Hinwendung zu Kubernetes weiter ausbauen wird, wenn reine Docker-Deployments weiter an Bedeutung verlieren.