Strimzi previews stable identities for Connect workers

A replacement pod can be healthy and still appear to the surrounding system under a new identity. For a distributed worker service, that change can create coordination work beyond the process restart itself. Strimzi 0.34.0, released March 20, adds an alpha feature gate for stable Kafka Connect and MirrorMaker 2 pod identities. It changes the Kubernetes resource managing those pods so their names and addresses survive rolling upgrades.

The feature addresses an operational property of the workers. It does not change what records Kafka retains or which external system a connector reads. Its purpose is to reduce avoidable disruption while the operator maintains the processes that perform that integration work.

I find Kafka's independent consumer positions useful because several systems can process the same retained history. Connect extends that arrangement into integrations with other systems, and maintaining its workers introduces another lifecycle. A more stable worker identity is useful when a routine rollout would otherwise create additional coordination changes.

The gate changes the managing resource

The version 0.34 deployment documentation names the gate StableConnectIdentities. When enabled, it uses StrimziPodSet resources for Kafka Connect and MirrorMaker 2 pods instead of Kubernetes Deployments. The documentation says the resulting stable names and addresses help minimize connector-task rebalances during rolling upgrades.

That is a specific mechanism and a bounded claim. The resource change preserves identity through the rollout. It does not guarantee that no rebalance can occur, because a running worker can still leave and return during maintenance. The benefit concerns one source of change that the operator can avoid while replacing a pod.

This distinction helps explain why stable naming is more than a cosmetic change. A pod name that only affects a dashboard label would have little bearing on coordination. Here, the documentation also identifies stable addresses and connects that stability to the worker system's behavior. Identity is part of the operational arrangement being managed.

Enablement belongs to the Cluster Operator

The feature is disabled by default in this release. Administrators opt in by setting STRIMZI_FEATURE_GATES in the Cluster Operator configuration. The following fragment illustrates the environment entry, which belongs in the operator container's environment list. It enables the named gate for the operator managing those resources.

env:
  - name: STRIMZI_FEATURE_GATES
    value: "+StableConnectIdentities"

This is operator configuration, not a connector property. Placing the value in a connector's configuration would address the wrong component. The Cluster Operator needs the setting because it chooses the Kubernetes resources used to maintain the worker pods.

The alpha status also describes what installing 0.34 does by itself. An existing deployment does not acquire this behavior merely because the release contains it. The operator must receive the opt-in. Separating package availability from gate activation makes the rollout state easier to explain when two environments use the same operator version.

The documentation requires disabling the gate before downgrading to Strimzi 0.33 or earlier. That requirement follows the resource-management transition. A downgrade must account for resources the earlier operator expects to manage. Recording the gate value alongside the operator version gives an operator a more complete description of that state.

Kafka version support changes independently

Strimzi's tagged changelog adds support for Kafka 3.4.0 and removes support for Kafka 3.2.x. This is a separate compatibility change from the identity gate. A deployment using an unsupported broker version has an upgrade concern even if it leaves the new gate disabled.

The release also adds digest support to the Helm chart. That concerns identification of the operator's image package, while stable worker identity concerns the names and addresses of managed pods. Both use the word identity in a broad discussion, but they apply to different objects and should be kept separate in configuration documentation.

The supported broker version and the feature-gate state consequently describe different dimensions of an installation. One determines which Kafka release the operator supports. The other determines how particular worker pods are managed. A useful change description names both when both are changing, instead of presenting the operator upgrade as a single undifferentiated action.

Stable pods do not establish connector correctness

Reducing coordination changes helps preserve continuity of work, but it does not establish the correctness of the connector's external interaction. A worker can have a stable address while a task fails for an unrelated reason. The identity feature should therefore be evaluated in terms of the rollout behavior it changes.

I prefer that narrow interpretation because it makes the expected outcome inspectable. A rolling upgrade should retain the documented pod names and addresses when the gate is enabled. The worker deployment can then avoid identity changes as an additional cause of task redistribution. Connector semantics remain the responsibility of the connector and the system it integrates.