Strimzi removes KafkaConnectS2I while preserving Connect storage continuity

Replacing a connector runtime should not accidentally create a new account of its progress. Strimzi 0.25.0, released August 11, removes the KafkaConnectS2I resource and its operator support. The replacement is the build workflow on KafkaConnect. The migration needs to preserve Connect's identity and storage configuration while changing how the runtime image is supplied.

The migration guide linked by the release describes downtime between deleting the old deployment and successfully starting its replacement. Connectors stop processing during that interval and should resume from where they stopped after the changeover. The procedure is therefore a planned replacement, rather than a promise of an uninterrupted rolling transition.

I regard the retained progress as the important part. Kafka makes input history available independently of the process reading it. A deployment replacement needs to retain the connection between that history and the connector's recorded position, instead of confusing a new container image with a new logical connector system.

Image construction moves into the standard resource

The guide explains that KafkaConnect now has build properties for constructing an image with the connector plugins needed by the deployment. The migration creates a new KafkaConnect resource to replace the old KafkaConnectS2I object. This consolidates the description of the worker runtime under the standard resource type.

The guide also permits manually building an image and referring to it through spec.image. That is a useful distinction. Removing the separate S2I resource does not mean every installation must use the operator to perform its image build. The replacement resource can describe either the build or the already-built artifact.

The Connect runtime still needs the connector libraries. Changing the Kubernetes resource kind cannot supply a plugin that is absent from its image. The new build configuration is where the required connectors and additional libraries are declared when using the automated route.

This makes artifact identity part of understanding the migration. The replacement worker should contain the connector implementations expected by the saved configuration. Preserving storage topics while supplying an incompatible runtime would preserve the old instructions without necessarily preserving the software capable of executing them.

Worker identity and stored configuration continue

The guide requires using the same resource name. It also calls out group.id, offset.storage.topic, config.storage.topic and status.storage.topic in spec.config. If they were set explicitly, the replacement should retain the values. If defaults were used, it says to leave those properties unspecified in the new resource too.

Those fields identify different parts of Connect's existing state. The migration does not ask the operator to discard them and create an unrelated configuration history. It relies on the new worker deployment reaching the stored connector information that already exists.

The procedure specifically says not to delete other resources when removing the old S2I deployment. It then waits for the old pods and deployment to disappear before creating the replacement. That sequencing prevents interpreting resource removal as permission to erase the surrounding state needed for recovery.

The guide says connectors recover through Kafka Connect storage and should not require manual recreation, including connectors managed through the REST API. This is the intended continuity mechanism. A saved definition and its progress remain meaningful across the change in deployment resource when the replacement reaches the same state.

The change also removes another direct ZooKeeper dependency

The 0.25 changelog says the User Operator now manages SCRAM-SHA-512 credentials through the Kafka Admin API. Its operations connect directly to Kafka instead of ZooKeeper. The corresponding ZooKeeper connection and session-timeout environment variables are removed from that operator configuration.

This is separate from the Connect resource removal, but it follows a similar direction of reducing special integration paths. The runtime being managed and the administrative interface being used need to be identified precisely. An operator no longer reading a ZooKeeper setting is a configuration contract change, even if the Kafka user it manages retains the same name.

The release adds an environment-variable configuration provider and permits a custom SCRAM password through a Secret reference in KafkaUser. These changes concern how values enter configuration and credential management. They do not replace the need to preserve the Connect storage identifiers during its migration.

Scala also moves from 2.12 to 2.13 in this release. The accompanying Open Policy Agent authorizer update changes its input format, another compatibility requirement the changelog identifies separately from the Connect migration.

I find the explicit migration contract more useful than describing this as a resource rename. The old deployment is removed, another runtime is built or selected, and existing connector state is recovered through retained storage. Strimzi 0.25 removes the S2I-specific path while keeping those separate identities visible in the supported replacement procedure.