kubara: Kubernetes-Plattform in 30 Minuten, und der Preis dafür

01.08.2026

Thema: alle Beiträge zu Kubernetes

kubara bootstrappt eine GitOps-Plattform aus einem einzigen Binary. Welche Lizenz dahintersteckt und was das Framework dir wirklich abnimmt.

Inhaltsverzeichnis

Eine vollständige Kubernetes-Plattform in unter 30 Minuten: Argo CD, Prometheus, cert-manager, External Secrets, Traefik, alles über GitOps ausgerollt und über mehrere Cluster hinweg. Das verspricht kubara, ein Framework, das STACKIT aus dem Realbetrieb der Schwarz Gruppe heraus offengelegt hat.

Die Antwort vorweg: Der Exit ist eingebaut, gleich zweimal. kubara ist ein reiner Generator, und was am Ende in deinem Git-Repository liegt, sind gewöhnliche Helm-Charts und Argo-CD-Objekte, die weiterlaufen, auch wenn das Werkzeug nie wieder angefasst wird. Seit Version 0.13.0 kommt der zweite Ausgang dazu: Der meinungsstarke Plattform-Stack steckt nicht mehr in der Binary, sondern in einem austauschbaren Katalog. Der Rest dieses Beitrags klärt, was das kostet.

Was kubara ist, und was ausdrücklich nicht

kubara ist eine einzelne Go-Binary mit drei zentralen Kommandos:

kubara init        # Konfiguration und Verzeichnisstruktur anlegen
kubara generate    # Helm- und Terraform-Artefakte aus Katalog-Templates rendern
kubara bootstrap   # CRDs und Argo CD auf den Cluster bringen

Danach übernimmt Argo CD. kubara setzt auf ein Hub-and-Spoke-Modell: ein zentraler Cluster verwaltet sich selbst und die angehängten Spokes, verteilt über label-basierte ApplicationSets.

Der Plattform-Stack, die „General Distro”, bündelt 14 Komponenten, alle selbst Open Source. Seit v0.13.0 ist er nicht mehr Teil der Binary, sondern wird als Katalog nachgeladen, dazu unten mehr:

Bereich Komponenten
Application Management Argo CD, Homer Dashboard, Reloader
Observability Prometheus, Grafana, Loki
Security cert-manager, External Secrets, Kyverno, OAuth2 Proxy
Network ExternalDNS, Traefik, MetalLB
Storage Velero, Longhorn

Genauso wichtig ist, was kubara nicht ist: keine Kubernetes-Distribution, kein Developer-Portal, kein Ersatz für Argo CD. Es baut nichts Eigenes, es verdrahtet Bestehendes nach einem Muster, das im Konzernbetrieb standgehalten hat.

Die Lizenzfrage, und der Befund daneben

Der Code steht unter Apache 2.0, im unveränderten Standardtext, die Dokumentation unter CC BY 4.0. Eine anerkannte Open-Source-Lizenz, kein „source-available”, keine Zusatzklausel. Wer den Unterschied nicht scharf hat: Der steckt in den zehn Kriterien der OSI, und er entscheidet darüber, ob du das Ding morgen noch so nutzen darfst wie heute.

Interessanter ist eine Datei, die fast nie geprüft wird. In der CONTRIBUTING.md von kubara stehen Regeln zu Commit-Konventionen, Pre-Commit-Hooks und Code-Reviews. Was dort nicht steht: eine Forderung nach einem CLA, einem Contributor License Agreement.

Das ist keine Formalie, sondern der Unterschied zwischen „darf relizenziert werden” und „darf es nicht”. Als HashiCorp 2023 auf die BUSL umschwenkte, war das möglich, weil sich das Unternehmen die Beiträge der Community vorher per CLA hatte übereignen lassen. Wer alle Rechte hält, kann jederzeit umschalten. Ohne CLA gehört jeder Beitrag weiterhin seinem Autor, und eine Relizenzierung bräuchte die Zustimmung aller Beteiligten. Das ist in der Praxis eine sehr hohe Hürde.

Ehrlich dazugesagt: Das ist keine Garantie. Ein Projekt kann später einen CLA einführen, und der Code, den STACKIT selbst geschrieben hat, gehört STACKIT. Aber es ist ein deutliches Signal, und es ist mehr Schutz als die Lizenz allein liefert.

Der Träger bleibt trotzdem ein einzelnes Unternehmen. kubara liegt nicht in einer Stiftung, nicht bei der CNCF, und die Kontaktadresse lautet kubara@digits.schwarz. Ein neutrales Gremium gibt es nicht. Das Risiko heißt hier allerdings weniger Rug-Pull als schlicht Aufgabe des Projekts, und dagegen hilft Apache 2.0 tatsächlich: Der erreichte Stand bleibt nutzbar und forkbar.

Was am Ende in deinem Repository liegt

Der entscheidende Punkt bei jedem Framework, das dir Arbeit abnimmt, ist die Frage, was passiert, wenn du es loswerden willst. Die Dokumentation beantwortet das nicht eindeutig, also habe ich es ausgeführt: v0.13.0 heruntergeladen, Prüfsumme verifiziert, in einem leeren Verzeichnis init und generate laufen lassen. Beides braucht keinen Cluster.

Das Ergebnis sind 118 Dateien in zwei sauber getrennten Verzeichnissen:

platform-components/helm/<komponente>/     Umbrella-Chart je Komponente
platform-configs/<cluster>/helm/<komponente>/values.generated.yaml

Und ein Umbrella-Chart sieht so aus:

apiVersion: v2
name: traefik
version: 2.1.0
dependencies:
  - name: traefik
    version: 41.0.2
    repository: oci://ghcr.io/traefik/helm
  - name: template-library
    repository: file://../template-library
    version: 0.2.0

Drei Beobachtungen daraus, und alle drei zeigen in dieselbe Richtung:

Es läuft nichts von kubara im Cluster. Kein Controller, kein Operator, keine eigene CustomResourceDefinition. Die erzeugten Objekte sind Standard-Typen und die CRDs der eingebundenen Projekte, also ExternalSecret, ClusterIssuer, Certificate, ServiceMonitor.

Die Zeichenfolge „kubara” taucht im Ergebnis dreimal auf, und keiner der Treffer ist funktional: in der Beschreibung eines Charts, in der Verlinkung des Homer-Dashboards und als Kopfkommentar in den generierten Wertedateien. Der Rest ist Standard-Helm.

Die Abhängigkeiten zeigen auf die Hersteller, nicht auf einen Spiegel. charts.jetstack.io für cert-manager, argoproj.github.io für Argo CD, oci://ghcr.io/traefik/helm für Traefik. Das ist genau die Frage aus dem Beitrag dazu, wer dir deine Provider liefert: Hier schiebt sich niemand in den Vertriebsweg.

Damit ist die Ausgangsfrage beantwortet. Was dort liegt, ist ein gewöhnliches GitOps-Repository. Argo CD rollt es weiter aus, auch wenn es kubara nie wieder sieht.

Eine Einschränkung gehört dazu. Die generierten Wertedateien tragen einen unmissverständlichen Kopf:

# AUTO-GENERATED; DO NOT MODIFY;
# To customize values, you can add additional files named values-*.yaml to this directory.

Der generierte Stand gehört also dem Generator, deine Anpassungen gehören in die config.yaml oder in zusätzliche Wertedateien daneben. Das ist ein sauberer, dokumentierter Weg und keine Sackgasse. Es ist aber eine Strukturvorgabe: Wer die generierten Dateien von Hand pflegt, arbeitet gegen das Werkzeug.

Was es dir abnimmt

Die Auswahl. Die 14 Komponenten sind nicht die spannendste denkbare Auswahl, sondern eine, die im Konzernbetrieb gehalten hat. Wer selbst baut, verbringt Wochen mit Vergleichen, die andere schon durchgemacht haben, und trifft die Entscheidungen dann trotzdem aus zweiter Hand aus Blogposts.

Sicherheit als Ausgangszustand. Ingress hinter OAuth2 Proxy, Argo-CD-RBAC über Projects begrenzt, Kyverno-Policies von Anfang an. Das sind exakt die Punkte, die beim Eigenbau zuverlässig auf „machen wir gleich danach” wandern und dort liegen bleiben.

Reproduzierbarkeit. Versionierte Kataloge und generierte Artefakte ersetzen die gewachsene Sammlung aus Ad-hoc-Skripten und handkopierten Werten, die in den meisten Plattformen nach einem Jahr den eigentlichen Zustand darstellt.

Multi-Cluster ab Tag eins. Hub-and-Spoke und ApplicationSets sind beim Eigenbau typischerweise der Punkt, an dem die erste selbstgebaute Struktur zusammenbricht, nämlich sobald der zweite und dritte Cluster dazukommen.

Eine saubere Lieferkette. Jedes Release bringt SBOMs zu allen Artefakten mit, dazu Prüfsummen und eine licenses.csv mit den Lizenzen sämtlicher Go-Abhängigkeiten. Die Prüfsumme des heruntergeladenen Archivs stimmt. Das ist der Stand, den man von einer Freigabe erwarten sollte und viel zu selten bekommt.

Was es dich kostet

Pre-1.0, und das merkt man deutlich. Aktuell ist v0.13.0 vom 28. Juli 2026. v0.12.0 hat das Katalog-Layout umbenannt und Flags entfernt, v0.11.0 die Struktur der Secret-Pfade umgebaut. Zwei Breaking Changes in zwei Minor-Versionen. Wer heute bootstrappt, migriert absehbar mehrfach, und zwar an einer Plattform, auf der dann bereits Dinge laufen.

Du erbst 14 Betriebslasten. Traefik statt ingress-nginx, Longhorn statt des CSI-Treibers deines Providers, MetalLB für Load Balancing. Jede dieser Entscheidungen ist vertretbar, aber sie ist getroffen. Wer abweicht, arbeitet gegen den Katalog, und wer nicht abweicht, betreibt ab sofort 14 Projekte, die er sich nicht ausgesucht hat.

Der Versionstakt kommt aus dem Katalog. Wann Traefik von 41.0.2 auf die nächste Version geht, entscheidet zunächst nicht ihr, sondern der Katalog, den ihr referenziert. Wie weit das trägt, klärt der nächste Abschnitt, denn genau hier hat sich mit v0.13.0 das Wichtigste geändert.

Es deckt nur das Fundament. Kein Backstage, keine Self-Service-Templates, kein Entwicklerportal. Die Oberfläche, an der Entwicklerinnen und Entwickler tatsächlich arbeiten, baust du weiterhin selbst.

Die eigentliche Nachricht von Version 0.13.0

Wer sich kubara vor dem 28. Juli 2026 angesehen hat, hat ein anderes Werkzeug gesehen. In den Release-Notes von v0.13.0 steht ein Eintrag, der unscheinbar wirkt und die Bewertung des ganzen Projekts verschiebt: feat: declarative external catalogs.

Bis dahin war der Plattform-Stack in die Binary eingebaut. Jetzt ist er es nicht mehr. kubara bringt keinen eingebauten Katalog mehr mit, sondern zieht ihn als OCI-Artefakt. Nach meinem Durchlauf liegen genau zwei davon im lokalen Cache:

NAME       VERSION  REFERENCE
bootstrap  1.1.0    oci://ghcr.io/kubara-io/catalogs/bootstrap:1.1.0
general    1.1.0    oci://ghcr.io/kubara-io/catalogs/general:1.1.0

Die Aufteilung ist der Kern der Sache:

Referenziert werden sie pro Cluster in der config.yaml, als gewöhnliche Liste:

clusters:
  - name: test-cluster
    catalogs:
      - oci://ghcr.io/kubara-io/catalogs/general:1.1.0

Damit hat jeder Cluster seinen eigenen, deklarativ festgehaltenen Katalogstand. Der Testcluster darf auf 1.2.0 gehen, während die Produktion auf 1.1.0 bleibt, und dieser Unterschied steht versioniert im Repository statt im Kopf einer Person. Beliebig viele Kataloge lassen sich kombinieren, bei Namenskollisionen entscheidet --catalog-overwrite, welcher gewinnt.

Warum das die Lock-in-Frage entschärft

Ein eigener Katalog ist damit kein Eigenbau von null. kubara bringt den kompletten Lebenszyklus als Unterkommandos mit: create, add, package, push, pull, list und unpackage.

Das letzte ist das interessanteste. kubara catalog unpackage holt einen zwischengespeicherten OCI-Katalog als bearbeitbares Verzeichnis zurück. Ich habe es mit dem General-Katalog gemacht:

kubara catalog unpackage oci://ghcr.io/kubara-io/catalogs/general:1.1.0 mein-katalog

Heraus kommen 307 Dateien in einer nachvollziehbaren Struktur: eine Catalog.yaml mit Name und Version, dazu je Komponente eine Service-Definition unter services/, und darunter die Helm- und Terraform-Vorlagen. Eine solche Definition ist erfreulich unspektakulär:

apiVersion: kubara.io/v1alpha1
kind: ServiceDefinition
metadata:
  name: traefik
  annotations:
    kubara.io/category: networking
spec:
  chartPath: traefik
  status: enabled
  clusterTypes: [hub, spoke]

Der Weg ist damit vollständig offen: den kuratierten Stack auspacken, Traefik gegen den eigenen Ingress tauschen, Longhorn gegen den CSI-Treiber eures Providers, das Ergebnis in die eigene Registry pushen und in der config.yaml referenzieren. Ihr behaltet den Mechanismus und ersetzt die Meinung.

Das verändert die Bewertung an zwei Stellen. Der oben genannte Einwand, dass man 14 Komponenten samt Betriebslast erbt, ist damit keine Einbahnstraße mehr, sondern ein Startwert. Und die Versionshoheit lässt sich zurückholen, indem man den Katalog selbst hostet, statt auf den Takt von kubara-io zu warten. Für automatische Aktualisierungen der Katalogversionen ist Renovate-Unterstützung angekündigt.

Für ein Projekt, dessen Trägerschaft bei einem einzelnen Unternehmen liegt, ist das die richtige Richtung: Je austauschbarer der meinungsstarke Teil ist, desto weniger hängt an der Meinung des Herstellers.

Der Einwand, der keiner gegen das Werkzeug ist

Bleibt der wichtigste Punkt, und er richtet sich nicht gegen kubara, sondern gegen eine Erwartung, die solche Werkzeuge wecken.

30 Minuten bis zur laufenden Plattform ersetzen kein Verständnis. Beim ersten ApplicationSet, das nicht synchronisiert, stehst du vor generiertem YAML, das du nicht geschrieben hast, in einer Verzeichnisstruktur, die du nicht entworfen hast, mit einer Argo-CD-RBAC-Konfiguration, deren Begründung in einem fremden Repository steht. Der Zustand „läuft” und der Zustand „verstanden” sind zwei verschiedene Dinge, und ein Bootstrap-Kommando erzeugt nur den ersten.

Händisches Bauen ist langsam, fehleranfällig und produziert am Anfang schlechtere Ergebnisse. Es ist aber gleichzeitig der Lernvorgang. Wer Argo CD, cert-manager und External Secrets einmal selbst verdrahtet hat, liest das generierte Ergebnis später als Bestätigung oder als Widerspruch. Wer es nicht hat, liest es gar nicht.

Deshalb ist die produktivste Art, kubara zu benutzen, nicht die schnellste: generieren, und dann lesen, was da entstanden ist. 118 Dateien sind an einem Nachmittag durchzuarbeiten. Danach hast du beides, eine laufende Plattform und eine Vorstellung davon, warum sie so aussieht.

Für wen lohnt es sich?

Ja, wenn ihr eine Plattform von Grund auf aufbaut und die Grundsatzentscheidungen nicht selbst durchleiden wollt. Ebenso, wenn ihr bereits selbst gebaut habt und eure Struktur gegen eine gegenprüfen möchtet, die im Konzernbetrieb standgehalten hat. Und für alle, die Platform Engineering lernen, ist der generierte Baum das bessere Lehrmaterial als jedes Tutorial.

Nein, wenn ihr eine laufende, gewachsene Plattform habt. Der Umbau auf kubaras Struktur ist dann teurer als der Nutzen. Ebenso, wenn euer Stack stark abweicht, also anderer Ingress, Storage vom Cloud-Anbieter, eigene Observability. Dann kämpft ihr gegen den Katalog. Und nein, wenn niemand im Team die Zeit hat, das Erzeugte zu lesen. Dann bekommt ihr eine Plattform, die niemand verantworten kann.

Fazit

  1. Der Code steht unter Apache 2.0, die Doku unter CC BY 4.0. Eine echte Open-Source-Lizenz, keine Zusatzklausel.
  2. Der interessantere Befund ist das fehlende CLA in der CONTRIBUTING.md. Genau dieser Hebel machte die HashiCorp-Relizenzierung möglich. Ohne ihn ist ein Rug-Pull deutlich unwahrscheinlicher.
  3. kubara ist ein reiner Generator. Kein Controller, kein Operator, keine eigene CRD, Abhängigkeiten direkt auf die Hersteller. Was im Repo liegt, gehört dir und läuft ohne das Werkzeug weiter.
  4. Seit v0.13.0 ist der Plattform-Stack nicht mehr eingebaut, sondern ein austauschbarer OCI-Katalog, deklarativ je Cluster versioniert. Der meinungsstarke Teil ist damit ersetzbar, der Mechanismus bleibt.
  5. Der Preis ist trotzdem real: pre-1.0 mit Breaking Changes in zwei aufeinanderfolgenden Minor-Versionen und 14 Komponenten, die ihr erst einmal erbt.
  6. Beide Säulen geprüft: Die Lizenz erfüllt Säule 2 überdurchschnittlich gut. Säule 1, das technische Verständnis, nimmt dir kein Werkzeug ab.

kubara nimmt dir das Bauen ab, nicht das Verstehen. Das ist kein Vorwurf, sondern die korrekte Beschreibung dessen, was ein Framework leisten kann. Wer beides trennt, hat ein sehr gutes Werkzeug in der Hand. Wer es verwechselt, hat in 30 Minuten eine Plattform gebaut, die ihm nicht gehört.

© 2026 Trutz Software Consulting GmbH. CC BY 4.0: Dieser Text darf mit Namensnennung weiterverwendet und bearbeitet werden, auch kommerziell. Code-Beispiele darin stehen unter Apache 2.0. Ausgenommen sind Marke und Logo sowie gekennzeichnete Zitate Dritter. Was das genau heißt.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.