LoginSign Up
← Back to all sparks
S

Strimzi

INFRA · APIS
Velocity5.0

Kubernetes operator for running and managing Apache Kafka clusters

strimzi.io ↗

Strimzi 1.3 starts encrypting and authenticating Kafka's internal connections.

kafkakubernetes operatorinternal encryptionrelease candidatesserver-side apply
◆Current state
Strimzi's feed carries release candidates rather than finals. 1.3.0-rc1 on 5 October added early-access configurable encryption and authentication for internal Kafka connections; 1.3.1-rc1 added Kafka 4.3.2 support and fixed concurrency issues left by the Vert.x removal, and 1.3.1-rc2 on 3 November only bumps Jackson. The 1.3 line requires Kubernetes 1.32+, deprecates PKCS12 certificates and drops Kaniko for Buildah.
◆Where it's heading
Since 1.0 removed every CRD API but v1, each minor follows the same pattern: support the newest Kafka, drop the oldest, tighten operator defaults. 1.3 adds security of the cluster's internal traffic to that list.
◆Prediction
A 1.4.0 candidate tracking the next Kafka release is the likely next entry, with the internal-security options possibly leaving early access.

◆Recent moves

  1. 11d ago

    Strimzi 1.3.1 RC2 only bumps Jackson

    The second 1.3.1 candidate changes only a Jackson dependency since rc1, which suggests the patch is close to final. It carries the 1.3 line's Kubernetes 1.32+ floor and PKCS12 deprecation notice.

    View source ↗
  2. 15d ago

    Strimzi 1.3.1 RC adds Kafka 4.3.2 support

    A release candidate for Strimzi 1.3.1 adding Kafka 4.3.2 support and fixing concurrency issues left by the Vert.x removal. It also restates that Kubernetes 1.30 and 1.31 are no longer supported.

    View source ↗
  3. 1mo ago

    Strimzi 1.3 RC adds internal cluster security options

    The 1.3.0 candidate adds early-access configurable encryption and authentication for internal Kafka connections and Kafka 4.2.2 support, and drops Kubernetes 1.30 and 1.31.

    View source ↗
  4. 2mo ago

    1.2.0 RC2 lands one CA logging fix

    The second 1.2.0 candidate carries a single change — incorrect CA logging — against rc1's Kafka 4.3.1 support and per-pod volume templates. The container image table is the bulk of the body. A one-fix candidate three days after the first is the sign of a cycle closing, not of new work arriving.

    View source ↗
  5. 3mo ago

    Kafka 4.3.1, per-pod volume templates, server-side apply GA

    The 1.2.0 candidate continues the post-1.0 pattern of tracking Apache Kafka releases while tightening operator defaults: Kafka 4.3.1 support, per-pod templated additional volumes, Maven mirror configuration for Connect builds, and broker cordoning during scale-down auto-rebalancing. The ServerSideApplyPhase1 gate reaches GA and is permanently enabled, completing a migration that was staged across earlier releases. Installation files now default to the Restricted Pod Security Standard security context and mount Service Account tokens through a volume instead of auto-mounting them.

    View source ↗
  6. 4mo ago

    Kafka 4.3.0 support; 4.1.x dropped; connector stop semantics fixed

    The 1.1.0 candidate set the cadence the 1.2.0 line follows: add the newest Kafka versions, drop the oldest, and fix connector state semantics. Its tlsroute Gateway API listener and per-broker template options are the same kind of configuration-surface widening that 1.2.0 extends with per-pod volumes.

    View source ↗