Strimzi 1.1.0: The Kafka Operator That Speaks Gateway API

Running Apache Kafka on Kubernetes without losing your mind is a tall order. You need to handle broker configurations, rolling updates, TLS certificates, topic management, and about a dozen other things that Kafka politely leaves as an exercise to the operator. That is where Strimzi comes in.

Strimzi is an open-source CNCF incubating project that runs Kafka on Kubernetes using the operator pattern. Think of it as a really dedicated Kafka admin who never sleeps, never takes vacation, and is fluent in YAML. It handles the gritty details of deploying, configuring, and managing Kafka clusters so you do not have to babysit them.

If you have ever tried to manually configure Kafka listeners, rotate TLS certificates, or debug a Connect build that mysteriously cannot find its dependencies, Strimzi exists specifically to make those headaches go away. Platform engineers and SREs use it to declaratively manage Kafka clusters the same way they manage everything else on Kubernetes.

Strimzi 1.1.0 is the first minor release since the project moved to the v1 CRD API, and it brings a substantial set of new capabilities. The headline feature is Gateway API support with the new tlsroute listener type, but there is plenty more: Kafka 4.3.0 support, per-broker listener customization, PEM-based TLS for KafkaBridge and MirrorMaker 2, and fine-grained control over mTLS certificate lifecycles. Let us get into it.

Gateway API Support Arrives

The Gateway API is the Kubernetes-native way to manage inbound traffic, and Strimzi 1.1.0 adds support for a new type: tlsroute listener. This means you can now route TLS-terminated traffic to your Kafka brokers using the same Gateway API resources you already use for your HTTP services.

Previously, exposing Kafka externally meant dealing with NodePort, LoadBalancer, or Ingress resources, none of which were designed with Kafka in mind. The Gateway API integration gives you a unified, declarative traffic management model that plays nicely with service meshes and API gateways.

listeners:
  - name: gateway
    port: 9094
    type: tlsroute
    tls: true

This is a meaningful integration for teams standardizing on Gateway API across their stack. PR #12747 implements the feature.

Apache Kafka 4.3.0 and 4.2.1 Support

Kafka 4.3.0 is now supported in Strimzi 1.1.0, along with Kafka 4.2.1. The release also drops support for Kafka 4.1.x, so if you are running that version, you will need to upgrade your Kafka before or alongside the Strimzi upgrade.

The 4.3.0 release of Kafka itself brings improvements to KRaft mode stability and consumer group protocol enhancements. Combined with Strimzi, this gives you a fully supported, production-ready Kafka 4.x stack on Kubernetes.

For teams who want to run custom Apache Kafka versions, the improved support for custom builds means you are no longer locked into the versions Strimzi ships by default. You can bring your own Kafka distribution and Strimzi will manage it just the same.

Per-Broker Listener Templates

This one solves a genuinely annoying problem. Until now, listener annotations and labels applied at the cluster level. If you needed different annotations on different brokers (for example, different load balancer configurations per broker in a multi-AZ setup), you were out of luck.

Strimzi 1.1.0 adds support for configuring per-broker listener annotation and label templates. You can now use template variables to customize annotations and labels individually for each broker in the cluster:

listeners:
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    configuration:
      brokerCertChainAndKey:
        secretName: my-secret
        certificate: tls.crt
        key: tls.key
      annotations:
        external-dns.alpha.kubernetes.io/hostname: "${brokerId}.kafka.example.com"

The ${brokerId} template variable lets you generate unique annotations per broker, making multi-AZ and multi-region setups far less painful. PR #12743 adds this capability.

PEM Replaces P12/JKS for KafkaBridge and MirrorMaker 2

KafkaBridge and KafkaMirrorMaker2 now use PEM files instead of P12/JKS for TLS authentication and TLS truststore configuration. The PEM files are accessed directly from Kubernetes Secrets using the KubernetesSecretConfigProvider.

This is more than a format change. PEM is the lingua franca of TLS on Kubernetes, and removing the dependency on Java-specific keystore formats simplifies the entire TLS story.

If you are running KafkaBridge or MirrorMaker 2 with TLS, this is a behavior change you need to be aware of when upgrading. PR #12735 implements the migration.

More New Capabilities

• Maven dependency scope in Connect builds — You can now configure the dependency scope of Maven artifacts in Kafka Connect Build. This gives you fine-grained control over which dependencies end up in your connector plugins and which are only needed at build time. PR #12652.
• Per-KafkaUser mTLS certificate lifecycles — You can now configure validityDays and renewalDays for each individual KafkaUser, rather than being stuck with a single global setting. Different users can now have different certificate lifetimes. PR #12658.
• PKCS12 keystore generation toggle — The new STRIMZI_PKCS12_KEYSTORE_GENERATION operator config option lets you disable PKCS12 store generation in CA and KafkaUser Secrets. If you are not using Java clients, you no longer need to generate stores you will never use. PR #12708.
• UseBackgroundPodDeletion feature gate — A new alpha feature gate that uses background deletion propagation when deleting pods during rolling updates, which can speed up rolling operations on large clusters. PR #12672.
• Cruise Control reconciliation order — Cruise Control is now reconciled before the Entity Operator when both are enabled, improving the consistency of cluster rebalancing operations. PR #12759.
• Failed connector state transitions — Failed KafkaConnectors can now be stopped, and pausing of failed connectors is rejected since Kafka Connect does not support that operation. PR #12750.

Upgrading Notes

There are two things to be aware of when upgrading to 1.1.0:

• Kafka 4.1.x is no longer supported. Upgrade to 4.2.x or 4.3.0 before or during the Strimzi upgrade.
• KafkaBridge and MirrorMaker 2 TLS authentication now uses PEM instead of P12/JKS. If you rely on Java keystores for these components, you will need to adjust your configuration.

See the upgrade documentation for detailed instructions.

Strimzi 1.1.0 is a release that makes Kafka on Kubernetes feel a little more like it was always meant to be there.

Learn More

• Strimzi Official Website
• GitHub Repository
• Full Changelog for 1.1.0