How to upgrade Kafka with the Strimzi operator without breaking clients
Your Strimzi-managed Kafka cluster has to move to a newer Kafka 4.x release or a newer Strimzi release, and the work only stays safe if three layers line up: the Kubernetes version, the Strimzi operator version and the Kafka version set in the version field of the Kafka custom resource. Each layer constrains the next. Strimzi 1.3.0 supports Kafka 4.2.0, 4.2.1, 4.2.2, 4.3.0 and 4.3.1 and was tested on Kubernetes 1.32 to 1.37, so the operator release you choose decides which Kafka versions you can target and which Kubernetes versions you can run. Confirm that pairing in the Strimzi downloads page before you change anything, and confirm the Kubernetes version against your own distribution's support statement.
The rule that prevents most failures is that the operator is upgraded before Kafka. A newer operator can manage an older Kafka version, but an older operator will not reliably manage a Kafka version it does not support. Upgrade the operator first, let it reconcile the existing cluster, and only then change the Kafka version in the custom resource. Keep the Kafka change as a separate, reviewed commit so that a rollback has a clear target. For the Kafka side, the supported 4.x line today is 4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026), and the time-based release plan allows rolling upgrades from each of the last three releases to the latest version. If your cluster runs an older 4.x release, check the Kafka upgrade notes for that specific hop before you choose the target.
Client compatibility is the other half of the risk. Strimzi does not check your producers and consumers for you, so inventory client and Kafka Streams versions, Java runtimes (Java 17 for brokers and Connect, at least Java 11 for clients and Streams since Kafka 4.0) and any listener or authentication changes before you move the custom resource. Confirm with your application owners that each client is supported on the target version, and schedule the Kafka version change only after that inventory is complete.
Which Strimzi and Kafka versions change together
This table compares the version facts that decide a Strimzi upgrade: which Kafka releases the operator supports, what Kafka 4.x requires and which Kafka releases are still supported. Read each row as a question to answer before you change the operator or the Kafka version in the custom resource.
| Change | Impact on a Strimzi cluster | Action needed |
|---|---|---|
| Strimzi 1.3.0 Kafka support | Supports Kafka 4.2.0, 4.2.1, 4.2.2, 4.3.0 and 4.3.1, so the operator and Kafka versions must be paired from that list | Confirm the target Kafka version appears in the operator release's supported list before editing the custom resource |
| Strimzi 1.3.0 Kubernetes testing | Tested on Kubernetes 1.32 to 1.37, which limits the cluster versions the operator was validated against | Check your current and target Kubernetes minor versions against that range and plan any cluster upgrade first |
| Kafka 4.x requires KRaft | ZooKeeper-based clusters cannot move to Kafka 4.x, so older Strimzi-managed clusters must migrate to KRaft first | Confirm each cluster runs in KRaft mode and complete any migration before choosing a 4.x target |
| Kafka 4.x Java 17 for brokers and Connect | Brokers and Kafka Connect need Java 17 in the image the operator runs, while clients need at least Java 11 | Confirm the image and Connect plugins for the target release, and inventory client Java versions |
| Supported Kafka releases 4.3.1, 4.2.2 and 4.1.2 | These are the Kafka releases currently supported by the project, and earlier releases are archived | Prefer a target from this list and confirm the operator supports it |
| Rolling upgrade path | Rolling upgrades are supported from each release in the past year to the latest version, so larger jumps need intermediate steps | Confirm the source and target Kafka versions fall on a supported upgrade path before changing anything |
| Operator before Kafka | Upgrading the Strimzi operator first lets it manage the target Kafka version, and changing the Kafka version out of order can leave the cluster unmanaged | Upgrade the operator, then change the Kafka version in the custom resource, following the operator upgrade documentation |
| Release notes and upgrade docs | Each operator and Kafka target can add or remove behavior, so the pairing alone does not cover every change | Check the Strimzi release notes and upgrade documentation for each target version before starting |
What to back up and inventory before the first change
A Strimzi-managed Kafka upgrade touches the Kubernetes control plane, the Kafka data and the custom resources that describe the cluster. Each of the four cards below covers one of those layers, and together they give you a rollback path and a clear picture of what the upgrade will change.
Etcd and Kubernetes cluster backups
Kubernetes stores cluster state, including the Strimzi custom resources and their Secrets, in etcd. Take an etcd snapshot with etcdctl snapshot save before any change and confirm that you can restore it with etcdutl in a test environment. Store the snapshot outside the cluster and record the etcd and Kubernetes versions it came from. A snapshot you have never restored is not yet a backup. Confirm the exact Strimzi-specific backup steps in the Strimzi documentation before relying on them.
Kafka data and topic configuration inventory
Export the topic list, partition counts, replication factors, retention and compaction settings, and the configuration of each broker. Record the current Kafka version and the metadata state of the cluster so you can compare it after the rollout. Kafka data lives on persistent volumes, so confirm that the storage class and volume claims survive a pod restart. This inventory is also your baseline for checking that no topic changed during the upgrade.
Strimzi custom resources and deployment values
List every Kafka, KafkaNodePool, KafkaTopic, KafkaUser, KafkaConnect and operator resource in the namespace, and keep a copy of each one as it is applied today. If you install Strimzi with Helm, save the values.yaml used for the operator. If you manage it through GitOps, record the commit hash that the cluster is synced to. Without this record you cannot tell which change caused a problem or restore the previous configuration quickly.
Staging cluster on matching versions
Build a staging environment with the same Strimzi operator release, the same Kafka version and the same Kubernetes minor version as production. Run the upgrade there first, with representative topics, clients and load, and verify it before production. Check the Strimzi downloads page for the Kubernetes versions each operator release was tested on, and confirm that your production Kubernetes version is in that list. Staging that differs from production in versions tests a different upgrade.
Checking Kubernetes support before moving Strimzi or Kafka
Before you change the Strimzi operator or the Kafka version, confirm that your Kubernetes version sits inside the range Strimzi has tested. The Strimzi downloads page states that Strimzi 1.3.0 was tested on Kubernetes 1.32 to 1.37. If your cluster runs outside that range, treat the operator upgrade as a platform change first, and confirm with Strimzi which Kubernetes versions a given operator release supports before you schedule the work. Check the same page for the Kafka versions each operator release covers, because the Kubernetes check and the Kafka check are separate gates.
Kubernetes maintains only its three most recent minor releases. As of September 2026, these were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), according to the Kubernetes releases page. Kubernetes ships new minor releases about three times a year, so a cluster that was current at the start of a Kafka project can fall out of support during it. Record the end-of-life date for your cluster version next to your planned Strimzi and Kafka dates, and ask your distribution provider for its own support window, which may be shorter or longer than upstream. The Kubernetes releases page is the natural place to confirm the current list.
The Kubernetes version skew policy sets the order of control plane and node upgrades. kube-apiserver must be upgraded one minor version at a time, and kube-controller-manager, kube-scheduler and kubelets follow it. Kubelets may run up to three minor versions older than kube-apiserver, so a rolling node upgrade can proceed while the control plane is already newer. Confirm your distribution's conformance statement through the CNCF Certified Kubernetes program, which checks that a distribution supports the required APIs, and ask the vendor whether its upgrade tooling follows the skew rules. Then schedule the Kubernetes steps before the Strimzi operator upgrade, so the operator runs on a control plane version it has been tested against.
The upgrade sequence, with checks and rollback points
This sequence moves a Strimzi-managed Kafka cluster to a newer Kafka version in an order that keeps the operator, Kubernetes and brokers compatible at each stage. Each step ends with a check you can record, and each step states where you can still return to the previous state.
Confirm target versions in the Strimzi matrix
Start by checking the Strimzi downloads page for an operator release that lists your target Kafka version. For example, Strimzi 1.3.0 is listed as supporting Kafka 4.2.0, 4.2.1, 4.2.2, 4.3.0 and 4.3.1, and it was tested on Kubernetes 1.32 to 1.37. Record the current operator, Kafka and Kubernetes versions and the target pairing in your change request before anything changes. Rollback point: nothing has changed yet, so stopping here leaves the cluster untouched.
Upgrade Kubernetes in skew-compliant order
Skip this step if your Kubernetes version already falls in the tested range for the target operator. Otherwise, upgrade one minor version at a time, starting with kube-apiserver, then kube-controller-manager, kube-scheduler and kubelets. The Kubernetes version skew policy allows kubelets up to three minor versions behind kube-apiserver, so nodes may lag during a rolling change. Done when every control plane component and node reports the expected version and the cluster is healthy. Rollback point: the previous minor version is the fallback until the next minor step begins, and your distribution's documentation should confirm what downgrades it supports.
Upgrade the Strimzi operator before Kafka
Upgrade the operator to a release that supports both the current Kafka version and the target version while the brokers still run the old version. Apply the new operator's custom resource definitions and deployment through your normal change process. Done when the operator pod is ready, its logs show no reconciliation errors, and existing clusters reconcile without a broker restart. Rollback point: while Kafka is unchanged, you can reinstall the previous operator release if it still supports the current Kafka version. Confirm with the Strimzi documentation how custom resource definition changes are handled before you revert.
Verify operator and cluster health
Check that the Kafka resource reports a ready status, that all brokers and controllers are running, and that no reconciliation changes are pending. Confirm there are no offline partitions and no under-replicated partitions, and that producers and consumers behave as they did before the upgrade. Save a baseline with the topic count, partition health and consumer group lag so later steps have a reference point. Done when the baseline is recorded and matches the pre-upgrade state. Rollback point: if a check fails, resolve it on the current versions, since the Kafka version has not changed yet.
Change the Kafka version in the custom resource
Edit the Kafka custom resource to set the target Kafka version in the version field, and add any version-related settings that the Kafka upgrade notes require for your starting release. Apply the change through Git or your delivery pipeline so the diff can be reviewed and reverted in source control. The operator then begins a rolling restart of the brokers. Done when the Kafka resource reports the target version as current. Rollback limit: returning to the previous Kafka version is governed by the metadata and version finalization rules in the Kafka upgrade notes, so do not assume a simple revert is safe.
Watch the rolling restart and partition health
Watch each broker restart and confirm it rejoins the in-sync replicas before the next broker moves. Track offline and under-replicated partitions, controller status and consumer lag against the baseline from the health check. Kafka supports rolling upgrades from each of the last three releases to the latest version, so confirm your starting release falls within that range. Done when every broker runs the target version and partition health matches the baseline. Rollback point: the cluster stays on the new version during the roll, so if health stalls, pause and investigate rather than reverting mid-roll.
Run client tests and finalize the metadata version
Run smoke tests that produce and consume through each listener, exercise authentication and ACLs, and check Kafka Connect and Kafka Streams applications against the new version. Confirm that client libraries are supported by the new broker version. When results are acceptable, finalize the metadata version with kafka-features as the Kafka upgrade notes describe, since finalizing sets the limit on later rollback. Done when smoke tests pass and the finalization step is recorded. Rollback point: after finalization, returning to the previous release is restricted, so agree on the rollback window before you finalize.
What makes a Strimzi upgrade take longer
This table lists the factors that add work to a Strimzi-managed Kafka upgrade and what to inventory for each before planning the window. Read each row as a question to answer for your own environment, since the effort grows with the number of clusters, clients and Kubernetes distance from the target. Most schedule risk comes from client and Kubernetes version spread, not from the broker restart itself.
| Driver | Why it adds work | What to inventory |
|---|---|---|
| Number of Kafka clusters and brokers | Each cluster needs its own operator reconciliation, rolling restart and health checks, so work repeats per cluster. | Clusters, broker counts per node pool, and which environments each cluster serves. |
| Kafka Connect and MirrorMaker deployments | Connect workers and MirrorMaker 2 run on the Kafka version and must be moved and tested alongside brokers. | Connect clusters, connector plugins, MirrorMaker flows and their current image versions. |
| Java 17 requirement for Connect workers | Kafka 4.x requires Java 17 for Connect, so older worker images or custom base images need rebuilding. | Connect image base JDK, custom plugin builds and any third-party plugins that need recompiling. |
| Client version spread against Kafka 4.x | Clients that predate the Kafka 4.x compatibility range can fail after brokers move, forcing client work before or after the upgrade. | Client libraries and versions per application, including Streams and librdkafka-based services. |
| Customized Helm charts or GitOps overlays | Local patches to the operator, Kafka or Connect manifests must be reconciled with the new release or they can block reconciliation. | Helm values, Kustomize overlays, forked resources and the Git branches that hold them. |
| Kubernetes distance from the target skew window | If the cluster is far behind the Kubernetes version the operator supports, a platform upgrade may be needed first, and it has its own order and checks. | Current control plane and node versions, the operator's tested Kubernetes range and any node pools on older kubelets. |
| Multi-cluster or cross-site replication | Replicated topics and mirrored consumer offsets add coordination between sites and a second set of verification steps. | Replication flows, which side upgrades first, and the monitoring that shows lag during the change. |
| Size of retained data | Large retention and partition counts lengthen log recovery after each broker restart, which stretches the rolling restart. | Retention settings, total partitions per broker and typical recovery time observed in lower environments. |
How to test the upgrade and what rollback can and cannot undo
Test the full sequence in staging on an environment that matches production for every version that matters: the Strimzi operator release, the Kafka version in the custom resource, the Kubernetes version and the client libraries real applications use. Start by confirming on the Strimzi downloads page that the target operator release lists the Kafka version you plan to run. Then perform the operator upgrade, the Kafka version change and the rolling restart under a load profile close to production, with producers and consumers running throughout. Record the order of broker restarts, how long each broker takes to rejoin and any errors. A staging run that skips the operator step, or that uses a different Kubernetes minor version, tests a different upgrade from the one you will perform.
Check client compatibility before you change the Kafka version, because a healthy cluster can still break older clients. Work through the checks in the sibling page on checking client compatibility before upgrading to Kafka 4, and confirm that your starting version falls within the window Kafka supports for rolling upgrades: each of the last three releases to the latest version. During each broker restart, watch under-replicated partitions and consumer lag. Under-replicated partitions should return to zero before the next broker restarts, and lag that keeps growing after a restart is a reason to pause. Set these pause thresholds before the run, because the rolling restart continues unless someone or something stops it.
Decide the rollback window before the Kafka version changes. Reverting the operator release changes the component that manages the cluster, but it does not reverse a Kafka version change or a metadata change already applied to the brokers. Settle in advance how long the previous Kafka version remains available, who approves a rollback and which changes are one-way. Confirm the downgrade limits for the target release in the Kafka 4.3 upgrade notes and in the sibling page on finalizing and downgrading the Kafka metadata version, because finalizing the metadata version can close off a downgrade. Keep a tested backup of your custom resources and record which operator and Kafka versions each environment runs, so any rollback starts from a known state.
Questions buyers ask before upgrading Strimzi-managed Kafka
What drives the cost of upgrading Strimzi-managed Kafka, and who gets paid for what?
The cost depends on how many clusters, topics and client applications sit on the platform, how much testing your environment needs, and whether a Kubernetes upgrade is also required. Internal engineering time is the largest component for most teams. If you hire a partner, a fixed-scope engagement covers agreed deliverables, such as the upgrade plan, the staging rehearsal, the production change runbook and the verification evidence, and you pay for those in writing before work starts. Recurring costs come from operating the platform afterward, not from the upgrade itself. Ask any provider for a quote that separates planning, rehearsal, production execution and handover, and that states which items are optional. DeployOpen does not publish prices; a quote follows from the written scope.
How long does a Strimzi and Kafka upgrade take?
Duration is set by the number of clusters, the size of the Kafka cluster, the distance between your current and target versions, and how many approval gates your change process requires. The Kafka time-based release plan describes rolling upgrades from each of the last three releases to the latest version, so a supported path exists, but the calendar time depends on your own staging and change windows. Plan for at least one full rehearsal in a non-production environment before the production change. Confirm exact operator and Kafka version pairs with Strimzi's downloads page for your target release, because those pairs determine which steps are possible in one window.
What does our team need to provide for the upgrade?
You will need access to the Kubernetes clusters, the namespaces that hold Strimzi and Kafka, and the Git repositories or manifests that define the Kafka and KafkaNodePool resources. You also need agreed change windows, a non-production cluster that mirrors production settings, and named owners for each client application, since clients may need upgrades before or after the brokers move. Confirm who can approve rollback decisions during the window. Without these inputs, the upgrade plan cannot be tested realistically, and most delays come from missing access or unclear ownership rather than from the Kafka change itself.
Can our internal team run the Strimzi upgrade without a partner?
Yes, a team with Kubernetes operations experience and Kafka administration skills can run the upgrade internally. The work requires reading the Strimzi upgrade documentation for your target release, checking Kubernetes support, rehearsing the change in staging, and verifying broker health, partition leadership and client behavior after each step. A partner adds value when the internal team lacks recent Kafka or Kubernetes upgrade experience, when several clusters must change on one schedule, or when auditors expect documented evidence. Whichever path you choose, assign a single owner for the change and a rollback decision maker before the window opens.
Which Kafka versions does a given Strimzi release support, and how do I confirm them?
Each Strimzi release lists the Kafka versions it supports. For example, Strimzi 1.3.0 supports Kafka 4.2.0, 4.2.1, 4.2.2, 4.3.0 and 4.3.1. Confirm the list for your exact target release on the Strimzi downloads page before you change any version, and check that the Kafka version you plan to run is in that list. Also check the Apache Kafka downloads page for which Kafka releases are currently supported upstream, since an operator may still accept a Kafka version that the Kafka project no longer maintains. Record the pair you tested in your change record.
What happens if our Kubernetes version must be upgraded first?
If your Kubernetes version is not supported by the Strimzi release you need, you must upgrade Kubernetes before or alongside the operator. Strimzi 1.3.0 was tested on Kubernetes 1.32 to 1.37, so confirm your current and target versions against that tested range. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, and kubelets may lag the API server by up to three minor versions. Kubernetes upgrades affect the control plane, nodes and etcd, so schedule them as separate change windows with their own backups and rollback plan. Kubernetes minor releases also reach end of life on a published schedule, which limits how long you can defer the work.
Does the Strimzi operator upgrade interrupt running clients?
It can, if the rollout restarts brokers or changes listeners or authentication. Upgrade the operator first, confirm it reconciles existing resources without restarting brokers unexpectedly, then change the Kafka version in the custom resource and let the operator roll brokers one at a time. Check the Strimzi upgrade notes for your versions to see which changes trigger restarts. Monitor under-replicated partitions and producer errors during each broker restart, and confirm that topic replication factors and minimum in-sync replicas allow one broker to be unavailable at a time. Confirm these behaviors with Strimzi documentation for your release before the window.
How DeployOpen scopes, delivers and supports the upgrade
DeployOpen approaches a Strimzi-managed Kafka upgrade as a written, fixed-scope change to your own Kubernetes environment. We start by confirming the versions in play, then build and rehearse the sequence in a non-production copy before any production change.
How we scope
- Inventory the current Strimzi operator, Kafka version, Kubernetes version and every custom resource that references them.
- Confirm the target operator release and the Kafka versions it supports, using the Strimzi downloads page at the time of work.
- Record which Kubernetes version each cluster runs and whether your planned path stays within supported version skew.
How we build
- Write the upgrade runbook in order: operator first, then the Kafka version field in the custom resource, then clients.
- Rehearse the full sequence on a staging cluster that mirrors your topic counts, listeners and authentication settings.
- Test rollback points, pausing the rollout and the conditions under which you would stop, documented before production starts.
How we hand over
- Deliver the written runbook, pre-upgrade checklist, verification steps and the recorded results of the staging rehearsal.
- Document the final versions, custom resource changes and any manifest edits so your team can repeat the process.
- Walk your platform and operations engineers through the run and agree who owns each step after the engagement closes.
How we support
- Ongoing support, upgrade planning and continuous testing are available as a retainer, agreed in writing alongside the scope.
- Ask for a quote built from the written scope, covering your cluster count, environments and whether staging rehearsal is included.
- Confirm with your team which upgrades stay in-house, so the retainer covers only the work you cannot run yourselves.
