KafkaMirrorMaker2 rollingUpdate

[tsengph]

Hi,

I have a question about the MM2 rolling update. The MM2 rolling update will always create a new pod first instead of killing an old existing pod because the deployment has .spec.strategy.rollingUpdate.maxUnavailable=0.

I checked there is a template.podDisruptionBudget.maxUnavailable setting on mm2. But this setting cannot apply to rollingUpdate. For a rolling update, the Deployment's maxUnavailable will be in effect, even if the PodDisruptionBudget specifies a value. Reference https://stackoverflow.com/questions/58064904/kubernetes-specifying-maxunavailable-in-both-deployment-and-pdb

Do we have a way in which we can specify strategy.rollingUpdate.maxUnavailable on deployment object?

Thanks.

[scholzj]

You can change the deployment strategy in the custom resource: https://strimzi.io/docs/operators/latest/full/configuring.html#type-DeploymentTemplate-reference

[scholzj]

No, it should do it one by one. Delete one, create one, delete second, create another one etc.

[tsengph]

I did the test from my end and looks like the Recreate strategy terminates all the pods at the same time.
https://spot.io/resources/kubernetes-autoscaling/5-kubernetes-deployment-strategies-roll-out-like-the-pros/
Recreate—terminates all the pods and replaces them with the new version.

[scholzj]

Hmm, I think it didn't used to work like that, but it definitely does now. So you are right, sorry.

[tsengph]

No worries, thanks for your help! For .spec.strategy.rollingUpdate.maxUnavailable, Strimzi sets it to 0 and we can’t override the value. Should we consider it a bug?

[scholzj]

It would be a missing feature at best. But we are moving away from Deployment in general as it has some other things which are not perfect as well: https://github.com/strimzi/proposals/blob/main/045-Stable-identities-for-Kafka-Connect-worker-nodes.md ... so I do not think we are likely to add any new features for the Deplyoment based implementation.