We are currently targeting 3 m5.2xlarge nodes for the deployment of all cluster-wide components. Once we switch to strimzi podsets there will be additional strimzi instances running that should push cpu demand beyond what is currently available.

Options to consider include:

For enterprise kafka in particular the resource utilization of strimzi and the ingresscontrollers may not well balanced to the number of instances running. For example it would make sense to greatly reduce the cpu request of strimzi for enterprise - or in general revisit how necessary 3 cpu request / limit is in light improvements that have been made to that operator.

medgar@redhat.com had pointed out in an earlier discussion that we can also make the FSO responsible for scaling up / down the strimzi operator deployments (or even setting the resources) based upon how many managedkafkas, if any, reference the given strimzi version.

We can size the kas default and az specific ingresscontroller routers differently - the default does not need the same cpu resources as the az specific, and we may actually need even more memory on the az specific now that we are only running 1 instance by default.

Based upon all of this we can also consider using a different node type for the default pool, such as 3 x c5.2xlarge, which would offer some savings over m5.2xlarge for managed instances.

cc rhn-engineering-rareddy - I logged this as a single enhancement, but it could be viewed as an epic if you want.