GitOps manages Kafka infrastructure declaratively: Git stores the desired configuration, while automation reconciles the running cluster with that state. This replaces inconsistent manual setup with reviewable, repeatable change management. section 10.0 section 10.2.2
A Kafka GitOps workflow typically:
- Defines topics and other Kafka artifacts in text-based YAML or JSON files. section 10.2.2
- Stores configuration in Git, where commits, diffs, pull requests, review history, and rollback points provide traceability. section 10.2.2
- Triggers a CI/CD pipeline when changes are pushed, compares declared and current cluster state, and applies only the required changes. section 10.2.2
- Detects configuration drift caused by authorized direct changes and warns about, or proposes, corrective action. section 10.2.2
Customer 360 ODS
A Customer 360 operational data store uses AsyncAPI specifications as its architectural source of truth. Because the team does not run Kubernetes, it generates Kafka-compatible resources through CI/CD, commits those resources to Git, and synchronizes the cluster with the declared state. This separates technology-agnostic event design from Kafka-specific deployment while preserving traceability. section 10.2.5
Figure 10.1 Applying Kafka cluster modifications via GitOps: after the updated Kafka cluster configuration is pushed, the CI/CD pipeline retrieves the current cluster state, calculates the required modifications, and applies them.
The reconciliation loop compares the updated configuration in Git with the current Kafka cluster, calculates the difference, and applies the necessary modifications. section 10.2.2
