Artículo complementario: Monedula GitOps: gestión declarativa de Kafka para CLI y Kubernetes presenta la versión v0.1.0, el modelo de recursos y el flujo de trabajo básico.

Por qué

La configuración de Kafka rara vez vive en un solo sitio. Los topics vienen de un script, las ACL de otro, los esquemas de los pipelines de las aplicaciones, las cuotas de administración y los role bindings de RBAC de Confluent de otra herramienta más. Con el tiempo, el clúster en marcha acaba siendo la única descripción fiable del sistema, pero no una descripción intencionada ni revisable.

monedula-gitops hace explícita esa descripción: describe el estado deseado de Kafka en Git, revísalo como si fuera código, compáralo con el clúster en marcha y haz converger el clúster hacia él.

Kafka no son solo topics, así que el modelo cubre los recursos que suelen ir juntos: reglas de acceso, grupos de consumidores, cuotas, esquemas, credenciales y, en Confluent Platform, role bindings de RBAC.

Un modelo, dos entornos de ejecución

La CLI y el operador de Kubernetes usan el mismo modelo de recursos y el mismo motor de reconciliación.

  • CLI — valida, compara, aplica y verifica manifiestos desde la máquina de desarrollo o desde un pipeline de CI/CD. verify devuelve un código de salida distinto de cero cuando encuentra drift, así que funciona como gate de CI.
  • Operador — instala esos mismos recursos al estilo Kubernetes como CRD y los reconcilia de forma continua dentro de un clúster.

Las credenciales se proporcionan de forma distinta en cada entorno — referencias a variables de entorno o a ficheros en la CLI, Secrets de Kubernetes en el operador—, pero el estado deseado, las reglas de drift y la semántica de ejecución se mantienen coherentes. Un equipo puede empezar con cambios impulsados por el pipeline y adoptar el operador más tarde sin diseñar un segundo modelo de configuración.

Qué gestiona

KafkaCluster (conexión, autenticación, valores por defecto, Schema Registry, Confluent MDS opcional), KafkaTopic (ciclo de vida, particiones, configuración, acceso local al topic, esquemas), KafkaAccessPolicy (reglas ACL avanzadas y compartidas), KafkaQuota (cuotas por usuario, client-id e IP), KafkaUser (credenciales SCRAM) y KafkaRoleBinding (MDS/RBAC de Confluent).

El caso común se queda pequeño: un topic y las aplicaciones autorizadas a usarlo caben en un solo manifiesto, y de ahí se generan las ACL correspondientes de topic y de grupo de consumidores:

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

Instalación

brew install monedula-dev/tap/monedula-gitops

También disponible mediante go install, como binarios precompilados en las releases de GitHub y como imagen de contenedor en ghcr.io/monedula-dev/monedula-gitops. El operador se instala con Helm desde oci://ghcr.io/monedula-dev/charts/monedula-gitops.

Empezar desde un clúster existente

Los entornos reales rara vez están vacíos, así que import cluster lee el estado actual de Kafka y genera manifiestos a partir de él: topics, reglas de acceso, cuotas, esquemas, usuarios SCRAM y role bindings de RBAC de Confluent allí donde hay soporte. La clave es el viaje de ida y vuelta: verificar el directorio importado contra el mismo clúster no debería reportar ningún drift.

Las operaciones arriesgadas están protegidas, y el borrado y el pruning requieren activarlos explícitamente. En el repositorio hay dos quickstarts ejecutables (un playground de CLI con Docker Compose y un playground del operador sobre Kubernetes local) y un catálogo de 25 escenarios autocontenidos.