Powiązany wpis: Monedula GitOps: deklaratywne zarządzanie Kafką dla CLI i Kubernetesa przedstawia wydanie v0.1.0, model zasobów i podstawowy przepływ pracy.

Dlaczego

Konfiguracja Kafki rzadko mieszka w jednym miejscu. Tematy pochodzą z jednego skryptu, ACL-e z drugiego, schematy z pipeline’ów aplikacji, limity od administratora, a powiązania ról Confluent RBAC z jeszcze innego narzędzia. Z czasem jedynym wiarygodnym opisem systemu staje się działający klaster — opisem, którego nikt nie zaprojektował i którego nie da się przejrzeć.

monedula-gitops czyni ten opis jawnym: opisz pożądany stan Kafki w Gicie, przejrzyj go jak kod, porównaj z działającym klastrem i doprowadź klaster do tego stanu.

Kafka to nie tylko tematy, więc model obejmuje te zasoby, które zwykle idą w parze — reguły dostępu, grupy konsumentów, limity, schematy, poświadczenia, a w Confluent Platform także powiązania ról RBAC.

Jeden model, dwa środowiska uruchomieniowe

CLI i operator Kubernetesa używają tego samego modelu zasobów i tego samego silnika uzgadniania.

  • CLI — waliduj, porównuj, stosuj i weryfikuj manifesty z maszyny dewelopera albo z pipeline’u CI/CD. verify zwraca niezerowy kod wyjścia, gdy wykryje dryf, więc działa jako bramka w CI.
  • Operator — zainstaluj te same zasoby w stylu Kubernetesa jako CRD i uzgadniaj je w sposób ciągły wewnątrz klastra.

Poświadczenia dostarcza się inaczej w każdym środowisku — przez zmienne środowiskowe lub odwołania do plików w CLI, przez Sekrety Kubernetesa w operatorze — ale pożądany stan, reguły dryfu i semantyka wykonania pozostają spójne. Zespół może zacząć od zmian sterowanych pipeline’em i wdrożyć operator później, bez projektowania drugiego modelu konfiguracji.

Czym zarządza

KafkaCluster (połączenie, uwierzytelnianie, wartości domyślne, Schema Registry, opcjonalnie Confluent MDS), KafkaTopic (cykl życia, partycje, konfiguracja, dostęp lokalny dla tematu, schematy), KafkaAccessPolicy (zaawansowane i współdzielone reguły ACL), KafkaQuota (limity dla użytkownika, client-id i IP), KafkaUser (poświadczenia SCRAM) oraz KafkaRoleBinding (Confluent MDS/RBAC).

Najczęstszy przypadek pozostaje drobny — temat i aplikacje, które mają prawo z niego korzystać, mieszczą się w jednym manifeście, a odpowiadające im ACL-e tematu i grupy konsumentów są z niego generowane:

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

Instalacja

brew install monedula-dev/tap/monedula-gitops

Dostępne także przez go install, jako gotowe binaria z wydań na GitHubie oraz jako obraz kontenera pod ghcr.io/monedula-dev/monedula-gitops. Operator instaluje się Helmem z oci://ghcr.io/monedula-dev/charts/monedula-gitops.

Zacznij od istniejącego klastra

Prawdziwe środowiska rzadko są puste, więc import cluster odczytuje bieżący stan Kafki i generuje z niego manifesty — tematy, reguły dostępu, limity, schematy, użytkowników SCRAM oraz powiązania ról Confluent RBAC tam, gdzie jest to wspierane. Chodzi o podróż w obie strony: weryfikacja zaimportowanego katalogu wobec tego samego klastra nie powinna zgłosić żadnego dryfu.

Ryzykowne operacje są zabezpieczone, a usuwanie i przycinanie wymagają wyraźnej zgody. W repozytorium są dwa gotowe do uruchomienia quickstarty (plac zabaw dla CLI na Docker Compose i plac zabaw dla operatora na lokalnym Kubernetesie) oraz katalog 25 samodzielnych scenariuszy.