Begleitender Beitrag: Monedula GitOps: deklaratives Kafka-Management für CLI und Kubernetes stellt das Release v0.1.0, das Ressourcenmodell und den grundlegenden Workflow vor.

Warum

Kafka-Konfiguration liegt selten an einem einzigen Ort. Topics kommen aus einem Skript, ACLs aus einem anderen, Schemas aus Anwendungs-Pipelines, Quotas aus der Administration und Confluent-RBAC-Rollenbindungen aus wieder einem anderen Werkzeug. Mit der Zeit ist der laufende Cluster die einzige verlässliche Beschreibung des Systems — aber keine beabsichtigte und keine, die man reviewen könnte.

monedula-gitops macht diese Beschreibung explizit: den gewünschten Kafka-Zustand in Git beschreiben, wie Code reviewen, mit dem laufenden Cluster vergleichen und den Cluster darauf zuführen.

Kafka besteht nicht nur aus Topics, deshalb deckt das Modell die Ressourcen ab, die üblicherweise zusammengehören — Zugriffsregeln, Consumer Groups, Quotas, Schemas, Credentials und, in der Confluent Platform, RBAC-Rollenbindungen.

Ein Modell, zwei Laufzeiten

CLI und Kubernetes-Operator nutzen dasselbe Ressourcenmodell und dieselbe Reconciliation-Engine.

  • CLI — Manifeste von einem Entwicklungsrechner oder aus einer CI/CD-Pipeline validieren, diffen, anwenden und verifizieren. verify liefert bei erkanntem Drift einen Exit-Code ungleich null und taugt damit als CI-Gate.
  • Operator — dieselben Kubernetes-artigen Ressourcen als CRDs installieren und innerhalb eines Clusters fortlaufend abgleichen.

Credentials werden in beiden Laufzeiten unterschiedlich bereitgestellt — Umgebungs- oder Dateireferenzen für die CLI, Kubernetes Secrets für den Operator —, aber gewünschter Zustand, Drift-Regeln und Ausführungssemantik bleiben konsistent. Ein Team kann mit Pipeline-getriebenen Änderungen beginnen und den Operator später einführen, ohne ein zweites Konfigurationsmodell zu entwerfen.

Was es verwaltet

KafkaCluster (Verbindung, Authentifizierung, Defaults, Schema Registry, optional Confluent MDS), KafkaTopic (Lebenszyklus, Partitionen, Konfiguration, topic-lokaler Zugriff, Schemas), KafkaAccessPolicy (fortgeschrittene und gemeinsam genutzte ACL-Regeln), KafkaQuota (Quotas für Benutzer, Client-ID und IP), KafkaUser (SCRAM-Credentials) und KafkaRoleBinding (Confluent MDS/RBAC).

Der häufigste Fall bleibt klein: Ein Topic und die Anwendungen, die es nutzen dürfen, passen in ein Manifest, und die zugehörigen Topic- und Consumer-Group-ACLs werden daraus erzeugt:

apiVersion: gitops.monedula.dev/v1alpha1
kind: KafkaTopic
metadata:
  name: orders
spec:
  clusterRef:
    name: prod
  topicName: orders
  partitions: 6
  access:
    producers:
      - principal: User:svc-checkout
    consumers:
      - principal: User:svc-fraud
        group: fraud-orders

Installation

brew install monedula-dev/tap/monedula-gitops

Ebenso verfügbar über go install, als vorgebaute Binaries aus den GitHub-Releases und als Container-Image unter ghcr.io/monedula-dev/monedula-gitops. Der Operator wird per Helm aus oci://ghcr.io/monedula-dev/charts/monedula-gitops installiert.

Mit einem bestehenden Cluster starten

Echte Umgebungen sind selten leer, deshalb liest import cluster den aktuellen Kafka-Zustand und erzeugt daraus Manifeste — Topics, Zugriffsregeln, Quotas, Schemas, SCRAM-Benutzer und, wo unterstützt, Confluent-RBAC-Rollenbindungen. Entscheidend ist der Round Trip: Wird das importierte Verzeichnis gegen denselben Cluster verifiziert, sollte kein Drift gemeldet werden.

Riskante Operationen sind abgesichert, Löschen und Pruning erfordern eine ausdrückliche Freigabe. Im Repository liegen zwei lauffähige Quickstarts (ein CLI-Spielplatz mit Docker Compose und ein Operator-Spielplatz auf lokalem Kubernetes) sowie ein Katalog mit 25 in sich geschlossenen Szenarien.