monedula-gitops — Monedula

関連記事： Monedula GitOps — CLI と Kubernetes のための宣言的な Kafka 管理では、v0.1.0 リリース、リソースモデル、基本的なワークフローを紹介しています。

なぜ

Kafka の設定が一か所にまとまっていることは、めったにありません。トピックはあるスクリプトから、ACL は別のスクリプトから、スキーマはアプリケーションのパイプラインから、クォータは管理者から、Confluent RBAC のロールバインディングはさらに別のツールから生まれます。時間が経つと、稼働中のクラスタだけがシステムの唯一の信頼できる記述になります — 意図して書かれたものでも、レビューできるものでもない記述が。

monedula-gitops は、その記述を明示的なものにします。あるべき Kafka の状態を Git に記述し、コードと同じようにレビューし、稼働中のクラスタと比較し、クラスタをその状態へ収束させます。

Kafka はトピックだけではないので、モデルはふつう一緒に扱われるリソース — アクセスルール、コンシューマーグループ、クォータ、スキーマ、認証情報、そして Confluent Platform ではロールバインディング — までをカバーします。

1 つのモデル、2 つのランタイム

CLI と Kubernetes オペレーターは、同じリソースモデルと同じリコンサイルエンジンを使います。

CLI — 開発マシンや CI/CD パイプラインから、マニフェストを検証し、差分を取り、適用し、確認します。verify はドリフトを見つけると 0 以外の終了コードを返すので、CI のゲートとして機能します。
オペレーター — 同じ Kubernetes スタイルのリソースを CRD としてインストールし、クラスタ内で継続的にリコンサイルします。

認証情報の与え方はランタイムごとに異なります — CLI では環境変数やファイルの参照、オペレーターでは Kubernetes の Secret です — が、あるべき状態、ドリフトのルール、実行のセマンティクスは一貫しています。チームはまずパイプライン駆動の変更から始め、2 つ目の設定モデルを設計することなく、後からオペレーターを導入できます。

管理できるもの

KafkaCluster（接続、認証、デフォルト値、Schema Registry、任意の Confluent MDS）、KafkaTopic（ライフサイクル、パーティション、設定、トピックローカルなアクセス、スキーマ）、KafkaAccessPolicy（高度な、あるいは共有される ACL ルール）、KafkaQuota（ユーザー、client-id、IP のクォータ）、KafkaUser （SCRAM 認証情報）、KafkaRoleBinding（Confluent MDS/RBAC）。

よくあるケースは小さいままです。トピックとその利用を許可されたアプリケーションは 1 つのマニフェストに収まり、対応するトピックとコンシューマーグループの ACL はそこから生成されます。

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

インストール

brew install monedula-dev/tap/monedula-gitops

go install、GitHub リリースのビルド済みバイナリ、 ghcr.io/monedula-dev/monedula-gitops のコンテナイメージも利用できます。オペレーターは Helm で oci://ghcr.io/monedula-dev/charts/monedula-gitops からインストールします。

既存クラスタから始める

現実の環境が空であることはまずないので、import cluster は現在の Kafka の状態を読み取り、そこからマニフェストを生成します — トピック、アクセスルール、クォータ、スキーマ、SCRAM ユーザー、そしてサポートされている場合は Confluent RBAC のロールバインディングまで。大事なのはラウンドトリップです。インポートしたディレクトリを同じクラスタに対して検証すると、ドリフトは報告されないはずです。

リスクのある操作にはガードがかかっており、削除とプルーニングは明示的に有効化しないと実行されません。リポジトリには、実行できるクイックスタートが 2 つ（Docker Compose の CLI プレイグラウンドと、ローカル Kubernetes 上のオペレーターのプレイグラウンド）と、25 個の自己完結したシナリオのカタログが入っています。