-
Hello, We recently upgraded Strimzi and Kafka, and noticed that the unidirectional Topic Operator (UTO) is now enabled by default. As a result, any direct interactions with Kafka topics are being reverted to their previous state by the Topic Operator. (Previously, we were using the bidirectional mode.) New topics created directly in Kafka are no longer reflected in Kubernetes, which is expected behavior in this mode. However, this brings up a few questions: Currently, we have a mixed configuration experience—topic replicas, retention settings, and partitions configured directly via the Kafka API are working fine for newly created topics. But for topics that existed before UTO was enabled, changes continue to be overridden by the Topic Operator, as they're still defined in the KafkaTopic CRDs. Given that we manage topics directly via the Kafka API and not through Kubernetes CRDs, is there any real benefit to keeping the Topic Operator running in the cluster? Can we safely disable the Topic Operator without affecting the overall functionality or management of Kafka within Strimzi? As we plan to migrate to Kraft mode (removing ZooKeeper), are there any dependencies or considerations related to the Topic Operator in that setup? Thank you! |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
The Topic Operator is there to provide a Kube/cloud-native approach to handle Kafka topics. It's not mandatory to be used. If your use case is based on using Kafka Admin API to manage topics, it's totally fine. You can just avoid to deploy the Topic Operator.
As said before, the Topic Operator just provide a convinient way of handling topics with CRs (i.e. in a GitOps oriented environment if you like). Disabling it doesn't effect the topics management (via Admin API) in any way.
There is no strict relation between having the Topic Operator deployed or not within a cluster that could be ZooKeeper or KRaft. I would also leave @fvaleri adding more that could come to his mind. |
Beta Was this translation helpful? Give feedback.
-
This is still compatible with UTO. You can "unmanage" one or more KafkaTopic resources through a simple annotation and the operator will ignore them. After their status is updated to "Unmanaged", you can safely delete these KafkaTopic resources in Kube without this causing a topic deletion in Kafka. |
Beta Was this translation helpful? Give feedback.
-
Thank you both! |
Beta Was this translation helpful? Give feedback.
The Topic Operator is there to provide a Kube/cloud-native approach to handle Kafka topics. It's not mandatory to be used. If your use case is based on using Kafka Admin API to manage topics, it's totally fine. You can just avoid to deploy the Topic Operator.
As said before, the Topic Operator just provide a convinient way of handling topics with CRs (i.e. in a GitOps oriented environment if you li…