1 kafka cluster but 2 different statefulset

[pankajagarwal]

Is it possible to deploy a single kafka cluster 2 different statefulsets with strimzi operator ?

Basically i want my deployment to be distributed across different AWS AZ's and PVC (EBS) to be scoped to the same AZ always.

In a nutshell this is what we are trying to do:

Scenario # 1
sts-A goes to AZ1
sts-B goes to AZ2

both sts-A and sts-B are part of same kafka cluster and we can use AZ1 and AZ2 for rack awareness.

Scenario # 2
sts-A-pod0 and sts-A-pod2 goes to AZ1
sts-A-pod1 and sts-A-pod3 goes to AZ2

Please suggest

[scholzj]

Distributing the brokers over multiple AZs does not require multiple StatefulSets. You can do it without it:

• Enable the rack awareness in the Kafka CR
• Configure pod anti-affinity / topology spread constraints to spread the pods across the AZs.

So you can easily do it with a single StatefulSet.

[pankajagarwal]

How will i ensure the same statefulset is deployed in same AZ for ebs based PVC to work specially with restarts ?

[scholzj]

I'm not sure I follow what exactly you mean. So, what is it you want? You want the brokers split across the AZs? Or you want all brokers in a single AZ? Both can be achieved with the right settings without too many StatefulSets.

[pankajagarwal]

basically we are trying to keep specific broker to a specific AZ as we use EBS backed persistent volumes. volumes are tied to specific AZ and can not be accessed outside of AZ. In a nutshell we are trying to map broker-0 to AZ1, broker-1 to AZ2 via some config here. So in case of restarts the same broker lands in same AZ and we don't loose any data as the data is persistent in the EBS volume available in that AZ and kubernetes csi driver takes care of making the volume available to the node in the same AZ.

[scholzj]

But normally you don't have to care about this. If you have properly configured Kubernetes cluster, it understands the affinity of the storage and where the broker should run. It creates the PVCs across the AZs and schedules the pods to run in the same AZ where the storage is. You might not have a guarantee that broker 0 will end up in AZ1 before you deploy it. But it does not really matter where do they land as the ID is just a number.

If you want to control which exact broker runs in which AZ, you have two options:

• Pre-create the PVCs in the AZs as you want them and they will pull the broker into their AZ
• Use per-AZ storage classes and the per-volume override to configure storage class per broker (check the docs for more details)

But essentially, you just make your own life more complicated then needed.

[pankajagarwal]

@scholzj that's a very good and valid point. Yeah, it will be some code but as we use Helm, i think it can be baked in. thanks for the pointer.