Article associé : Monedula GitOps : la gestion déclarative de Kafka pour la CLI et Kubernetes présente la version v0.1.0, le modèle de ressources et le flux de travail de base.

Pourquoi

La configuration de Kafka vit rarement au même endroit. Les topics viennent d’un script, les ACL d’un autre, les schémas des pipelines applicatifs, les quotas de l’administration et les role bindings RBAC de Confluent d’un outil encore différent. Avec le temps, le cluster en production devient la seule description fiable du système — mais une description ni intentionnelle ni relisible.

monedula-gitops rend cette description explicite : décrire l’état Kafka souhaité dans Git, le relire comme du code, le comparer au cluster en production et faire converger le cluster vers lui.

Kafka, ce n’est pas seulement des topics : le modèle couvre donc les ressources qui vont généralement ensemble — règles d’accès, groupes de consommateurs, quotas, schémas, identifiants et, sur Confluent Platform, role bindings RBAC.

Un modèle, deux runtimes

La CLI et l’opérateur Kubernetes utilisent le même modèle de ressources et le même moteur de réconciliation.

  • CLI — valider, comparer, appliquer et vérifier les manifestes depuis un poste de développement ou un pipeline CI/CD. verify renvoie un code de sortie non nul lorsqu’un drift est détecté : il fait office de garde-fou de CI.
  • Opérateur — installer ces mêmes ressources de style Kubernetes en tant que CRD et les réconcilier en continu dans un cluster.

Les identifiants sont fournis différemment dans chaque runtime — références d’environnement ou de fichiers pour la CLI, Secrets Kubernetes pour l’opérateur — mais l’état souhaité, les règles de drift et la sémantique d’exécution restent cohérents. Une équipe peut commencer par des changements pilotés par le pipeline et adopter l’opérateur plus tard, sans concevoir un second modèle de configuration.

Ce qu’il gère

KafkaCluster (connexion, authentification, valeurs par défaut, Schema Registry, Confluent MDS optionnel), KafkaTopic (cycle de vie, partitions, configuration, accès local au topic, schémas), KafkaAccessPolicy (règles ACL avancées et partagées), KafkaQuota (quotas par utilisateur, client-id et IP), KafkaUser (identifiants SCRAM) et KafkaRoleBinding (MDS/RBAC Confluent).

Le cas courant reste petit : un topic et les applications autorisées à l’utiliser tiennent dans un seul manifeste, d’où sont générées les ACL de topic et de groupe de consommateurs correspondantes :

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

Également disponible via go install, sous forme de binaires précompilés dans les releases GitHub et d’image de conteneur sur ghcr.io/monedula-dev/monedula-gitops. L’opérateur s’installe avec Helm depuis oci://ghcr.io/monedula-dev/charts/monedula-gitops.

Partir d’un cluster existant

Les environnements réels sont rarement vides : import cluster lit l’état Kafka actuel et en génère des manifestes — topics, règles d’accès, quotas, schémas, utilisateurs SCRAM et role bindings RBAC de Confluent là où c’est pris en charge. Tout l’intérêt est l’aller-retour : vérifier le répertoire importé face au même cluster ne devrait signaler aucun drift.

Les opérations risquées sont protégées, et la suppression comme le pruning exigent une activation explicite. Le dépôt contient deux quickstarts exécutables (un terrain de jeu CLI avec Docker Compose et un terrain de jeu opérateur sur Kubernetes local) ainsi qu’un catalogue de 25 scénarios autonomes.