Strimzi 1.0.0: CRD Versioning, Conversion, and GitOps Operations

Managing operators within production Kubernetes environments involves much more than simply rolling out a new release. For those leveraging GitOps-driven platforms, handling CRD and API updates necessitates a high level of coordination between the operator, the live cluster state, and the deployment tooling. This complexity makes major milestones, such as the Strimzi 1.0 release, particularly significant from an operational standpoint.

CustomResourceDefinitions (CRDs) combined with ArgoCD in Kubernetes can be tricky, especially when adding a new apiVersion. The owner and creator of CRDs has to take several things into account while building an upgrade path for their users.

A few things that come up when planning a v1 apiVersion.

• At which point is the new apiVersion actually introduced?
• Are old apiVersions going to be removed, and if so, when?
• Is there any help provided when moving from an older version to a newer version?
• Will there be a conversion strategy using a webhook, or simply default to none?

Strimzi has recently released their version 1.0.0 of the Strimzi Operator for Kafka. And with this release, an updated set of CRDs in which all Fold versions have been removed with the recently introduced v1 remaining.

Let's list some characteristics of the path to Strimzi CRDs v1.

v1 was introduced several releases before 1.0.0, not marked as the storage version yet of course. This allows users to already configure their resources using the v1 schema.

With the 1.0.0 release, the new set of CRDs actually does two things: set storage=true for v1 and remove all old apiVersions at the same time.

A conversion tool was shipped with the prior releases that can be used to update several Custom Resources as well as the CRDs. One of its most important features is the modification of currently existing CRDs in your Kubernetes cluster. It sets storage=true for v1, performs a no-op update of existing CRs so they are persisted with apiVersion v1 in etcd, and finally removes the old apiVersions from the storedVersions array in the CRD status subresource.

Now combine what Strimzi provides with a GitOps operations environment using ArgoCD, where everything is managed, including CRDs. It is quite clear that ArgoCD will start complaining about things being out of sync the moment that the Strimzi conversion tool has run.

Upgrade Plan for Strimzi 1.0.0

All things considered, the following is a short plan we have at Axual to properly upgrade our Strimzi Operator to 1.0.0.

1. Have a separate ArgoCD Application managing only Strimzi CRDs using version 0.51.0 (or another version very close to 1.0.0).
2. A merge request is standing by that actually changes the storage version to v1 in all our CRDs.
3. Make sure that the CRs are created using v1, ensuring the resources are written with apiVersion v1. The conversion tool can actually help here as well.
4. Run the conversion tool for CRDs. This is the part where the ArgoCD Application will get out of sync.
5. Merge the open MR that alters the storage version. The result of this will be that your ArgoCD Application will get back in sync, with the changes of the MR reflecting the changes made by the conversion tool.
6. Do the actual upgrade to Strimzi 1.0.0 including the CRDs.

Conclusion: Strimzi CRDs v1

So, this is our plan to upgrade the Strimzi deployment to version 1.0.0. Curious to hear other approaches!

Questions, feedback, or interested in discussing Strimzi operations and upgrades in Kubernetes environments?

Connect with our Strimzi experts at Axual.

‍