Auf HN vorgestellt: Glasskube – Open-Source-Paketmanager für Kubernetes als Helm-Alternative

 (github.com/glasskube)
3 Punkte von GN⁺ 2024-06-27 | 1 Kommentare | Auf WhatsApp teilen
  • Glasskube ist ein Open-Source-Paketmanager für Kubernetes und wird als Lösung vorgestellt, die Deployment, Updates und Konfiguration 20-mal schneller macht als Tools wie Helm oder Kustomize
  • Nutzer können Pakete über die Glasskube-UI, die CLI oder per GitOps bereitstellen; inspiriert wurde das Projekt von der Einfachheit von Homebrew und npm
  • Zu den wichtigsten Funktionen gehören die Paketinstallation direkt in der UI ohne Suche nach Helm-Repositories, typsichere Konfigurationseingaben, Werte-Injektion zwischen Paketen, abhängigkeitssensitive Installationen und vorab getestete sichere Updates
  • Alle Glasskube-Pakete werden als Custom Resources verwaltet und können per GitOps betrieben werden; außerdem werden mehrere Repositories und private Packages unterstützt
  • Aktuell werden unter anderem Kubernetes Dashboard, cert-manager, Ingress-NGINX Controller, Kube Prometheus Stack und Cloud Native PG unterstützt; die Beta-Version kann per Homebrew installiert werden

Das Kubernetes-Paketmanagement-Problem, das Glasskube lösen will

  • Glasskube ist ein Open-Source-Paketmanager für Kubernetes
  • Das Deployment, Aktualisieren und Konfigurieren von Paketen in Kubernetes soll damit 20-mal schneller sein als mit Tools wie Helm oder Kustomize
  • Inspiriert von der Einfachheit von Homebrew und npm können Nutzer eine der folgenden Methoden wählen
    • Glasskube-UI
    • Glasskube-CLI
    • direkte Paketbereitstellung über GitOps
  • Der Hintergrund der Entwicklung ist die Erfahrung aus mehr als fünf Jahren Arbeit im Kubernetes-Ökosystem, in denen Paketmanagement, Konfiguration und Deployment immer wieder Schwierigkeiten bereiteten
  • In bisherigen Arbeitsabläufen ging viel Zeit dafür drauf, Templates zu erstellen und Dokumentation zu schreiben, um schwer verständliche Befehle und Konzepte zu erklären
  • Tools wie Homebrew, apt und dnf waren im Vergleich einfach zu verwenden und verursachten weniger Probleme – das diente als Referenz bei der Entwicklung von Glasskube

Installations- und Konfigurationsablauf

  • Die Beta-Version kann über Homebrew installiert werden
brew install glasskube/tap/glasskube
  • Weitere Installationsoptionen finden sich im Installation Guide
  • Nach der Installation der CLI wird zum Einrichten der benötigten Komponenten im Cluster folgender Befehl ausgeführt
glasskube bootstrap
  • Nach Abschluss des Cluster-Bootstrappings kann die UI des Paketmanagers gestartet werden
glasskube serve
  • Dieser Befehl öffnet http://localhost:8580 im Standardbrowser; dort können Nutzer verfügbare Pakete durchsuchen und installieren

Funktionen für UI, Konfiguration und Abhängigkeitsverwaltung

  • Die Glasskube-UI stellt alle Pakete zentral an einem Ort bereit, sodass Nutzer Pakete im Cluster installieren können, ohne separat nach Helm-Repositories suchen zu müssen
  • Die Paketkonfiguration kann in der UI oder über einen interaktiven CLI-Fragebogen mit typsicheren Eingabewerten eingerichtet werden
    • Werte aus anderen Paketen, ConfigMaps und Secrets lassen sich einfach injizieren
    • Damit wird eine Alternative zu nicht typisierten und undokumentierten values.yaml-Dateien vorgeschlagen
  • Die Abhängigkeitsverwaltung sorgt dafür, dass Glasskube-Pakete von mehreren anderen Paketen verwendet und referenziert werden können
    • Abhängige Pakete werden im richtigen Namespace installiert
    • Das README beschreibt dies sinngemäß als etwas, „wie ein Umbrella Chart von Anfang an hätte funktionieren sollen“

Updates, GitOps und Repository-Unterstützung

  • Paket-Updates können vorab als Pending Update für eine gewünschte Version eingesehen und dann mit einem Klick oder per CLI-Befehl ausgeführt werden
  • Alle Updates werden vorab mit der Glasskube-Testsuite getestet
  • Feedback und Kommentare zu Paketen können in den GitHub Discussions oder direkt in der Glasskube-UI hinterlassen werden
  • Die GitOps-Integration basiert darauf, dass alle Glasskube-Pakete als Custom Resources verwaltet werden
  • Eine Renovate-Integration ist in Arbeit; das zugehörige Issue findet sich unter renovatebot/renovate#29322
  • Mehrere Repositories und private Packages können verwendet werden
    • Damit lassen sich interne Service-Pakete eines Unternehmens bereitstellen
    • Vorgestellt wird ein Szenario, in dem Entwickler interne Services einfach in aktuellem Zustand aufsetzen können

Architektur der Paketinstallation

  • Der Ablauf von glasskube install [package] ist so aufgebaut, dass UI oder CLI über den Client sowohl das Paket-Repository als auch die Kubernetes API nutzen
  • Die UI verbindet sich über den lokalen Server http://localhost:8580 mit dem Client
  • Die CLI verbindet sich über die cobra CLI mit dem Client
  • Der Client prüft zunächst das Package Repo, um das Paket zu validieren
  • Nach der Validierung wird eine Package-Custom-Resource in der Kubernetes API erzeugt
  • Im Cluster übernehmen PackageController und PackageInfoController das Reconcile
    • PackageController reconcilet Package und erstellt bei Bedarf PackageInfo
    • PackageInfoController aktualisiert das Paket-Manifest aus dem Paket-Repository
    • Das aktualisierte Manifest wird in PackageInfo übernommen
    • Anschließend deployt PackageController das Paket in Kubernetes
  • Kubernetes gibt den Paketstatus an den Client zurück

Unterstützte Pakete und Projektinformationen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-27
Meinungen auf Hacker News

  • Das könnte ein Schritt in die richtige Richtung sein, aber das größte Problem beim Kubernetes-Paketmanagement scheint derzeit schwer mit einem Paketmanager lösbar zu sein.
    Im Alltag ist am mühsamsten, dass verschachteltes YAML über mehrere Ebenen gestapelt wird und das Ergebnis unvorhersehbar ist.
    Zum Beispiel erstellt ein ArgoCD ApplicationSet mehrere Applications, diese Applications rendern Helm-Charts, und in diesen Charts stecken CRDs, die von beliebigen Operatoren wie Strimzi, Grafana oder Vector verwendet werden.
    YAML hat eine schwache Syntax und es gibt keinen Standard für Template-Rendering, sodass es nahezu unmöglich ist zu wissen, welches YAML nach einer Änderung auf oberster Ebene tatsächlich in die Kubernetes API eingespeist wird.
    Am Ende führt das jeden Monat zu Trial-and-Error, teuren Blue-Green-Deployments und Hunderten Minuten Debugging.

    • Die breite Einführung von YAML in Tools rund um DevOps war ein Fehler.
      Ich denke, Unterstützung durch eine richtige Programmiersprache ist die Richtung.
      Idealerweise bräuchte es ein statisches Typsystem, das nicht Turing-vollständig ist und Terminierung garantiert; etwas wie Starlark mit Typen scheint passend.
    • Ich frage mich, ob du das Rendered-Manifests-Pattern ausprobiert hast: https://akuity.io/blog/the-rendered-manifests-pattern/
    • Das ist das Problem, auf das sich Glasskube Cloud(https://glasskube.cloud/) konzentrieren will.
      glasskube[bot] soll in GitOps-Pull-Requests einen Kommentar mit dem exakten Diff der Ressourcen posten, die sich in allen verbundenen Clustern tatsächlich ändern würden.
      Dieses Diff wird von einem Controller erstellt, der im Cluster läuft.
      Man kann es sich wie eine codecov-Analyse vorstellen, nur speziell für Ressourcenänderungen.
    • Die Lösung ist, Kubernetes nicht zu verwenden.

  • Das wirkt wie ein interessanter Ansatz für Paketmanagement und scheint für Dinge wie einen Homebrew-artigen Cluster geeignet zu sein.
    Trotzdem bevorzuge ich persönlich, schon um Konsistenz im Repository zu wahren, die Kombination aus helmfile + Renovate + Pipeline.
    Ein Button wie update all fühlt sich zum Beispiel bei einem relevanten Cluster ziemlich beängstigend an.
    Für persönliche Projekte ist es trotzdem ein cooles Tool.
    Der Package Controller erinnert stark an Tillers frühere Rolle in Helm; das war in vielen Unternehmen ein großes Sicherheitsproblem und wurde in Helm 3 entfernt und durch clientseitige Verarbeitung auf ConfigMap-Basis ersetzt. Ich frage mich, wie dieses Projekt dieses Problem umgehen wird.

    • Glasskube-Pakete können in ein GitOps-Repository gelegt werden, weil jedes Paket eine CR(custom resource) ist.
      Man kann sie auch über die CLI mit den Flags --dry-run und --output yaml konfigurieren und dann in Git einchecken.
      Außerdem arbeiten wir an Pull Requests, die Paket-Updates per Renovate unterstützen: https://github.com/renovatebot/renovate/issues/29322
      Helm 3 ist inzwischen ein clientseitiges Tool und kann daher selbst kein RBAC erzwingen.
      OLM hat Operator Groups(https://olm.operatorframework.io/docs/advanced-tasks/operato...) eingeführt, um Berechtigungen auf Operator-Ebene bereitzustellen.
      Etwas Ähnliches ließe sich auch für Glasskube-Pakete einführen; Glasskube selbst wird zwar weiterhin recht weitreichende Berechtigungen benötigen, aber man kann den Paket-Scope einschränken und feingranulare Berechtigungen einbauen.

  • Traditionell sind Anwendungspakete versionierte, unveränderliche Binärdateien mit Schritten vor und nach der Installation; sie werden für eine bestimmte Plattform und bestimmte Abhängigkeiten gebaut, und die Konfigurationsmöglichkeiten bei der Installation sind äußerst begrenzt.
    Der Grund, warum Pakete gut funktionieren, ist, dass sie für sehr konkrete Umgebungen entworfen sind und die Teile, die sich bei der Installation ändern lassen, auf ein Minimum reduziert werden.
    Trotzdem erfordern Betriebssystempakete selbst innerhalb dieser engen Bedingungen weiterhin enorme Mengen an Tests, Entwicklung und Patches.
    Dass sich ein Paket, das man heute installiert, einfach anfühlt, kann daran liegen, dass Hunderte Stunden in die aktuelle Plattform, die aktuellen Komponenten und Versionen geflossen sind.
    Ein Kubernetes-„Paket“ ist in Wirklichkeit kein Paket, sondern eher ein Bündel von Anweisungen für Komponenten, die installiert und konfiguriert werden sollen, und enthält oft mehrere separate Anwendungspakete.
    Dieser Unterschied zeigt sich in zweierlei Hinsicht: K8s-„Pakete“ sind sehr lose definiert und damit stark variabel, und alle möglichen Leute erstellen sie auf alle möglichen Arten, wobei sie alle möglichen Annahmen über den Zustand des Zielsystems treffen.
    Damit ein Kubernetes-„Paket“ funktioniert, müssen mehrere Ebenen von Abhängigkeiten und Konfiguration zusammenpassen.
    K8s-API-Version, Installation und Ausführung der K8s-Komponenten, ACLs, das Nichtvorhandensein kollidierender bestehender Komponenten, festgelegte Versionen der vom Paket installierten Komponenten und Container sowie deren Kompatibilität mit anderen Dingen im Cluster und schließlich die Benutzereinstellungen müssen alle stimmen.
    Upgrades sind ähnlich chaotisch, weil es kein Konzept stabiler Release-Trees oder Rolling Releases gibt; es ist vergleichbar damit, beliebige .deb-, .rpm- oder .dmg-Dateien auf einem Betriebssystem zu installieren und auf das Beste zu hoffen.
    Heute gibt es nichts, das all das übernimmt.
    Um Kubernetes-Packaging so reibungslos zu machen wie plattformspezifisches Binär-Packaging, bräuchte es eine ganze Maintainer-Community und entweder einen Rolling-Release-Ansatz wie bei Homebrew oder stabile Versions-Release-Branches.
    Letztlich müsste ein Projekt wie ArtifactHub oder Homebrew alle Pakete auf eine einheitliche Weise verwalten, aber das ist ein großer Aufwand und wirkt überhaupt nicht profitabel.

    • Glasskube hat ebenfalls mit einem Ansatz begonnen, bei dem Pakete ähnlich wie bei Homebrew im „core“-Glasskube-Paket-Repository (https://github.com/glasskube/packages) liegen.
      Die Struktur zielt darauf ab, alle Updates zentral zu speichern und über CI/CD-Workflows zu testen, damit Nutzer getestete, reibungslose Upgrades bekommen.
      Nutzer können zwar eigene Repositories und Pakete hosten, aber standardmäßig wollen wir selbst eine meinungsstarke Paketauswahl bereitstellen.
      Auch Builds für unterschiedliche Kubernetes-Versionen oder Umgebungen sind bereits bedacht und werden irgendwann nötig werden, wenn mehr Konfiguration in die Build-Phase einfließen soll.

  • Ich bin nicht sicher, ob ein K8s-Paketmanager so einfach werden kann wie brew oder apt.
    Ein wichtiger Punkt ist insbesondere, dass die Werte je nach Zielumgebung unterschiedlich sind und fast alle Nutzer ihre jeweils eigene „Snowflake“-Umgebung haben.
    REPL-artige Prompts oder eine Web-UI zum Setzen solcher Werte sprechen mich nicht an.
    Der eigentliche Schmerz ist weiterhin ungelöst: Helm-Charts zu schreiben ist mühsam, umgebungsspezifische Werte müssen verwaltet werden, und ich würde mir wünschen, dass Werte nicht zwischen Charts verbunden werden müssen.

    • In der Praxis gibt es sehr viele Snowflake-Cluster, und auch auf einer Cloud-Native-Konferenz, die ich kürzlich besucht habe, war das ein heißes Thema.
      Plattformteams bauen interne Entwicklerplattformen, um Kubernetes-Konfigurationen über Teams und Cluster hinweg stärker zu standardisieren und Entwicklern nur kleine Anpassungen zu erlauben.
      Meiner Erfahrung nach sollte man diese individuellen Konfigurationen reduzieren, und genau das ist auch einer der Gründe, warum Glasskube entstanden ist.
      Dass das Schreiben von Helm-Charts mühsam ist, dem stimme ich zu 100 % zu, und wir wollen das künftig ändern.
      Glasskube-Pakete bleiben konfigurierbar, bieten aber sinnvolle Defaults.
      Konfigurationswerte anderer Pakete lassen sich in Glasskube leicht referenzieren, sodass dieselben Werte nicht mehrfach angegeben werden müssen.

  • Ich erstelle viele Kubernetes-Operatoren und habe häufig mit Helm- und OLM-Problemen zu tun.
    In der Dokumentation steht: „CRD-Upgrades werden von Glasskube behandelt, damit CRs und Operatoren nicht auseinanderlaufen“, aber wenn ich in der Doku nach „CRD“ suche, finde ich keine konkreten Ergebnisse.
    Das ist einer der größten Schmerzen, die ich derzeit mit Helm habe, daher würde mich interessieren, ob ihr eure Pläne dazu teilen könnt.
    [1] <https://stackable.tech/en/>
    [2] <https://www.youtube.com/watch?v=Q8OSYOgBdCc>

    • Pakete im öffentlichen Glasskube-Repository sind so konfiguriert, dass CRD-Änderungen angewendet werden.
      Das wird über Manifeste oder den helm-controller abgewickelt.
      Die Dokumentation werden wir aktualisieren.

  • Ich denke, Kubernetes ist durch sein übermäßig simples Operator-Modell grundlegend eingeschränkt.
    Die Grundidee gefällt mir, aber das gesamte Modell auf „aktueller Zustand, gewünschter Zustand, nächste Aktion“ zu reduzieren, ist praktisch unmöglich.
    Am Ende wandert der gesamte Workflow in die Logik für die nächste Aktion, und weil zu viele Operatoren denselben Systemzustand betrachten, ist schwer abzusehen, wie mehrere Komponenten miteinander interagieren werden.
    Helms Problem ist ein Teilfall dieses größeren Problems.
    Als Analogie: Es ist dasselbe Problem, das Frontend-Programmierung mit dem DOM hat.
    Die Einführung eines Virtual-DOM-/Reducer-Paradigmas wie bei React würde erheblich dabei helfen, solche Probleme zu lösen.

    • „Aktueller Zustand, gewünschter Zustand, nächste Aktion“ ist im Grunde die Art, wie allgemeine Regelungstechnik funktioniert.
      Es gibt einen Zustand, ein Ziel und Störungen auf dem Weg zum Ziel; wenn man ein mächtiges und flexibles Werkzeug will, halte ich diese Abstraktionsebene für richtig.
      Das Problem ist, dass die physischen Eigenschaften und die Anordnung der Maschine einen so großen Unterschied machen, dass es viel zu teuer ist, sie sinnvoll zu virtualisieren oder zu simulieren.
      Deshalb verifiziert man stattdessen, ob der Konfigurationszustand auf einer Teilmenge der physischen Struktur funktioniert.
      Das entspricht dem Einsatz von dev-, staging- und prod-Umgebungen sowie Blue-Green-Deployments, Canary-Analysen, teilweisen Rollouts und Ähnlichem.

  • Wenn man ein solches Tool braucht, um K8s zu verwenden, ist man wahrscheinlich mit einer anderen Lösung besser bedient.
    Kubernetes wurde nicht dafür gebaut, ohne Vorwissen genutzt zu werden, und es ist schwierig.
    Solange man keine vollständige PaaS baut, kommt man dieser Komplexität nur schwer aus dem Weg.

  • Ich glaube, dieses Tool ist marketingseitig falsch positioniert
    Das hat nicht viel mit Helm zu tun
    Für mich ist Helm in erster Linie kein Paketmanager, sondern eine Template-Sprache und eine Art, über kubeapps, die Helm CLI und ArgoCD Dinge in K8s-Clustern zu konfigurieren und zu installieren
    Dieser Ansatz bricht auch mit einem hervorragenden IaC-Paradigma
    Denn nach dem Bootstrap von ArgoCD ist eine Struktur gut, die nur noch auf ein Git-Repository verweist
    Die Demo zeigt nicht, wie man Template-Funktionen wie form-Unterstützung nutzt, sondern nur alles andere
    Ich habe weiterhin das Gefühl, dass mit Helm etwas nicht stimmt, daher gefällt mir dieses Tool an sich ehrlich gesagt, aber mit dem aktuellen Ansatz wird es meiner Meinung nach scheitern
    Große Unternehmen brauchen dieses Tool nicht, daher wird es schwierig, genügend Adoption zu erreichen
    Kubeapps und Helm funktionieren gut, und selbst wenn man Helm ersetzen will, wird die Helm-Unterstützung vermutlich noch lange erhalten bleiben
    Das Problem bei Helm ist, dass Charts mit zunehmender Größe komplex werden
    Eine Struktur, bei der praktisch alles in einem einzigen templates-Ordner liegt, ist ein Durcheinander, YAML eignet sich nicht gut für Templates, und values.yaml wird übermäßig groß

    • Die Demo ist stärker auf Endnutzer ausgerichtet
      Weitere Details zu den Konfigurationsoptionen finden sich in der Dokumentation zur Paketkonfiguration: https://glasskube.dev/docs/design/package-config/
    • Ich will nicht arrogant oder herablassend klingen, aber wenn du denkst, dass Helm hauptsächlich kein Paketmanager ist, hast du wahrscheinlich noch nicht viel mit auf K8s ausgerollter Infrastruktur gearbeitet

  • Das Verkaufsargument, schneller als Helm zu sein, spricht mich nicht besonders an
    Ich hatte nie das Gefühl, dass Geschwindigkeit das Problem von Helm ist

  • Sieht interessant aus
    Eine kurze Erklärung, wie es mit bestehenden Tools wie ArgoCD zusammenspielt oder sich davon unterscheidet, würde beim Verständnis helfen
    Ich habe das Video gesehen, und eines der installierten Tools war Argo, also besetzt es offensichtlich eine andere Nische, aber ich bin mir noch nicht sicher, welche das ist

    • ArgoCD ist ein hervorragendes Tool, um den Zustand eines GitOps-Repositorys mit dem Cluster zu synchronisieren, installierte Ressourcen zu visualisieren und potenzielle Fehler anzuzeigen
      Es wird häufig genutzt, damit Entwickler den Zustand der zentralen Unternehmensanwendungen einsehen können, ohne Cluster-Zugriff zu haben
      Glasskube konzentriert sich auf die Pakete, von denen die zentralen Anwendungen abhängen
      Es verwaltet den Lebenszyklus von Infrastrukturkomponenten, testet Updates und stellt Upgrade-Pfade bereit
      Man kann Glasskube-Pakete auch in ein GitOps-Repository legen und sie mit ArgoCD in den Cluster synchronisieren; den Rest übernimmt der PackageController