---
title: "monedula-gitops"
repo: https://github.com/monedula-dev/monedula-gitops
language: Go
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---> **Artículo complementario:** [Monedula GitOps: gestión declarativa de Kafka para CLI y Kubernetes](/blog/monedula-gitops/) 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:

```yaml
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

```bash
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.