Kubernetes Deployment Tools – Wo stehen wir heute?

Stelle dir vor, dein Unternehmen hat sich für eine Microservice-Architektur entschieden. Während du immer mehr Microservices entwickelst und bereitstellst, beschließt du, diese mithilfe von Kubernetes zu orchestrieren. Du beginnst mit dem Schreiben von YAML-Manifesten und zusätzlichen Konfigurationen und stellst die erforderlichen Tools in deinem Cluster bereit. Irgendwann wechselst du aus Gründen der Konfigurierbarkeit zu Kustomize oder Helm.
Vielleicht verwendest du schließlich ArgoCD oder Flux für einen GitOps-Ansatz. Irgendwann reichen Kustomize und Helm nicht mehr aus – zu viel YAML, zu wenig Überblick über das, was man eigentlich tut. Du ertappst dich dabei, wie du Kubernetes Deployment Tools recherchierst und vergleichst.

Unabhängig davon, ob du dir dieses Szenario in deinem Kopf ausmalen musstest oder es selbst erlebt hast (oder es gerade erlebst) – es ist kein schöner Zustand. Helm und Kustomize sind zuverlässige, gut etablierte Tools, die tief in das Kubernetes-Ökosystem integriert sind. Dennoch mangelt es ihnen an Benutzerfreundlichkeit und Ergonomie, und sie bieten keine wirklich tolle Entwicklererfahrung – es ist Zeit für einen Nachfolger!
Da du und ich nicht die Einzigen sind, denen es so geht, gibt es heute eine Handvoll Tools, die alle versuchen, verschiedene Probleme bei der Anwendungsbereitstellung unter Kubernetes zu lösen, und ich werde diese Kubernetes Deployment Tools für dich vergleichen.
Schauen wir sie uns an: Timoni, kapp und Glasskube.

Timoni – Distribution und Lifecycle-Management für Cloud-Native Anwendungen

Timoni verspricht, die CUE-Funktionen für Typsicherheit, Codegenerierung und Datenvalidierung in Kubernetes einzubringen, um die Erstellung komplexer Deployments zu einem angenehmen Erlebnis zu machen – das klingt doch gut! Aber was ist CUE?
CUE ist eine Open-Source-Datenvalidierungssprache, die ihre Wurzeln in der Logikprogrammierung hat. Als solche ist sie an der Schnittstelle zwischen Zustandsbeschreibung, Zustandsableitung und Zustandsvalidierung angesiedelt – klingt nach einer perfekten Lösung für ein Deployment-Tool, aber wie funktioniert sie?

Timoni baut auf vier Konzepten auf – Modulen, Instanzen, Bundles und Artefakten, jedes mit seinen eigenen Implikationen und zugehörigen Aktionen in der Timoni CLI:

• Timoni-Module sind eine Sammlung von CUE-Definitionen und -Einschränkungen, die ein CUE-Modul einer meinungsbildenden Struktur bilden.
  Diese Module akzeptieren eine Reihe von definierten Eingabewerten von einem Benutzer und generieren eine Reihe von Kubernetes-Manifesten als Ausgabe, die von Timoni in Ihren Kubernetes-Cluster(n) bereitgestellt wird.
  Timoni-Module können als Äquivalent zu z.B. Helm Charts betrachtet werden.
• Timoni-Instanzen sind bestehende Installationen von Timoni-Modulen innerhalb deines Clusters bzw. deinem Cluster.
  Mit Timoni kann ein und dasselbe Modul mehrfach in einem Cluster installiert werden, wobei jede Instanz ihren eigenen Satz an bereitgestellten Werten hat.
  Timoni-Instanzen können als Äquivalent zu Helm-Releases betrachtet werden.
• Timoni Bundles erlauben es den Autoren, sowohl Modulreferenzen als auch Instanzwerte innerhalb desselben Artefakts auszuliefern und einzusetzen.
  Auf diese Weise können Anwendungen zusammen mit ihrer benötigten Infrastruktur ausgeliefert werden.
  Timoni Bundles können als Äquivalent zu Umbrella Charts in Helm betrachtet werden.
• Timoni-Artefakte sind der vorgesehene Weg, um Module und Bundles zu verteilen.
  Timoni kommt mit seinen eigenen OCI-Mediatypes und setzt zusätzliche Metadaten aus Git-Metadaten, um reproduzierbare Builds zu ermöglichen.
  Auf diese Weise können Module und Bundles signiert und miteinander verglichen werden und sicher verteilt werden.

Das Fazit

Beim Vergleich von Timoni mit bestehenden Kubernetes-Deployment-Tools wie Helm oder Kustomize lassen sich einige Vorteile herausstellen:

1. Geschwindigkeit: Timoni nutzt Kubernetes‘ server-side apply in Kombination mit der Drift-Erkennung von Flux und patcht nur die Manifeste, die sich zwischen den Upgrades geändert haben.
2. Ausführlichkeit: Timoni kann dir genau sagen, was es ändern wird, bis hin zu den Kubernetes-Ressourcen und ihren Eigenschaften.
3. Validierung: Da Module eine Sammlung von CUE-Definitionen und -Einschränkungen sind, kann Timoni korrekte Datentypen oder sogar Werte (z. B. Enums) für Deployments erzwingen.
4. Sicherheit und Verteilung: Während Helmcharts seit letztem Jahr als OCI-Artefakte verteilt werden können, mangelt es ihnen noch immer an Reproduzierbarkeit in einigen Bereichen.Kustomize bietet keinerlei Verteilungsmechanismen an.
   Timoni hat an diese Dinge von Anfang an gedacht und bietet eine schlanke, unterstützte und sichere Art der Verteilung.

Insgesamt könnte Timoni eine gute Wahl für dich sein, wenn du Geschwindigkeit, Sicherheit und Korrektheit indeinen Kubernetes-Bereitstellungstools suchst. Timoni kann große und komplexe Anwendungen bereitstellen, die aus vielen Manifesten bestehen, und gleichzeitig Konfigurationseinschränkungen für die Betreiber mit CUE definieren.
Die Kehrseite der Medaille ist, dass CUElang selbst eine Lernkurve aufweist und nicht agnostisch „GitOps-ready“ ist: Während es eine dokumentierte Möglichkeit gibt, Timoni mit Flux zu verwenden, gibt es keine Entsprechung für z.B. ArgoCD. Dies wird sich wahrscheinlich ändern, sobald Timonis API ausgereift ist.

Werfen wir als nächstes einen Blick auf kapp und sehen wir uns an, wie es Kubernetes Deployments vereinfachen kann!

kapp – Übernehme die Kontrolle über deine Kubernetes-Ressourcen

kapp ist Teil von Carvel, einer Reihe von zuverlässigen, kompatiblen Einzweck-Tools, die Sie bei der Erstellung, Konfiguration und Bereitstellung von Anwendungen für Kubernetes unterstützen. Laut der Website ist es leichtgewichtig, explizit und dependency-aware. Schauen wir uns das mal an:

• leichtgewichtig: kapp ist eine clientseitige CLI, die nicht auf serverseitige Komponenten angewiesen ist und daher z.B. in Umgebungen mit eingeschränktem RBAC funktionieren kann.
• explizit: kapp berechnet die Erstellung, Löschung und Aktualisierung von Ressourcen im Voraus und meldet sie dem Benutzer. Es liegt an ihm, diese Aktionen zu bestätigen.
  kapp loggt auch den Deploymentvorgang während der Installation in großem Detail.
• dependency-aware: kapp ordnet die Ressourcen, die es installieren soll. Das bedeutet, dass z.B. Namespaces oder CRDs vor anderen Ressourcen angewendet werden, die möglicherweise von ihnen abhängen.
  Es ist möglich, benutzerdefinierte Abhängigkeiten hinzuzufügen, z.B. um Housekeeping-Jobs vor oder nach einem Anwendungs-Upgrade auszuführen.

Ähnlich wie Timoni legt  kapp sehr ausführlich dar, was es in deinem Namen tun wird, und führt dich durch den Prozess der Bereitstellung deiner Anwendung(en):

Im Gegensatz zu Timoni musst du nicht unbedingt selbst eine maßgeschneiderte Anwendungskonfiguration schreiben – kapp kann auf bestehenden Lösungen wie Kustomize, Helm oder ytt, einem weiteren Carvel-Tool zum Templaten und Patchen von YAML, aufbauen. Siehe das folgende Beispiel mit der podinfo Helmchart:

Nach der Bereitstellung kann kapp Einblicke in Ihre Kubernetes-Bereitstellungen geben: Vom Reconciliation-Status über verknüpfte ServiceAccounts oder ConfigMaps bis hin zu den Labels Ihrer Anwendungen – kapp hat alles im Griff.

Wenn du dir mehr Gedanken über Day-2-Betrieb und Automatisierung machst, hat kapp ein weiteres Ass im Ärmel: kapp-controller. Kombiniere diese beiden Carvel-Tools und du erhältst eine GitOps-fähige, vollständig automatisierte Lösung für Kubernetes Deployments. kapp-controller führt eine Reihe von CRDs ein, um Apps zu verwalten und/oder sie als Pakete, PackageRepositories und PackageInstallations zu verteilen. Diese CRDs können wiederum z.B. von deiner GitOps-Lösung deployed werden.

Das Fazit

Diese Funktionen machen kapp zu einer soliden Wahl, wenn du beim Vergleich von Kubernetes Deployment Tools nach einer oder mehreren der folgenden Stärken suchst:

• Korrektheit: kapp listet alle anstehenden Änderungen an deinen Anwendungs-Deployments auf, sei es Erstellung, Löschung oder Patch, und bittet standardmäßig um eine Bestätigung.
  kapp hält dich außerdem während des gesamten Deployments auf dem Laufenden und zeigt den Status Deines Deployments jederzeit an.
• Einfache Einführung: Mit kapp musst du keine bestehenden Deployment-Konfigurationen umschreiben, weder Manifeste noch Helmcharts oder Kustomize-Strukturen.
  Füge kapp einfach zu deiner Deployment-Pipeline hinzu und nutze den Mehrwert, den es bietet.
• GitOps-fähig: Mit kapp-controller in Kombination mit kapp kannst du deklarative CRDs verwenden, um deine Anwendungsbereitstellung zu verwalten.
  Darüber hinaus hast du die Möglichkeit, verschiedene Versionen von Bereitstellungen als Pakete zu verwalten.

Wir haben uns bisher bereits zwei Kubernetes Deployment Tools angesehen, aber du weißt ja, was man sagt: „Aller guten Dinge sind drei!“
Werfen wir also einen Blick auf das letzte Tool für heute – Glasskube.

Glasskube – der Paketmanager der nächsten Generation für Kubernetes

Die nächste Generation von Paketmanager für Kubernetes zu lesen, weckt sicherlich einige Erwartungen – aber der steile Anstieg von Glasskube auf ~2400 GitHub-Sterne und die kürzliche Aufnahme des Startups in den Y Combinator-Inkubator können als Zeichen dafür gewertet werden, dass Glasskube tatsächlich der nächste (oder erste?) Paketmanager für Kubernetes sein könnte.

Glasskube ist vollständig quelloffen (wie Timoni und kapp), verfügt über eine integrierte Benutzeroberfläche und verspricht, sowohl unternehmenstauglich als auch in Gitops integrierbar zu sein. Das Projekt hostet auch eine öffentliche Registry getesteter und verifizierter Pakete, die jeder reviewen und in seinen Clustern verwenden kann.

Aber kommen wir nun zu den technischen Details. Das Herzstück von Glasskube ist seine CLI, die auch für das Bootstrapping der Glasskube-Komponenten im Cluster benötigt wird. Dabei handelt es sich um den Glasskube-eigenen Controller-Manager, der zwei Controller betreibt, sowie die Helm- und Source-Controller von Flux. Wenn du bereits Flux innerhalb deines Clusters einsetzt, kannst du die Installation der Flux-Komponenten ganz überspringen.

Zusätzlich zu diesen Controllern wird Glasskube auch einige CRDs in Deinem Cluster installieren, die Pakete, Repositories und Paketinstallationen für dich verwalten.

Die UI hingegen läuft nicht innerhalb des Clusters; sie wird lokal über die CLI gestartet und bietet eine sehr einfache Möglichkeit, Pakete in deinem Cluster zu installieren.
Glasskube unterscheidet zwischen ClusterPackages, die in einem clusterweiten Kontext (z.B. Operatoren) installiert werden, und Packages, die in namespacegebundenen Kontexten installiert werden. Innerhalb deines Clusters werden diese Paketinstallationen als CustomResources persistiert. Das Gleiche gilt für Registries, die du über die CLI konfigurieren kannst, einschließlich Authentifizierung.

Genau wie kapp baut Glasskube auf bestehenden Lösungen auf – Helm oder reine YAML-Manifeste – um Pakete in Kubernetes bereitzustellen. Ein Glasskube-Paket definiert konfigurierbare Werte, einschließlich Beschreibung, Einschränkungen usw., die dem Benutzer bei der Installation in der Benutzeroberfläche oder im Terminal angezeigt werden. Diese Wertedefinitionen unterstützen sowohl Werteliterale als auch Lookups, die von anderen Cluster-Ressourcen stammen.
Glasskube verarbeitet und validiert diese Werte, bevor sie in die zugrunde liegenden Helm-Werte oder YAML-Manifeste eingefügt werden.

Das Fazit

Mit diesen Informationen können wir wie bei den anderen Kubernetes Deployment Tools einige Schlüsselpunkte von Glasskube identifizieren:

• Benutzerfreundlichkeit: Mit seinem automatisierten Bootstrap-Verfahren, seiner clientseitigen Benutzeroberfläche und immer mehr Paketen, die sofort verfügbar sind, eignet sich Glasskube perfekt für die Erstellung von PoCs und das „Ausprobieren“ von Dingen.
• Dependencymanagement: Als Paketmanager verspricht Glasskube ein vollwertiges Dependencymanagement.
  Dies ist bereits Realität, z.B. wird bei der Installation des Keptn-Pakets auch das cert-manager-Paket als Abhängigkeit installiert.
• GitOps-ready: wie kapp kann Glasskube dank seiner CRDs verwendet werden, um Anwendungen deklarativ bereitzustellen.

Im weiteren Entwicklungsprozess des Projekts würde ich mir wünschen, dass die UI weitere Funktionen für Multi-Tenancy und Benutzer-Governance enthält. Sollte dies jedoch nicht der Fall sein, wird es dank der zugrunde liegenden CRDs, die den Konfigurations- und Bereitstellungsstatus erfassen, trotzdem möglich sein, eigene maßgeschneiderte Benutzeroberflächen zu erstellen.

Quo Vadis, Kubernetes Deployments?

Helm und Kustomize sind Säulen und Standards des Kubernetes-Ökosystems. Eine neue Generation von Deployment-Tools steht jedoch in gewisser Weise auf den Schultern dieser Giganten und versucht, den Status Quo noch zu verbessern.
Nach dem Vergleich dieser drei Kubernetes Deployment Tools ist klar, dass Korrektheit, Verteilung und Automatisierung der Fokus von Timoni, kapp und Glasskube sind:

• Alle drei Lösungen haben einen Weg gefunden, Benutzereingaben zu validieren und/oder Deployment-Prozesse verständlicher zu machen.
• Alle drei Lösungen arbeiten an besseren Möglichkeiten der Verteilung und des Beziehens von Anwendungen.
  Timoni mit seinen Modulen und Bundles, kapp (bzw. kapp-controller) mit seiner Package CRD und Glasskube mit seinen (Cluster-)Package CRDs.
• Alle drei Lösungen heben in ihren Dokumentationen ihre Fähigkeiten zur Integration mit GitOps-Praktiken hervor.
  Automatisierung und deklarative Konfiguration von Infrastruktur- und Anwendungsimplementierungen sind zu einem De-facto-Standard in Kubernetes geworden, und die neue Generation von Kubernetes-Implementierungstools weiß das.

kapp und Glasskube bieten sehr klare Migrationspfade, wenn man von Helmcharts oder YAML-Manifesten kommt – baue einfach auf deinen bestehenden Lösungen auf und erweitere oder refactore sie im Laufe der Zeit.
Timoni hingegen ist mit den anfänglichen Kosten und der Lernkurve von CUE verbunden, verspricht aber eine sehr hohe Performanz und wahrscheinlich die beste Eingabevalidierung der drei verglichenen Tools.

Egal, welchen Weg du letztendlich einschlagen wirst, ich hoffe, dass dieser Artikel ein wenig Licht auf die Optionen wirft, die es heute gibt. Schaue dir auf jeden Fall unsere Tutorials zum Thema Kubernetes an und abonniere unseren Newsletter, um von nun an auf dem Laufenden zu bleiben!