Strimzi 1.2 prevents new assignments during broker removal

A broker scheduled for removal can still receive new partitions while its existing replicas move elsewhere. Kafka's cordoning mechanism addresses that placement race, and Strimzi 1.2.0, released on August 20, integrates it into automatic scale-down rebalancing for Kafka 4.3 and later.

The distinction matters because a Kubernetes replica count does not describe where Kafka's partition replicas live. Removing a pod and moving the data it owns are different operations. Strimzi's integration lets the broker-placement restriction participate in the operator's existing removal workflow.

I value Kafka's durable history and the independence of its consumers. That history also makes a broker a stateful member of a replicated system, with responsibilities that outlast a pod scheduling decision. This release makes one part of that relationship explicit during scaling.

Auto-rebalancing has a defined trigger

The versioned deployment documentation defines a scaling event as a change to spec.replicas in an existing KafkaNodePool. With auto-rebalancing enabled, partitions move onto added brokers or off brokers scheduled for removal.

The trigger has an important boundary. Creating a new KafkaNodePool or deleting an existing one does not trigger the same auto-rebalancing mechanism. Those operations require a manually initiated KafkaRebalance using the appropriate add-brokers or remove-brokers mode. Similar-looking Kubernetes changes therefore have different operator workflows.

Auto-rebalancing also requires Cruise Control to be deployed with Kafka. Each scaling mode can use a template or the default Cruise Control rebalancing configuration. If a mode has no autoRebalance configuration, the automatic workflow does not run for that mode.

The following fragment enables the documented removal mode using default rebalancing configuration. It belongs under the existing Kafka resource's specification:

spec:
  cruiseControl:
    autoRebalance:
      - mode: remove-brokers

The fragment expresses a workflow choice. It is not a complete Kafka resource and does not create the Cruise Control prerequisites by itself. Its purpose is to distinguish enabling removal rebalancing from changing a node pool's desired replica count.

Cordoning closes the new-placement race

On Kafka 4.3 or later, Strimzi automatically cordons brokers selected for removal. It sets the broker's cordoned.log.dirs configuration so new partitions cannot arrive while existing replicas move away. The broker remains available for its current work during the movement.

The documented ownership of that setting is significant. Strimzi lists cordoned.log.dirs among broker properties that users cannot set through the Kafka resource's general config map. The operator manages it as part of scale-down. Manually treating it as an independent tuning value would conflict with the workflow that now owns the decision.

This integration connects the two levels of desired state. The node pool describes how many brokers should remain. Kafka's cordoning configuration describes which storage remains eligible for new placement while the transition occurs. Cruise Control supplies the reassignment operation between those states.

Without the placement restriction, evacuation can race with new topic or partition creation. With it, the broker can continue serving existing replicas while the cluster stops allocating new ones to it. The result is a more specific maintenance state than simply healthy or absent.

Rebalance progress survives individual reconciliations

The documentation describes a KafkaRebalance resource created for the automatic operation. Its name identifies the cluster and scaling mode. Strimzi applies an auto-rebalancing finalizer to prevent deletion during the process.

Progress also appears in the Kafka resource's status.autoRebalance. Its modes identify the brokers being added or removed, so the operation has observable state across reconciliations. A desired replica count alone cannot communicate that intermediate work.

Rebalance templates remain configuration resources rather than immediate rebalance requests. The strimzi.io/rebalance-template annotation marks that role. That separation lets the operator reuse optimization settings when a scaling event occurs, while creating an operation-specific resource for the actual work.

The distinction is useful for an operator reading cluster state. A template explains policy. A generated rebalance resource and status explain an operation in progress. Neither should be mistaken for proof that every requested broker has already left the cluster.

Installation defaults restrict the operator containers

Strimzi 1.2 also changes its installation manifests and Helm defaults to match the Kubernetes Restricted Pod Security Standard. The release specifically names the Cluster, Topic, and User Operator installation files and the Cluster Operator chart. That scope should remain explicit when describing the change.

The Cluster Operator deployment shipped in 1.2.0 shows the concrete settings. Its container disables privilege escalation, drops all Linux capabilities, requires a non-root process, and selects RuntimeDefault seccomp. It also makes the root filesystem read-only.

These are execution restrictions on the operator container. They do not remove the Kubernetes permissions required for the operator to manage its resources. Container security settings and API authorization answer different questions, even though both affect the operator's authority.

The release also stops automatically mounting service-account tokens and instead uses an explicit projected volume. The shipped deployment sets automountServiceAccountToken to false while projecting the token, cluster CA certificate, and namespace information into a named volume.

That is not a removal of API credentials. The container still mounts the projected data at the service-account path, read-only. The difference is that the deployment specifies the projection directly, making credential availability part of the manifest rather than relying on automatic mounting.

The upgrade includes an API-version prerequisite

The release notes repeat the Strimzi 1.0 boundary for custom resources. Only the v1 CRD API is supported in 1.0 and later. Installations still using older beta or alpha resource versions must complete conversion and CRD upgrades before moving to this release.

That prerequisite is separate from Kafka's version requirement for cordoning. An installation needs the supported custom-resource API for the operator upgrade and Kafka 4.3 or later for the new removal integration. The release also adds Kafka 4.3.1 support, giving users a named broker patch release within that supported range.

The operational improvement is specific. Automatic removal can exclude a retiring broker from new placement while Cruise Control moves its existing replicas. The accompanying status and generated rebalance resource describe that work until the requested smaller cluster is ready.