Companion post: Monedula GitOps: Declarative Kafka Management for CLI and Kubernetes introduces the v0.1.0 release, the resource model, and the basic workflow.

Why

Kafka configuration rarely lives in one place. Topics come from one script, ACLs from another, schemas from application pipelines, quotas from an administrator, and Confluent RBAC role bindings from yet another tool. Over time the live cluster becomes the only reliable description of the system — but not an intentional or reviewable one.

monedula-gitops makes that description explicit: describe the desired Kafka state in Git, review it like code, compare it with the live cluster, and converge the cluster toward it.

Kafka is not only about topics, so the model covers the resources that usually belong together — access rules, consumer groups, quotas, schemas, credentials, and, on Confluent Platform, RBAC role bindings.

One model, two runtimes

The CLI and the Kubernetes operator use the same resource model and the same reconciliation engine.

  • CLI — validate, diff, apply, and verify manifests from a developer machine or a CI/CD pipeline. verify returns a non-zero exit code when drift is found, so it works as a CI gate.
  • Operator — install the same Kubernetes-style resources as CRDs and reconcile them continuously inside a cluster.

Credentials are supplied differently in each runtime — environment or file references for the CLI, Kubernetes Secrets for the operator — but the desired state, drift rules, and execution semantics stay consistent. A team can start with pipeline-driven changes and adopt the operator later without designing a second configuration model.

What it manages

KafkaCluster (connection, authentication, defaults, Schema Registry, optional Confluent MDS), KafkaTopic (lifecycle, partitions, configuration, topic-local access, schemas), KafkaAccessPolicy (advanced and shared ACL rules), KafkaQuota (user, client-id, and IP quotas), KafkaUser (SCRAM credentials), and KafkaRoleBinding (Confluent MDS/RBAC).

The common case stays small — a topic and the applications allowed to use it fit in one manifest, and the matching topic and consumer-group ACLs are generated from it:

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

Install

brew install monedula-dev/tap/monedula-gitops

Also available via go install, as prebuilt binaries from the GitHub releases, and as a container image at ghcr.io/monedula-dev/monedula-gitops. The operator installs with Helm from oci://ghcr.io/monedula-dev/charts/monedula-gitops.

Start from an existing cluster

Real environments are rarely empty, so import cluster reads the current Kafka state and generates manifests from it — topics, access rules, quotas, schemas, SCRAM users, and Confluent RBAC role bindings where supported. The round trip is the point: verifying the imported directory against the same cluster should report no drift.

Risky operations are guarded, and deletion and pruning require explicit opt-in. Two runnable quickstarts (a Docker Compose CLI playground and an operator playground on local Kubernetes) and a catalog of 25 self-contained scenarios live in the repo.