Strimzi packages Kafka 3.5.1 for broker upgrades

A Kafka security patch reaches a Kubernetes deployment through more than an upstream release announcement. The operator needs an image containing the new binaries and a mapping that selects that image for the requested broker version. Strimzi 0.36.1, released on August 1, adds support for Kafka 3.5.1. The practical change is that an operator-managed cluster can request that patch through the same declarative version setting used for other broker upgrades.

The release also repairs Grafana dashboards in the Helm chart and issues with two-node ZooKeeper deployments. Those fixes affect the operator distribution around Kafka. They do not change the ordering guarantees of a topic or the meaning of a consumer offset. The useful angle in this small release is how several independently versioned pieces become one deployable system.

I think about Kafka primarily as retained history that several systems can consume independently. That makes the broker's exact executable dependencies relevant to the reliability of the history. An operator version is useful evidence about available upgrades, but it does not by itself tell me which broker binaries a particular cluster has selected.

The image follows the requested version

The 0.36.1 deployment documentation explains the relationship between Kafka.spec.kafka.version and the operator's STRIMZI_KAFKA_IMAGES environment variable. The environment variable maps supported Kafka versions to container images. When the custom resource requests a version without an explicit image override, the operator uses the mapped image. The release's image list includes Kafka 3.5.1 alongside other supported versions.

This distinction permits a cluster specification to describe its intended Kafka version without embedding the full image selection mechanism in every resource. The operator distribution supplies that mapping. Supporting a newly released Kafka patch therefore involves shipping the corresponding image and teaching the operator which image matches the version. The short entry in the tagged changelog represents that packaging work.

An explicit spec.kafka.image changes the relationship. The documentation says that it overrides the default image for the requested version, and warns that the operator cannot validate whether the image actually contains the expected broker version. A resource can consequently declare the desired version while still naming an old custom image. For installations that build their own images, the custom build and the declarative version must agree.

The difference is especially relevant to the Snappy vulnerability disclosed in July. Kafka 3.5.1's tagged dependency declaration selects snappy-java 1.1.10.1. The Kafka security advisory identifies that library version as a fix for CVE-2023-34455. Selecting the supported broker patch gives an operator-managed installation a packaged route to that dependency, provided its image configuration actually selects the corresponding binaries.

Broker binaries and protocol settings

Strimzi documents the broker upgrade as a rolling change. Updating the requested Kafka version causes brokers to start with the new binaries in turn. During that process, a cluster contains brokers running different binary versions. The inter-broker protocol setting controls the protocol they use while they coexist. A binary version and a protocol version describe different parts of the upgrade.

The documentation illustrates a larger change from Kafka 3.4.0 to 3.5.1. It first leaves inter.broker.protocol.version at 3.4 while changing the binary version. After the broker rollout completes, the protocol setting can advance. That example should not be misread as a demand to change the protocol for every patch update. The relevant question is whether the upgrade crosses a protocol version, independently of whether the broker image changes.

This separation also explains the documented downgrade warning. A protocol change can affect persistent metadata that an older broker does not understand. The operator cannot reduce that compatibility question to whether an earlier container image still exists. The deployment procedure makes the binary rollout and the later protocol transition distinct operations so that their consequences remain visible.

I prefer that explicit distinction because a stream's retention makes upgrades a compatibility problem over existing state. Consumer replay assumes the stored history remains interpretable. Treating the image tag as the complete upgrade plan would leave out the settings that govern how brokers communicate and persist internal information.

The operator still has its own compatibility boundary

Strimzi 0.36.1 retains the Kubernetes minimum introduced in 0.36.0. The release requires Kubernetes 1.21 or newer, and direct upgrades from Strimzi 0.22 or earlier are unsupported. These requirements apply even when the immediate motivation is a broker patch. The installed operator's starting version and the Kubernetes version determine whether the operator update itself follows a supported route.

The dashboard and ZooKeeper repairs belong in that same assessment of the surrounding deployment. The release notes identify their scope without claiming a change to Kafka's storage model. A cluster already on the 0.36 line gets a narrow operator patch and access to the newer broker image. A cluster coming from a much older operator must account for the intervening compatibility requirements before it can use that image mapping through the new release.

The resulting deployment description has two concrete parts. The operator release establishes which Kafka images it supports, and each Kafka resource selects the broker version it intends to run. Keeping those parts aligned makes the security dependency in Kafka 3.5.1 an actual broker change instead of an available image that no cluster has requested.