Kafka operations with
Strimzi context attached.
Use native Kafka APIs for records, topics, groups, and ACLs, then add explicit Kubernetes access for Kafka, KafkaNodePool, and KafkaRebalance evidence and workflows.
Respect the boundary between Kafka and its operator.
Strimzi manages Kafka through Kubernetes resources while Kafka clients still use the normal Kafka protocol. BetterKafka treats those as separate trust boundaries: core Kafka operations do not require Kubernetes access, and Strimzi capabilities are enabled only when the deployment explicitly attaches a namespace and RBAC scope.
Cruise Control actions are represented through Strimzi KafkaRebalance resources. BetterKafka does not bypass the operator or call Cruise Control directly, and stopping active movement is never described as rollback.
Kafka and node pools
Read provider evidence and selected Kafka/KafkaNodePool status from a fixed, namespaced Kubernetes attachment.
KafkaRebalance workflow
Create dry-run proposals, inspect optimization results, and approve, refresh, stop, or discard supported resources.
Namespaced RBAC
Keep Kubernetes read and mutation permissions separate from Kafka ACLs and BetterKafka product roles.
Cruise Control evidence
Expose what Strimzi reports without inventing direct Cruise Control control or rollback guarantees.
From signal to answer.
Configure the bootstrap service and Kafka security through deployment-owned Helm values and Secrets.
Choose the namespace and service account permissions that BetterKafka may observe.
Create a KafkaRebalance dry run and inspect the operator-reported optimization status.
Require the appropriate product role, Kubernetes RBAC, cluster capability, reason, and mutation plan.
What teams need to know.
Does BetterKafka require Strimzi?
No. Strimzi support is an optional provider attachment; the core Kafka protocol features work independently.
Does BetterKafka call Cruise Control directly?
No. It follows the Strimzi KafkaRebalance custom-resource workflow.
Can it operate multiple Strimzi namespaces?
Each configured cluster can carry its own fixed provider attachment and namespace scope.
Does stopping a rebalance undo moved replicas?
No. Stopping interrupts active work; it is not a rollback of movement that already completed.
Try it on one cluster. Decide from evidence.
BetterKafka keeps the trial path as focused as the operator workflow.
