Strimzi 0.28 adds an experimental controller for Pod sets

A Kafka operator manages a distributed system through another distributed system's API. The resource used to describe its Pods determines what the operator can express and reconcile. Strimzi 0.28 introduces StrimziPodSet, with support disabled by default behind UseStrimziPodSets. The February 15 release makes the new controller an explicit experimental choice.

The design is interesting because it puts Pod definitions directly into a Strimzi-owned resource. The operator can observe that resource and reconcile the Pods associated with it. This is infrastructure around Kafka's log, not a change to how an application chooses its partition key or advances a consumer position.

I value Kafka's durable history and independent consumer positions, but those properties depend on a maintained broker environment. A change in the operator's Pod management deserves attention because it affects the machinery responsible for keeping that environment present.

The resource contains concrete Pod definitions

The 0.28 resource specification has two required properties, selector and pods. Labels in the selector identify the managed Pods. The pods property contains their definitions as a list.

The selector supports matchLabels only. The specification says matchExpressions is ignored. That limitation matters for anyone reading the resource as a general Kubernetes label-query interface. A familiar property name does not imply support for every matching mechanism available elsewhere in Kubernetes.

An explicit list also changes what the resource describes. It contains the desired Pods themselves, giving Strimzi a concrete representation to reconcile. The significance is the operator's ability to reason about those definitions through its own controller. The release notes do not claim that merely installing the CRD changes every existing deployment to use it.

A dedicated controller watches resources and Pods

The controller implementation creates informers for Pod sets and Pods. Additions and changes enqueue reconciliation work. Pod deletion also enqueues work associated with the owning set. The controller therefore responds to changes in both the desired resource and the objects that realize it.

The code checks whether a set belongs to a Kafka cluster selected by that operator instance. This matters when an operator watches a particular namespace or uses custom-resource selector labels. Seeing a resource through an informer is not sufficient reason to manage it without checking its ownership and scope.

Reconciliation is queued by Pod set rather than by an individual Pod. That makes the set the unit through which the controller processes the observed change. The distinction provides a concrete explanation of what the new resource adds beyond another name in the API catalog.

The feature gate keeps adoption explicit

The feature-gate implementation gives UseStrimziPodSets a false default. Its configuration accepts named gates with plus or minus prefixes. Unknown gates and duplicate configuration of a gate cause configuration errors. This rejects an ambiguous operator configuration before it can be mistaken for a successful selection. The exact gate name is consequently relevant when translating an intended experiment into the configuration consumed by this release.

That behavior makes the experimental selection identifiable. An installation of version 0.28 and an installation exercising the new controller are different states. A support report needs the gate configuration to distinguish them. The release's default preserves that distinction instead of silently opting every deployment into the new path.

My preference is to treat that selection as part of the operator configuration. A declarative Kafka resource alone cannot identify every implementation choice made by the controller responsible for it. Recording the gate state makes an observation about Pod behavior more reproducible.

Kafka support and disk balancing also advance

Strimzi adds support for Kafka 3.1.0 and removes support for 2.8.0 and 2.8.1 in this release. That supported-version change is independent of opting into Pod sets. An upgrade procedure therefore needs to account for the Kafka version in use even when the new gate stays disabled.

The release also adds intra-broker disk balancing through Cruise Control. Its scope is movement within a broker's disks, which is a different placement question from distributing work between broker machines. The release summary identifies the capability without changing the application's partitioning model.

OAuth integration gains connection and read timeouts, both defaulting to 60 seconds where there previously was no timeout. That is another explicit operational boundary around a dependency outside Kafka itself. Alongside the new controller, these changes show the operator addressing the lifecycle of the environment around the log, with Pod-set adoption remaining a separately configured experiment.