Beim Lesen von Materialien auf Kubernetes sind Sie wahrscheinlich wiederholt auf Beispiele für verschiedene Kubectl-Befehle und knifflige YAML-Konfigurationen gestoßen. Für Leute, die sich mit K8s auskennen, führt dieser Ansatz zweifellos zu keiner Ablehnung. Im Zeitalter der Allgegenwart von Webschnittstellen kann dies jedoch nicht als benutzerfreundlich bezeichnet werden. Es verkompliziert den Lernprozess für Neulinge und wirkt als Barriere für diejenigen, die mit Kubernetes nicht sehr vertraut sind.
Natürlich gibt es verschiedene GUIs für K8s, einschließlich des Kubernetes Dashboards , das Teil des Kubernetes Upstream selbst ist. (Anmerkung Übersetzung: Wir haben bereits über viele der vorhandenen Lösungen in diesem Vergleich gesprochen .) Bei der Prüfung der verschiedenen Optionen konnten wir jedoch keine Lösung finden, die vollständig zu uns passt. Ich wollte die Schnittstelle:
- war 100% Open Source;
- aktiv von der Community unterstützt;
- war universell in dem Sinne, dass es nicht an die Kubernetes-Distribution eines bestimmten Anbieters gebunden war;
- war modular und erweiterbar;
- hatte ein ordentliches und modernes Aussehen;
- wurde auf einem Stapel implementiert, der unseren Entwicklern vertraut ist (Go, JavaScript / TypeScript, React);
- war interaktiv (d. h. sammelte nicht nur Daten, sondern erlaubte auch bestimmte Aktionen mit dem Cluster);
- unterstützter Multi-Cluster-Modus.
Trotz der großen Auswahl erfüllte keine der von uns getesteten Lösungen alle oben aufgeführten Kriterien (oder könnte als gute Grundlage für die Erstellung einer neuen Lösung dienen). Aus alter Tradition haben wir uns daher entschlossen, es selbst zu machen ...
Scheinwerfer vorstellen
Heute bin ich stolz darauf, die breite Verfügbarkeit einer neuen Benutzeroberfläche für Kubernetes namens Headlamp bekannt zu geben .
Headlamp ist eine universelle und erweiterbare Benutzeroberfläche für Kubernetes, die die oben genannten Kriterien erfüllt. Als Idee von Kinvolk ist es natürlich 100% Open Source. Wir hoffen, dass viele Mitglieder der Kubernetes-Community Headlamp nicht nur schätzen, sondern auch zum Projekt beitragen werden.
Lassen Sie uns einen kurzen Blick auf die Hauptmerkmale werfen.
Erweiterbare Benutzeroberfläche
Wir bemühen uns sicherzustellen, dass der Scheinwerfer für möglichst viele Anwendungsfälle geeignet ist. Die Zielgruppe des Projekts sind nicht nur Neulinge bei Kubernetes, sondern auch erfahrene Administratoren und K8-Anbieter mit sehr unterschiedlichen Anforderungen. Oft (insbesondere für UI-Projekte) wird eine solche Vielzahl von Anwendungsfällen implementiert, indem eine große Anzahl von Gabeln erstellt wird, von denen jede von einem eigenen nachgeschalteten Team verwaltet wird. Es ist jedoch schwieriger, die Gabeln auf dem neuesten Stand zu halten, je größer die Änderungen sind.
Das Plugin-System löst dieses Problem. Aus diesem Grund unterstützt Headlamp Out-of-Tree-UI-Plugins. Hierbei handelt es sich um JavaScript-Dateien, die vom Headlamp-Backend geladen und an den Client übergeben werden, der sie dynamisch lädt.
Dieser Ansatz eröffnet große Innovationsmöglichkeiten und trägt zur Entstehung vieler neuer Funktionen bei. Beispielsweise ist es einfach, im Pod-Detailblock eine Schaltfläche zu erstellen, die den Benutzer zu einem Dienst umleitet, der die finanziellen Kosten dieses Pods anzeigt.
Der Headlamp-Plugin-Mechanismus eröffnet der Community großartige Möglichkeiten. Und wir sind bereit, mit allen zusammenzuarbeiten, die an der Entwicklung neuer Plugins für Headlamp teilnehmen und den Mechanismus selbst entwickeln und an neue Anwendungsfälle anpassen möchten.
Traceloop
Um die volle Leistungsfähigkeit des Plugin-Mechanismus (und des Tools selbst) zu demonstrieren, haben wir ein Headlamp-Plugin für das Traceloop-Gadget entwickelt , das Teil des Inspektor Gadget- Projekts ist (eine Reihe von Tools zum Überprüfen und Debuggen von Anwendungen in Kubernetes - ca. Transl.) .
Nach der Installation des Inspektor-Gadgets und der Aktivierung des Traceloop-Gadgets werden alle Systemaufrufe vom Pod in einen Ringpuffer geschrieben. Dieser Puffer kann in Echtzeit angezeigt werden, während der Pod ausgeführt wird. Mit anderen Worten, traceloop gibt Ihnen einen Einblick in das, was der Pod gerade tut. Außerdem werden die Daten im Puffer für Pods gespeichert, die beendet wurden. Auf diese Weise können Sie die Ursache des Fehlers nach dessen Auftreten ermitteln - eine Art "Black Box" für Kubernetes-Anwendungen.
Selektive Benutzeroberfläche
Das Problem bei vielen CRUD-Benutzeroberflächen besteht darin, dass sie nichts über die interne Organisation der Zugriffskontrolle wissen. Beispielsweise ist das Vorhandensein von Schaltflächen zum Bearbeiten / Löschen für den Benutzer verwirrend, wenn er nicht über die Berechtigung zum Ändern der Ressource verfügt. Der Scheinwerfer überprüft die RBAC Kubernetes-Einstellungen und zeigt nur die Steuerelemente für die Aktionen an, die dem Benutzer zur Verfügung stehen. Wenn der Benutzer beispielsweise nicht das Recht hat, die Ressource zu bearbeiten, wird die Schaltfläche "Bearbeiten" nicht angezeigt.
All dies wirkt sich äußerst positiv auf die Benutzererfahrung aus: Schließlich sieht der Bediener unter Berücksichtigung der aktuellen Rechte sofort, welche Aktionen ihm zur Verfügung stehen. Dies ist ideal für Situationen, in denen zeitlich begrenzte Berechtigungen erteilt werden (z. B. vorübergehende Berechtigung zum Löschen einer Ressource).
Verfügbare Schaltflächen für Aktionen mit dem Pod, wenn der Benutzer über Bearbeitungs- / Löschrechte verfügt
Verfügbare Schaltflächen, wenn der Benutzer keine Bearbeitungs- / Löschrechte hat
Design / Benutzeroberfläche
Wir wollten das Scheinwerferdesign so lakonisch und modern wie möglich gestalten und dabei den "traditionellen" Kubernetes UI- oder Dashboard-Stil beibehalten. Wir sind beispielsweise davon überzeugt, dass die vertraute tabellarische Ansicht sich hervorragend für die Arbeit eignet, und wir hoffen, dass andere Arten der Visualisierung (z. B. die Darstellung eines Clusters in Form von Diagrammen) mithilfe von Plugins implementiert werden können.
Das Frontend ist in React mit der Material UI- Bibliothek implementiert (es ist modern, ordentlich und wird von einer großen Benutzergemeinschaft unterstützt). Außerdem ist es im technologischen Stack unseres anderen Projekts enthalten - Nebraska (Update Manager für Flatcar Container Linux - ca. übersetzt).Dies ermöglicht es uns, Erfahrungen und Ressourcen auszutauschen und eine einheitliche Benutzeroberfläche für alle Produkte sicherzustellen.
Lokal oder in einem Cluster
Die meisten Kubernetes-Benutzeroberflächen lassen sich in zwei Gruppen einteilen: Remote (das Backend befindet sich häufig in einem Cluster) wie Kubernetes Dashboard oder Local (die Anwendung ist auf dem Computer installiert) wie Octant von VMware.
Jeder dieser Ansätze hat Vor- und Nachteile. Im Fall einer Remoteanwendung ist es beispielsweise sehr einfach, die URL für andere Benutzer freizugeben und deren Anmeldung über OIDC zu implementieren. Es ist „überall“ verfügbar und leicht auf dem neuesten Stand zu halten. Im Gegenteil, bei der Desktop-Version müssen Sie nicht über die Platzierung der Benutzeroberfläche nachdenken. Dieser Ansatz bietet eine bessere Isolation, aber es liegt in der Verantwortung des Benutzers, die Anwendung auf dem neuesten Stand zu halten.
Mit Headlamp müssen Sie nicht mehr zwischen diesen beiden Ansätzen wählen: Beide werden unterstützt. Headlamp kann einfach mithilfe unserer YAML-Dateien geclustert (und angepasst) oder lokal auf einem Linux-, MacOS- oder Windows-Computer installiert werden.
Multi-Cluster-Modus
Die meisten Kubernetes-Bereitstellungen bestehen aus mehreren Clustern (schon allein zur Trennung von Entwicklungs- und Produktumgebungen). Headlamp bietet Zugriff auf alle diese Cluster: Die spezifische Methode hängt davon ab, ob Sie sie lokal oder remote ausführen.
Bei lokaler Ausführung liest Headlamp die kubeconfig und zeigt die dort verfügbaren Kontexte an, sodass der Benutzer sie bei Bedarf ändern kann, indem er einfach die lokale Umgebungsvariable auf den entsprechenden Cluster setzt.
Der Multi-Cluster-Modus ist sehr einfach: Für jeden konfigurierten Cluster wird ein Proxy erstellt, und Anforderungen von der Benutzeroberfläche (mit Aufrufen der Kubernetes-API) werden an die Adresse des gewünschten Clusters umgeleitet. Das K8dash- Projekt sollte hier erwähnt werden, Module zum Verwalten von Anforderungen / APIs, die wir bei der Entwicklung von Headlamp verwendet haben.
Dieser Ansatz kann auch mit der Ausführung im Cluster kombiniert werden. Zu diesem Zweck erfordert der Cluster, in dem die Anwendung ausgeführt wird, den API-Zugriff auf andere angegebene Cluster.
Lokomotive Kubernetes Verbindung
Wie Sie wahrscheinlich wissen, haben wir auch unsere eigene Kubernetes-Distribution - Lokomotive . Wir verwenden Headlamp bei Lokomotive für den vorgesehenen Zweck, möchten jedoch betonen, dass es sich um unabhängige und unabhängige Projekte handelt. Wir werden Headlamp nicht an einen K8-Dienstleister binden und entwickeln es so, dass es auf jedem typischen Kubernetes-Cluster funktioniert.
Probieren Sie Headlamp in Ihrem Cluster aus!
Dies ist sehr einfach: Stellen Sie die Bereitstellung in Ihrem Cluster bereit und rufen Sie die entsprechende Adresse im Browser auf oder laden Sie die Desktop-Version für Windows, MacOS oder Linux herunter und installieren Sie sie. Details finden Sie in der Dokumentation .
Headlamp ist ein vollständig Open Source-Tool, das unter der Apache 2.0-Lizenz veröffentlicht wurde. Wie oben erwähnt, haben wir es unabhängig von Kubernetes-Dienstanbietern und vielseitig einsetzbar gemacht (was eine große Anzahl von Anwendungsfällen abdeckt). Heute laden wir alle ein, sich an der Entwicklung des Projekts zu beteiligen! Lesen Sie dazu bitte die entsprechenden Richtlinien .
Wir wünschen Ihnen viel Spaß mit Headlamp!
PS vom Übersetzer
Lesen Sie auch in unserem Blog: