Supported pattern

[Sjoerd97]

Dear all,

We would like to deploy a strimzi cluster to our kubernetes cluster.
We have the following pattern in mind and are running into issues while deploying. We would like to know if the pattern is supported from the getgo.

We would like to deploy the cluster and entity operator and the kafka cluster in our infra namespace and deploy all kafka topics in a seperate namespaces.

The reasoning behind this comes from our test cluster. We have a lot of namespaces for testing purposes and would like to reduce the amount of running pods to a minimum.

Whenever I set this up using helm charts I noticed that the cluster operator fails to start as the default clusterrole doesnt allow the service account to create all necessary roles/rolebindings/kafkatopics etc in the watched namespace. Whenever I add these permissions, everything seems to work fine.

I am wondering if this pattern is supported at all?
And if there is a way around having to manually add permissions to the cluster role

[scholzj]

To be honest, you might need to provide more details on what exactly is the pattern you are asking about, how do you install things and what are the errors you get.

We would like to deploy the cluster and entity operator and the kafka cluster in our infra namespace and deploy all kafka topics in a seperate namespaces.

This is not really supported. What you can do is:

• Deploy the Kafka cluster into a namespace A
• And configure the Topic Operator to watch for KafkaTopic resources in a different namespace B.

That would be supported. However, please keep in mind that it is namespace B in singular. Neither the Topic nor the User operator can currently watch multiple namespaces.

Assuming watching a single different namespace for Topics is the pattern, I do not think the Cluster Operator Helm Chart has any special support for it. If you instal the Cluster Operator to watch the whole cluster or mutiple namespace including the one with the topics, I think it should have the RBAC rights needed. However, if you installed it to watch only the namespace A and then try to deploy the Kafka cluster with Topic Operator watching namespace B, you would likely need to give it additional RBAC rights manually. That is mostly by design as the Cluster Operator Helm is not really designed to handle every single niche use-case.

[Sjoerd97]

Thanks for the quick response!

To clarify the pattern that we were asking about a little more:
We would have liked to deploy the cluster operator, the entity operator and the cluster in our Infra namespace. Ideally we would have like create kafka topics in each of our test-1, test-2, etc.. namespaces, which the single entity operator could manage.

But from this comment of you I get the understanding that that is not supported at all.

Neither the Topic nor the User operator can currently watch multiple namespaces.

The reasoning behind this is that our test cluster contains a lot of separate namespace and we would not have liked to deploy all strimzi kafka resources in each seperate test-x namespace to reduce strain on the hardware. Beside we require the topic names to be identical to what they currently are with our Bitnami Kafka cluster for migration purposes.

In case this is indeed not supported we came up with the following approach, which seem to be supported when looking at all the documentation:

The advantage here would be that we don't need to create a separate cluster operator in each test-x namespace reducing a bit of strain on the hardware.

My question for now is, if indeed this approach is supported

[scholzj]

To clarify the pattern that we were asking about a little more:
We would have liked to deploy the cluster operator, the entity operator and the cluster in our Infra namespace. Ideally we would have like create kafka topics in each of our test-1, test-2, etc.. namespaces, which the single entity operator could manage.

Right, this approach is not supported currently. There are issues opened for it: #1206 and #5895. But to be honest, they are unsolved for a long time and I'm not aware of anyone working on them. So, I would not wait for that. It is not completely simple with things such as ensuring the uniqueness etc.

Some alternative patterns that I know some users are using:

• Various Gitops approaches where the topics and users are in single namespace, but users are self-managing them through Git rather than through Kubernetes directly. That way you can decouple the self-managed part form having the resources live in a single namespace
• Some users also have the resources in varous namespaces and then use various tools to collect them and copy them to the central namespace (+ copy back things such as credentials etc.)

Obviously, these are not exactly the same as what the multi-namespace Topic and User Operator would do. So I'm just sharing them as a potential inspiration.

---

The pattern with a single Cluster Operator installation and multiple Kafka clusters in different namespaces should work fine and is supported. Please keep in mind that with a lot of namespaces, the cluster-wide Cluster Operator installation is much more efficient than the operator wtaching multiple selected namespaces. (Because the operator can use a single watch when watching the whole cluster. But with multiple specific namespaces, it needs to have a watch per namespace.)

[Sjoerd97]

Thanks again for the quick and elaborate answer!
For now we will keep things simple and deploy the sketch we drew up

P.S. Unfortunately I have little time outside of working hours, otherwise I might have been tempted to contribute to the open issues ;)