Strimzi 1.0.0: CRD Versioning, Conversion, and GitOps Operations
A technical overview of the Strimzi 1.0.0 CRD migration path, including CRD versioning, conversion tooling, storageVersion updates, and operational considerations for ArgoCD-managed GitOps Kubernetes environments.
.png)
On this page
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 old 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.
- Have a separate ArgoCD Application managing only Strimzi CRDs using version 0.51.0 (or another version very close to 1.0.0).
- A merge request is standing by that actually changes the storage version to v1 in all our CRDs.
- 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.
- Run the conversion tool for CRDs. This is the part where the ArgoCD Application will get out of sync.
- 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.
- 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.
Answers to your questions about Axual’s All-in-one Kafka Platform
Are you curious about our All-in-one Kafka platform? Dive into our FAQs
for all the details you need, and find the answers to your burning questions.
Related blogs
.png)
This blog explores why many European organizations and policymakers remain skeptical of AWS’s “sovereign” cloud initiative. From concerns around US jurisdiction and the CLOUD Act to questions about operational independence, data governance, and true digital sovereignty, we break down the key reasons behind Europe’s hesitation. The article also examines the broader push for European cloud alternatives and what this means for enterprises navigating compliance, security, and infrastructure strategy.
The Axual 2026.1 release builds on the improvements in governance, observability, and self-service introduced in 2025.4, and takes things a step further. This release adds audit event coverage across platform resources, giving teams more visibility and control over what’s happening in the platform. We’ve also extended OAuth support to all data plane components, making security more consistent end to end. On top of that, updates to Connector management and the Overview Graph make the platform easier to use and give clearer insight into platform activity.
In this blog, we explore how the Model Context Protocol (MCP) enables AI applications to move beyond text generation and interact with systems like Kafka through structured actions. We will look at how natural language intent can be translated into real operations such as managing topics, schemas, and streaming applications, while also touching on governance, security, and the role of declarative approaches like KSML.