Question regarding strimzi upgrade
I don't sure this is the right place to ask, I hope it is. I need
help with strimzi upgrade.
The situation is: there is a strimzi 0.13.0 (and kafka 2.3.0)
installed in a kubernetes cluster, which was recently upgraded
from 1.15.3 to 1.22.8.
Is it possible to properly upgrade strimzi and kafka to the
latest supported versions in this situation from 0.13.0 to 0.32.0
(kafka from 2.3.0 to 3.*)? The most important thing is to not
disrupt kafka data.
I read that firstly strimzi should be upgraded to 0.22.0. But couldn't do it, because CRDs from this version use old kubernetes api v1beta1, and it is not supported in 1.22.8 now.If this is not the right place, please could you advice where I could get advice with this problem.
toggle quoted message Show quoted text
Unfortunately, as you noted, Strimzi 0.13 does not support Kubernetes 1.22 because Strimzi 0.13 was written based on the apiextensions v1beta1 API. But Kube 1.22 and newer supports only apiextensions v1 API. The old APIs used by the older Stirmzi versions are not compatible with the new versions because Kubernetes changed what is allowed in the CRDs schemas.
The proper upgrade path indeed was to upgrade to Strimzi 0.22, do the CRD conversion, then upgrade to Strimzi 0.23 (or newer), and only then upgrade to Kubernetes 1.22 (or newer). But the CRD conversion will not work for you if you are already on Kubernetes 1.22 and are using some modified CRDs (since the original would not work there).
To be honest, there is no guide for how to deal with this situation as it was supposed to be upgraded way earlier and there is no tested approach. There were several Slack and GitHub discussion where you can check for the possible solutions. f I remember correctly, one of them was to delete the operator and do "non-cascading" deletion of the CRs & CRDs, install a new version of the operator and the new CRDs and create a new CRs to match the old ones but using the new versions to get the new operator to take over the old cluster. Another I think was to create your own CRDs with the new API versions without a schemas, upgrade Strimzi operator with it and only then install the actual new Strimzi CRDs. But you should definitely test them first in some test cluster. Another option is of course to downgrade the Kubernetes cluster, install the original old CRDs and follow the proper and tested upgrade procedure with the CRD conversion.
Thanks & Regards
On Wed, Mar 15, 2023 at 12:39 AM Dmytro Kondratskyi <kondratskyidmytro@...> wrote:
|1 - 2 of 2|