The type: ingress listener relied on the Ingress NGINX Controller for Kubernetes, a project that was announced for retirement by the Kubernetes community. It was actually archived on the stage during KubeCon EU Amsterdam this year, and I was there! With no future investment planned for that controller, building on top of it is no longer a good idea. Fortunately, the Kubernetes ecosystem has a well-supported successor: the Gateway API.

Starting with Strimzi 1.1, the operator natively supports a new external listener type (type: tlsroute) based on the Kubernetes Gateway API and its TLSRoute resource. In this post we will look at what the Gateway API is, why TLSRoute is the right fit for Kafka traffic, and then walk through a fully working example on minikube using Envoy Gateway as the Gateway controller.

From Ingress to Gateway API

The Ingress resource was the original Kubernetes abstraction for north-south HTTP traffic. It was never designed for non-HTTP protocols and, as a result, anyone trying to expose Kafka through it had to rely on vendor-specific annotations and implementation quirks.

The Kubernetes Gateway API was created to be a proper successor. It is an official Kubernetes SIG project that defines a set of standard Custom Resource Definitions for routing L4 and L7 traffic. It ships only the API specification; the actual data-plane work is delegated to Gateway controller implementations, of which there are many. This clean separation means you can swap controllers without changing your application-level configuration.

The Gateway API introduces a hierarchy of resources:

• GatewayClass: a cluster-scoped resource that names a specific controller (comparable to IngressClass).
• Gateway: an instance of a load balancer / proxy configured to handle traffic according to a GatewayClass.
• Route resources (HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, …): describe how traffic should be forwarded from the gateway to backend services.

Why TLSRoute?

Kafka speaks its own binary protocol over TCP, not HTTP or gRPC, so HTTPRoute and GRPCRoute are immediately ruled out. That leaves TCPRoute and TLSRoute.

TCPRoute routes arbitrary TCP traffic based solely on the destination port. This means you need a unique IP address or a unique port for every broker you want to expose, effectively 1 + N addresses/ports for a cluster with N brokers. At any meaningful scale that quickly becomes unmanageable.

TLSRoute solves this elegantly by using TLS-SNI (Server Name Indication) to route traffic. Because Kafka clients always open a TLS-encrypted connection to the broker (when TLS is enabled), the client hostname is present in the TLS handshake before any Kafka protocol bytes are exchanged. The gateway reads the SNI hostname and decides which backend service to forward the connection to. This means that one gateway address and one port can serve the bootstrap endpoint and every individual broker, distinguished purely by hostname.

TLSRoute moved to the Standard API channel in Gateway API v1.4 and got a stable v1 API version in v1.5, making it a solid foundation to build on.

How Strimzi uses TLSRoute

When you configure a type: tlsroute listener, the Strimzi Cluster Operator takes care of all the Gateway API plumbing on your behalf:

• A bootstrap service pointing to all brokers is created, along with a bootstrap TLSRoute for the bootstrap hostname.
• A per-broker service and a per-broker TLSRoute are created for each Kafka broker node, using the per-broker hostname.

You only need to:

1. Deploy and configure a Gateway (using any Gateway API compatible controller).
2. Reference that Gateway in your Kafka CR via the new parentRefs configuration field.

Strimzi will create and keep the TLSRoute resources in sync. This is especially useful when you combine type: tlsroute with horizontal auto-scaling of broker node pools: as brokers are added or removed, Strimzi automatically creates or deletes the corresponding TLSRoute resources.

TLS passthrough vs. TLS termination: the TLS mode is configured on the Gateway listener, not in Strimzi. With TLS passthrough, the encrypted connection travels all the way to the Kafka broker; the broker’s certificate is what clients verify. This is what we use in this guide and is the most common setup. TLS termination at the gateway is also possible in principle, but Gateway API controller support for it is still emerging.

Trying it on minikube

The rest of this post is a step-by-step walkthrough for running the type: tlsroute listener on a laptop using minikube and Envoy Gateway. At the end you will be able to produce and consume messages from outside the cluster using the standard Kafka client tools.

We assume minikube is already running locally. If you need to set it up first, follow the minikube getting started guide.

Prerequisites

You will need the following tools installed:

• kubectl
• Helm 3
• Strimzi 1.1.0+ installed in your cluster (the Quickstart is the fastest path)
• Kafka CLI tools (kafka-topics.sh, kafka-console-producer.sh, kafka-console-consumer.sh); alternatively, you can run them from inside a broker pod

Step 1: Install Envoy Gateway

Envoy Gateway ships with the Gateway API CRDs bundled, so there is no need to install them separately.

helm install envoygateway oci://docker.io/envoyproxy/gateway-helm \
  -n envoy-gateway-system --create-namespace

kubectl wait --timeout=5m -n envoy-gateway-system \
  deployment/envoy-gateway --for=condition=Available

Verify the installation and confirm that the Gateway API CRDs are present:

kubectl get pods -n envoy-gateway-system
kubectl get crd | grep gateway

You should see several CRDs including gateways.gateway.networking.k8s.io and tlsroutes.gateway.networking.k8s.io.

Step 2: Create the EnvoyProxy resource

The EnvoyProxy resource tells Envoy Gateway how to deploy the data-plane Envoy pods and what service type to use. On minikube we use LoadBalancer and rely on minikube tunnel to expose it.

# envoy-proxy.yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: minikube-proxy
  namespace: envoy-gateway-system
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyService:
        type: LoadBalancer

kubectl apply -f envoy-proxy.yaml

Step 3: Create the GatewayClass

A GatewayClass is a cluster-scoped resource that registers a specific Gateway controller with Kubernetes, much like IngressClass does for Ingress controllers. Every Gateway you create later must reference a GatewayClass, which is how Kubernetes knows which controller should reconcile it.

The controllerName field identifies the Envoy Gateway controller, and the parametersRef points to the EnvoyProxy resource we created in the previous step so that the controller knows how to deploy the data-plane pods.

# gateway-class.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-gateway
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
  parametersRef:
    group: gateway.envoyproxy.io
    kind: EnvoyProxy
    name: minikube-proxy
    namespace: envoy-gateway-system

kubectl apply -f gateway-class.yaml
kubectl get gatewayclass

The output should show the GatewayClass with ACCEPTED set to True, which means the Envoy Gateway controller has picked it up successfully.

Step 4: Start minikube tunnel

The LoadBalancer service created for the gateway needs an external IP. Open a new terminal and keep this command running throughout the session:

minikube tunnel

You may be prompted for your sudo password. Leave this terminal open and go back to your main terminal.

Step 5: Create the Gateway

A Gateway is an instance of a load balancer or proxy that listens for incoming traffic and routes it to backend services based on the attached route resources. It references a GatewayClass (via gatewayClassName) so Envoy Gateway knows it is responsible for reconciling this resource and deploying the corresponding Envoy proxy pods.

The listener we define here is the entry point for all Kafka traffic:

• protocol: TLS with mode: Passthrough tells the gateway to forward the raw TLS connection directly to the backend without terminating it. The TLS handshake happens end-to-end between the Kafka client and the Kafka broker.
• port: 8443 is the port on which the gateway will accept connections from outside the cluster.
• hostname: "*.kafka.local" restricts this listener to SNI hostnames matching that wildcard, which covers both the bootstrap address and all per-broker addresses we will configure later.
• allowedRoutes.namespaces.from: All permits TLSRoute resources from any namespace to attach to this listener, which is needed because Strimzi will create the routes in the Kafka cluster’s namespace.

# gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: envoy-gateway
  namespace: envoy-gateway-system
spec:
  gatewayClassName: envoy-gateway
  listeners:
    - name: tls-passthrough
      protocol: TLS
      port: 8443
      hostname: "*.kafka.local"
      tls:
        mode: Passthrough
      allowedRoutes:
        namespaces:
          from: All

kubectl apply -f gateway.yaml

Wait a few seconds and then verify the Gateway is PROGRAMMED:

kubectl get gateway envoy-gateway -n envoy-gateway-system

If PROGRAMMED shows False, check that minikube tunnel is still running and that the LoadBalancer service has been assigned an EXTERNAL-IP:

kubectl get svc -n envoy-gateway-system

Step 6: Configure DNS

Because we are running on a laptop, there is no real DNS server that can resolve the Kafka hostnames to the gateway’s address. We solve this by adding static entries to the local /etc/hosts file. This is the same technique used when doing local Kubernetes development: map the hostnames you care about directly to the IP exposed by minikube tunnel.

The hostnames we need come from the Kafka listener configuration we will apply in Step 7. The bootstrap.host field sets the bootstrap address (bootstrap.kafka.local), and the hostTemplate field defines the per-broker naming pattern (broker-{nodeId}.kafka.local), which for a three-broker cluster produces broker-0.kafka.local, broker-1.kafka.local, and broker-2.kafka.local. We add all four entries now so that the cluster is reachable as soon as it finishes reconciling.

First, retrieve the external IP that was assigned to the gateway:

GATEWAY_IP=$(kubectl get gateway envoy-gateway -n envoy-gateway-system \
  -o jsonpath='{.status.addresses[0].value}')
echo $GATEWAY_IP

Add entries to /etc/hosts so your laptop can resolve the Kafka hostnames:

sudo tee -a /etc/hosts <<EOF
${GATEWAY_IP} bootstrap.kafka.local
${GATEWAY_IP} broker-0.kafka.local
${GATEWAY_IP} broker-1.kafka.local
${GATEWAY_IP} broker-2.kafka.local
EOF

You can verify that DNS resolves correctly with:

ping -c 1 bootstrap.kafka.local

Note that the ping itself will likely time out (the gateway only listens on TCP); what matters is that the hostname resolves to the right IP.

Step 7: Deploy the Kafka cluster with a tlsroute listener

We assume the Strimzi Cluster Operator is installed in the kafka namespace and we will deploy the Kafka cluster there as well.

Create the Kafka and KafkaNodePool resources. The key part is the external listener of type: tlsroute, which instructs Strimzi to create TLSRoute resources instead of managing Ingress or LoadBalancer objects itself.

A few fields in the listener configuration are worth calling out:

• parentRefs points to the Gateway resource created in Step 5. This is how Strimzi knows which gateway to attach the TLSRoute resources to.
• bootstrap.host sets the hostname advertised to Kafka clients for the initial connection.
• hostTemplate defines the per-broker hostname pattern. The {nodeId} placeholder is replaced by the actual broker node ID at runtime.
• advertisedPortTemplate: 8443 fixes the advertised port to 8443 for every broker, matching the single port our gateway listener is configured on.

# kafka-cluster.yaml
apiVersion: kafka.strimzi.io/v1
kind: KafkaNodePool
metadata:
  name: controller
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - controller
  storage:
    type: jbod
    volumes:
      - id: 0
        type: ephemeral
        kraftMetadata: shared
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaNodePool
metadata:
  name: broker
  labels:
    strimzi.io/cluster: my-cluster
spec:
  replicas: 3
  roles:
    - broker
  storage:
    type: jbod
    volumes:
      - id: 0
        type: ephemeral
        kraftMetadata: shared
---
apiVersion: kafka.strimzi.io/v1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    version: 4.3.0
    metadataVersion: 4.3-IV0
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
      - name: external
        port: 9094
        type: tlsroute
        tls: true
        configuration:
          bootstrap:
            host: bootstrap.kafka.local
          parentRefs:
            - kind: Gateway
              group: gateway.networking.k8s.io
              name: envoy-gateway
              namespace: envoy-gateway-system
          hostTemplate: broker-{nodeId}.kafka.local
          advertisedPortTemplate: "8443"
    config:
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      default.replication.factor: 3
      min.insync.replicas: 2
  entityOperator:
    topicOperator: {}
    userOperator: {}

kubectl apply -f kafka-cluster.yaml -n kafka
kubectl wait kafka/my-cluster -n kafka --for=condition=Ready --timeout=300s

Once the cluster is ready, verify that Strimzi has created the TLSRoute resources automatically in the kafka namespace:

kubectl get tlsroute -n kafka

You should see one bootstrap route and one route per broker:

NAME                              HOSTNAMES                        AGE
my-cluster-kafka-bootstrap        ["bootstrap.kafka.local"]        2m
my-cluster-broker-0               ["broker-0.kafka.local"]         2m
my-cluster-broker-1               ["broker-1.kafka.local"]         2m
my-cluster-broker-2               ["broker-2.kafka.local"]         2m

Tip: If the TLSRoute resources are not created and the Cluster Operator logs show The Gateway API TLSRoute resource is not available in this Kubernetes cluster, the operator was started before the Gateway API CRDs were installed. Simply restart it (replace <operator-namespace> with the namespace where Strimzi is installed, e.g. strimzi if you used the Quickstart):

kubectl rollout restart deployment strimzi-cluster-operator -n <operator-namespace>

Step 8: Test the connection

Before connecting Kafka clients, we need to extract the cluster CA certificate that Strimzi generated for the cluster. Clients must trust this CA to be able to establish a TLS connection to the brokers.

kubectl get secret my-cluster-cluster-ca-cert -n kafka \
  -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

With the CA certificate in hand, do a quick sanity check with OpenSSL to verify the TLS passthrough is working end to end:

openssl s_client -connect broker-0.kafka.local:8443 \
  -servername broker-0.kafka.local -showcerts

You should see CONNECTED and the broker certificate chain. A Verify return code: 19 (self-signed certificate in certificate chain) is expected; the important thing is that the TLS handshake completes successfully.

Now test with the Kafka CLI tools. All commands need to know the bootstrap address and that TLS is required, so start by creating a client properties file that every tool will share via --command-config or --producer.config / --consumer.config:

# client-ssl.properties
bootstrap.servers=bootstrap.kafka.local:8443
security.protocol=SSL
ssl.truststore.type=PEM
ssl.truststore.location=ca.crt

The ssl.truststore.location points to the ca.crt file we just extracted. Using ssl.truststore.type=PEM means we can pass the certificate file directly without converting it to a Java keystore first.

First, verify that the client can reach the cluster and list topics. At this point the list will be empty, but a successful response confirms that the bootstrap connection and broker metadata exchange are working correctly:

kafka-topics.sh --bootstrap-server bootstrap.kafka.local:8443 \
  --command-config client-ssl.properties \
  --list

Next, create a test topic with three partitions and a replication factor of three, one replica per broker:

kafka-topics.sh --bootstrap-server bootstrap.kafka.local:8443 \
  --command-config client-ssl.properties \
  --create --topic test-topic \
  --partitions 3 --replication-factor 3

With the topic in place, open an interactive producer session and type a few messages, pressing Enter after each one. Press Ctrl+C when you are done to close the producer:

kafka-console-producer.sh --bootstrap-server bootstrap.kafka.local:8443 \
  --producer.config client-ssl.properties \
  --topic test-topic

Finally, start a consumer reading from the beginning of the topic. It should print every message you just produced, which confirms that the per-broker TLSRoute resources are working correctly. Each message was written to a specific broker and the consumer was able to reach that broker individually through its own dedicated route:

kafka-console-consumer.sh --bootstrap-server bootstrap.kafka.local:8443 \
  --consumer.config client-ssl.properties \
  --topic test-topic \
  --from-beginning

Press Ctrl+C to stop the consumer once you have seen all the messages.

Conclusion

The new type: tlsroute listener brings first-class Gateway API support to Strimzi. It fills the gap left by the deprecated type: ingress listener and does so on a stable, vendor-neutral standard that has broad ecosystem support.

From a user perspective, the configuration is straightforward: bring your own Gateway, point Strimzi at it via parentRefs, and Strimzi takes care of creating and maintaining the TLSRoute resources, including as brokers are scaled up or down.

From a protocol perspective, TLS-SNI-based routing gives you the clean one-address-one-port topology that is so important for the Kafka protocol, without the complexity of managing one unique IP per broker that TCPRoute would require.

If you are currently using type: ingress and wondering what to migrate to, type: tlsroute is the answer. Any Gateway API compatible controller will work; in this post we used Envoy Gateway, but you could equally use Cilium Gateway API, Istio, NGINX Gateway Fabric, or any other implementation you already have in your cluster.

For more background on the design decisions behind this feature, have a look at Strimzi proposal #136.

Why We Added an AI Assistant

As Strimzi has grown, so has the volume of questions from the community. Many of these questions, whether they come through Slack, GitHub Discussions, or issues, are already answered somewhere in our documentation. But finding the right answer in the right place is not always easy, especially for newcomers.

Maintainers spend a significant amount of time answering repetitive questions, which takes time away from development, reviews, and other project work. This is a common challenge across open-source projects, sometimes called the “support tax.”

The CNCF partnered with Kapa.ai to offer AI-powered assistants to all CNCF projects, free of charge. When we saw the opportunity, we decided to try it out for Strimzi.

What Is Kapa.ai?

Kapa.ai is an AI assistant platform built specifically for technical communities. Unlike a general-purpose chatbot, it uses Retrieval Augmented Generation (RAG) to ground its responses in a project’s actual knowledge base. This means answers come from Strimzi’s own documentation, GitHub issues, discussions, and other project-specific sources, rather than from a generic language model that might hallucinate.

How It Works

Click the Strimzi icon in the bottom-right corner of any page on the Strimzi website, and a chat window opens. You can ask questions in natural language, and Kapa.ai will search through the Strimzi knowledge base to find relevant answers.

Each answer includes references to the source material, so you can verify the information and dive deeper if needed.

Here are a few examples of questions you could ask:

• “How do I configure TLS for Kafka listeners in Strimzi?”
• “What is the difference between KRaft and ZooKeeper mode in Strimzi?”
• “How do I set up Kafka Connect with Strimzi?”
• “What annotations control certificate renewal?”

What Kapa.ai Means for the Community

The goal is not to replace human interaction. Strimzi’s community channels remain the best place for in-depth discussions, design conversations, and collaboration.

What Kapa.ai does is handle the common, well-documented questions, so maintainers can focus on the work that needs a human: code reviews, design decisions, mentoring contributors, and pushing the project forward.

It also helps identify gaps in our documentation. When the assistant cannot answer a question, that is a signal that we may need to improve our docs in that area.

Privacy and Data

Kapa.ai does not use community question-and-answer data for training models or any other purpose. Your data stays with the project. You can read more about the CNCF’s partnership and data policies in their announcement blog post.

Try It Out

Head over to strimzi.io and click the floating Strimzi icon in the bottom-right corner. Ask it anything about Strimzi, and let us know what you think.

After each answer, you will see “Good Answer” and “Bad Answer” buttons along with an optional text field where you can explain your rating.

This feedback loop matters. Positive ratings confirm that the knowledge base is working well, while negative ratings with a short rationale help us pinpoint where the assistant falls short and where our documentation needs improvement.

We would love to hear your experience. Share your feedback on the #strimzi Slack channel or open a GitHub Discussion.

StrimziCon is over for another year!

The 2026 program included:

• 6 sessions
• 10 speakers from 5 organizations
• Over 4 hours of content

This year’s content included tips for running in production, best practices for using Strimzi components, and real-world use cases shared by maintainers, contributors and users of Strimzi. In the breaks between sessions attendees connected and shared their own experiences with Strimzi.

A massive thank you to everyone who joined us live on the day, our wonderful speakers, the program committee who built the schedule, and to CNCF for hosting the event.

Session Recordings and Slides

All the session recordings are now available on the Strimzi YouTube channel. To help you choose which one to watch first, here’s an introduction to each session, as well as links to the recording and slides.

Keynote (Recording/Slides)

Speakers: Paolo Patierno & Kate Stanley @ IBM

Paolo and Kate opened the event by sharing the latest features and improvements that have been added to Strimzi over the past year, including the long awaited 1.0.0 release. They also shared some insights into how the 1.0.0 release came about and provided a glimpse into what’s on the horizon for the project. Finally, they shared some updates from the community, including new ways to keep up with the wider community, the new AI policy and the path to graduation.

Beyond the Install: Take full ownership of your Strimzi cluster (Recording/Slides)

Speaker: Jakub Scholz @ Cloudera

Jakub challenged the notion that open source is “free” and explored what it really means to own your Strimzi installation in production. The session covered critical aspects of Strimzi ownership including securing your container supply chain, mirroring images, and handling CVEs in base images and dependencies even when there’s no official patch release.

Who Are You? Configuring Kafka Authentication in Strimzi from TLS to Custom Principals (Recording/Slides)

Speaker: Daniel Mulder @ Axual

Daniel walked through the full range of authentication options available in Strimzi, from basic TLS authentication to advanced custom principal builders. The session explored listener-aware authentication patterns and how to implement a robust multi-tenancy strategy, while also discussing the risks of leaning too heavily on Strimzi internals and how to add authorization into the picture.

Swapping the Engine Mid-Flight: How We Moved Reddit’s Petabyte Scale Kafka Fleet to Kubernetes (Recording/Slides)

Speaker: Sky Kistler @ Reddit

Sky shared Reddit’s remarkable journey of migrating 500+ EC2-backed Kafka brokers and petabytes of data to Strimzi on Kubernetes with zero downtime. The session detailed their innovative “stretch cluster” approach, including DNS facade implementation, hybrid cluster setup by temporarily forking the Strimzi operator, and the step-by-step process that treated the migration as a series of safe, reversible operations rather than a risky “lift and shift.”

Building Strimzi MCP Server for Kubernetes: Democratizing Platform Expertise Through LLMs (Recording/Slides)

Speaker: David Kornel, Jakub Stejskal @ IBM

David and Jakub demonstrated how they built an open-source MCP server for Strimzi that makes platform expertise accessible through natural language interactions with LLMs. The session included a live demo of incident diagnosis, explained the implementation using Quarkus, and discussed how structured data and prompt templates guide the LLM through expert-level troubleshooting steps while catching misconfigurations without requiring extensive documentation reading.

From Running to Operating: Real-World Strimzi in Production (Recording/Slides)

Speakers: Rajith Attapattu @ Randoli

Rajith shared a real-world case study of running Strimzi at scale, covering architecture choices, monitoring insights and how they handled the upgrade to Strimzi 1.0.0. The session explored how to instrument Strimzi with OpenTelemetry, identify signals that actually matter, and build actionable observability, along with operational patterns that help teams move from reactive firefighting to proactive reliability.

Disaster Recovery in action with Kafka and Strimzi (Recording/Slides)

Speaker: Mickael Maison, Gantigmaa Selenge @ IBM

Mickael and Tina walked through the key considerations for setting up and operating a disaster recovery environment for Kafka using Strimzi and MirrorMaker. The session covered monitoring replication lag and health, clean and unclean failover/failback procedures, offset translation semantics, and important limitations and pitfalls to be aware of when implementing disaster recovery.

Closing (Recording/Slides)

Speakers: Paolo Patierno & Kate Stanley @ IBM

Paolo and Kate closed the event by reflecting on the day’s sessions and thanking the speakers, attendees, and everyone who contributed to making StrimziCon 2026 a success. They also posed some final questions to the audience and shared some insights from Strimzi maintainers on their favourite features and what they are looking forward to coming to the project in future.

What Next?

If you’ve run out of StrimziCon 2026 sessions to watch, why not check out our playlist of last year’s event. Find out how you can help the Strimzi community on our Join Us page on the website.

Thanks again to everyone who made this year’s event such a success.

Awesome sessions … join StrimziCon!

The conference will take place on Wednesday, June 3rd, 2026 (afternoon CEST). The event opens with a keynote from Kate Stanley and Paolo Patierno (IBM, Strimzi maintainers). The keynote is followed by almost 4 hours of breakout sessions with topics covering core Strimzi features, use cases, operations, and integrations.

For more details about speakers and sessions, see the CNCF event page.

We look forward to seeing you at the conference. Register here. It’s free!

Why attend StrimziCon?

StrimziCon is a community event for developers, DevOps engineers, and solution architects who want to learn about Strimzi and event streaming. This event will bring together the Strimzi community to share real‑world use cases, best practices, and first‑hand experience from experts and users alike. If you work with cloud-native technologies, and need to manage data in motion in a cloud-based environment, this event is for you.

The conference will take place on Wednesday, June 3rd, 2026 (afternoon CEST).

The call for speakers is now open, and we’re eagerly awaiting your proposals to discuss:

• Core Strimzi: Deep dive into a specific component or feature.
• Case Studies: Provide an overview of a use case or review of a real-world Strimzi deployment, highlighting difficulties, lessons learned, and key takeaways.
• Integrations: Explore how Strimzi integrates with other open source or CNCF projects.
• Operations: Share insights into what it takes to run Strimzi and maintain clusters in production.

The submission deadline is March 31st, 2026.

From the community to the community

We encourage any community members to submit a talk: from a Strimzi deep dive, to how you operate and use it in production, through integrations with other projects. From the community to the community, this is the best way to share.

Paolo Patierno and Kate Stanley, Strimzi maintainers and contributors, are organizing the conference with the CNCF team and will host the event.

All submitted sessions will be evaluated by the StrimziCon program committee. The committee includes representatives from companies that use Strimzi in production. We’ll have representatives from IBM, Ericsson, Reddit, Red Hat, and Elation Health Inc.:

• Paolo Patierno (Senior Principal Software Engineer @IBM)
• Kate Stanley (Principal Software Engineer @IBM)
• Michael Morris (Master Engineer @Ericsson)
• Nick Garvey (Staff Software Engineer @Reddit)
• Ali Ok (Principal Software Engineer @Red Hat)
• Liam Clarke-Hutchinson (Staff Software Enginner @Elation Health Inc.)
• Jakub Scholz (Principal Engineer @Cloudera)
• Mickael Maison (Senior Principal Software Engineer @IBM)
• Shubham Rawat (Senior Software Engineer @IBM)

The committee members will leverage their experience and knowledge on the project as users and contributors in order to select the best proposals and build an awesome agenda.

Join us, propose your session or register to attend!

You can find more details on the official page as part of the CNCF events.

Don’t forget to submit your proposal here.

Even if you’re not considering presenting, we hope you will still join us as an attendee.

It’s virtual, it’s free, and it’s going to be epic again! Join the Strimzi community at StrimziCon 2026!

With client-side apply, even changes to different fields can unintentionally overwrite each other. This behavior is especially problematic when multiple reconciliation loops are involved, as one operator may repeatedly revert changes made by another. This is the case with client-side apply as used in Strimzi.

Client-side apply in Strimzi

When a user creates or updates a Strimzi resource, the desired state is taken by Strimzi and propagated into all needed resources. For example (based on the configuration), when a user updates a field in the Kafka CR, Strimzi rebuilds the desired state for resources like StrimziPodSet, ConfigMap, Service, and PersistentVolumeClaim. This is completely fine until another operator, running in a reconciliation loop, updates these resources with another value. One example is Kyverno, which has a policy to add annotation policies.kyverno.io/last-applied-patches:... to all resources in the Kubernetes cluster using MutatingWebhookConfiguration. With each update, Strimzi detects the resource change and reconciles it from the desired state, overwriting any modifications made by the other operator. This can result in an update loop, along with warnings, errors, or other downstream issues in affected services or operators.

Because of these issues, we decided to add support for Server-Side Apply.

What is Server-Side Apply?

Server-Side Apply (SSA) allows multiple actors to update the same Kubernetes resource while managing different fields. Instead of applying a full object update, each actor applies only the fields it owns, identified by a field manager. Kubernetes then tracks field ownership and detects conflicts when multiple actors attempt to manage the same field.

For operators, this provides a clear ownership model. The Strimzi operator can manage only the fields it’s responsible for, without overwriting changes made to other fields by users or other controllers.

At the same time, this model assumes that other actors modify only the fields that they are responsible for. If process external to Strimzi updates fields that are essential for Strimzi’s functionality, Strimzi will revert the changes back. However, SSA makes these ownership boundaries explicit and visible, helping surface such issues earlier and making them easier to understand and address.

Incremental implementation of Server-Side Apply in Strimzi

Originally, there was a proposal and a plan to implement Server-Side Apply for all resources managed by Strimzi. However, the scope of such a change turned out to be too large, so we decided (in second proposal) to split the implementation into multiple phases.

Phase 1: Initial Server-Side Apply support

Server-Side Apply support was introduced in Strimzi 0.48 behind a feature gate, and its adoption is being implemented incrementally.

In the first phase, we implemented Server-Side Apply for the following resources:

• PersistentVolumeClaim
• ServiceAccount
• Service
• Ingress
• ConfigMap

These resources were identified as the most problematic based on GitHub issues, community discussions, and feedback from users on the Strimzi community Slack channels. To minimize risk and avoid unexpected behavior, switching to Server-Side Apply is gated behind a feature gate called ServerSideApplyPhase1.

When this feature gate is enabled, the Cluster Operator uses Server-Side Apply (SSA) exclusively for these resources, applying declarative updates, such as changes to metadata, spec, and status, rather than rebuilding the entire resource from scratch. The SSA implementation in Strimzi ensures that fields managed by Strimzi are always reconciled to the desired state, even in the presence of conflicts.

The reconciliation flow is as follows:

• Strimzi first attempts to apply the change using Server-Side Apply without forcing ownership.
• If no conflict occurs, the patch is applied and reconciliation continues.
• If a conflict is detected, the Cluster Operator logs the error and retries the apply operation with force enabled.
• When force is used, the affected field is updated, overwriting any changes made by other actors, and an explicit log entry is emitted to make this behavior visible to users.

This approach ensures that Strimzi can reliably configure the fields required for correct cluster functionality, while still allowing other actors to manage fields outside of Strimzi’s ownership.

How Server-Side Apply works in practice

Theory is nice, but let’s see Server-Side Apply in action. To try out this feature, you first need to enable the ServerSideApplyPhase1 feature gate in the Deployment resource for the Strimzi Cluster Operator:

...
- name: STRIMZI_FEATURE_GATES
  value: "+ServerSideApplyPhase1"
...

With Server-Side Apply enabled in the Cluster Operator, it can be tested on one of the phase 1 SSA resources. For this example, an ephemeral Kafka cluster is created from the configuration examples provided with Strimzi.

As a simple test case, a custom annotation is added to the -kafka-bootstrap Service. Before doing that, let’s inspect the current .metadata section of the resource.

> kubectl get service
NAME                         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                        AGE
my-cluster-kafka-bootstrap   ClusterIP   X.X.X.X         <none>        9091/TCP,9092/TCP,9093/TCP                     9m17s
my-cluster-kafka-brokers     ClusterIP   None            <none>        9090/TCP,9091/TCP,8443/TCP,9092/TCP,9093/TCP   9m17s

> kubectl get service my-cluster-kafka-bootstrap -o jsonpath='{.metadata}' | jq
{
  "annotations": {
    "strimzi.io/discovery": "[ {\n  \"port\" : 9092,\n  \"tls\" : false,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n}, {\n  \"port\" : 9093,\n  \"tls\" : true,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n} ]"
  },
  ...
  "managedFields": [
    {
      "apiVersion": "v1",
      "fieldsType": "FieldsV1",
      "fieldsV1": {
        "f:metadata": {
          "f:annotations": {
            "f:strimzi.io/discovery": {}
          },
          ...
      "manager": "strimzi-kafka-operator",
      "operation": "Apply"
    },
    ...
  ]
}

At this point, the Service contains a single annotation, strimzi.io/discovery. The managedFields section shows that this annotation is owned by the strimzi-kafka-operator field manager and was applied using Server-Side Apply.

Now let’s simulate another actor updating the same resource by adding a custom annotation using SSA - in our case it will be my.annotation/some: value.

> kubectl apply --server-side --field-manager=different-agent -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  annotations:
    my.annotation/some: value # add new annotation
    strimzi.io/discovery: |-
      [ {
        "port" : 9092,
        "tls" : false,
        "protocol" : "kafka",
        "auth" : "none"
      }, {
        "port" : 9093,
        "tls" : true,
        "protocol" : "kafka",
        "auth" : "none"
      } ]
  labels:
    app.kubernetes.io/instance: my-cluster
    app.kubernetes.io/managed-by: strimzi-cluster-operator
    app.kubernetes.io/name: kafka
    app.kubernetes.io/part-of: strimzi-my-cluster
    strimzi.io/cluster: my-cluster
    strimzi.io/component-type: kafka
    strimzi.io/discovery: "true"
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka
  name: my-cluster-kafka-bootstrap
  namespace: test
spec:
  clusterIP: 10.97.174.54
  clusterIPs:
  - 10.97.174.54
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: tcp-replication
    port: 9091
    protocol: TCP
    targetPort: tcp-replication
  - name: tcp-clients
    port: 9092
    protocol: TCP
    targetPort: tcp-clients
  - name: tcp-clientstls
    port: 9093
    protocol: TCP
    targetPort: tcp-clientstls
  selector:
    strimzi.io/broker-role: "true"
    strimzi.io/cluster: my-cluster
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka
  sessionAffinity: None
  type: ClusterIP
EOF

The --field-manager flag identifies the actor performing the change. If we inspect the metadata again, we can see that the annotation was added and is now owned by a different field manager.

> kubectl get service my-cluster-kafka-bootstrap -o jsonpath='{.metadata}' | jq
{
  "annotations": {
    "my.annotation/some": "value",
    "strimzi.io/discovery": "[ {\n  \"port\" : 9092,\n  \"tls\" : false,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n}, {\n  \"port\" : 9093,\n  \"tls\" : true,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n} ]"
  },
  ...
  "managedFields": [
    ...
    {
      "apiVersion": "v1",
      "fieldsType": "FieldsV1",
      "fieldsV1": {
        "f:metadata": {
          "f:annotations": {
            "f:my.annotation/some": {}
          }
        }
      },
      "manager": "different-agent",
      "operation": "Update",
      "time": "2026-01-14T00:54:46Z"
    }

Without Server-Side Apply, Strimzi would not track ownership of individual fields, and this custom annotation would likely be removed during the next reconciliation.

Handling conflicts

Now let’s see what happens when another actor attempts to modify a field owned by Strimzi. In this case, you will need to use --force-conflicts, as the field we are trying to update is managed by Strimzi.

> kubectl apply --server-side --field-manager=different-agent --force-conflicts -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  annotations:
    my.annotation/some: value # keep the annotation
    strimzi.io/discovery: "this-is-wrong" # change the annotation managed by Strimzi
  labels:
    app.kubernetes.io/instance: my-cluster
    app.kubernetes.io/managed-by: strimzi-cluster-operator
    app.kubernetes.io/name: kafka
    app.kubernetes.io/part-of: strimzi-my-cluster
    strimzi.io/cluster: my-cluster
    strimzi.io/component-type: kafka
    strimzi.io/discovery: "true"
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka
  name: my-cluster-kafka-bootstrap
  namespace: test
spec:
  clusterIP: 10.97.174.54
  clusterIPs:
  - 10.97.174.54
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: tcp-replication
    port: 9091
    protocol: TCP
    targetPort: tcp-replication
  - name: tcp-clients
    port: 9092
    protocol: TCP
    targetPort: tcp-clients
  - name: tcp-clientstls
    port: 9093
    protocol: TCP
    targetPort: tcp-clientstls
  selector:
    strimzi.io/broker-role: "true"
    strimzi.io/cluster: my-cluster
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka
  sessionAffinity: None
  type: ClusterIP
EOF

At this point, the annotation is updated (as we used force apply):

> kubectl get service my-cluster-kafka-bootstrap -o jsonpath='{.metadata}' | jq
{
  "annotations": {
    "my.annotation/some": "value",
    "strimzi.io/discovery": "this-is-wrong"
  },
  ...
}

During the next reconciliation, Strimzi detects a conflict on the strimzi.io/discovery annotation. Since this field is owned by Strimzi, the operator logs a warning and retries the apply operation with force enabled:

2026-01-14 01:01:09 DEBUG AbstractNamespacedResourceOperator:280 - Reconciliation #68(timer) Kafka(test-suite-namespace/my-cluster): Service test-suite-namespace/my-cluster-kafka-bootstrap is being patched using Server Side Apply
2026-01-14 01:01:09 WARN  AbstractNamespacedResourceOperator:286 - Reconciliation #68(timer) Kafka(test-suite-namespace/my-cluster): Service test-suite-namespace/my-cluster-kafka-bootstrap failed to patch because of conflict: Failure executing: PATCH at: https://X.X.X.X:443/api/v1/namespaces/test-suite-namespace/services/my-cluster-kafka-bootstrap?fieldManager=strimzi-kafka-operator&force=false. Message: Apply failed with 1 conflict: conflict with "different-agent" using v1: .metadata.annotations.strimzi.io/discovery. Received status: Status(apiVersion=v1, code=409, details=StatusDetails(causes=[StatusCause(field=.metadata.annotations.strimzi.io/discovery, message=conflict with "different-agent" using v1, reason=FieldManagerConflict, additionalProperties={})], group=null, kind=null, name=null, retryAfterSeconds=null, uid=null, additionalProperties={}), kind=Status, message=Apply failed with 1 conflict: conflict with "different-agent" using v1: .metadata.annotations.strimzi.io/discovery, metadata=ListMeta(_continue=null, remainingItemCount=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=Conflict, status=Failure, additionalProperties={})., applying force

After the forced apply, Strimzi restores the correct value of its managed annotation, while the custom annotation remains untouched:

> kubectl get service my-cluster-kafka-bootstrap -o jsonpath='{.metadata}' | jq
{
  "annotations": {
    "my.annotation/some": "value",
    "strimzi.io/discovery": "[ {\n  \"port\" : 9092,\n  \"tls\" : false,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n}, {\n  \"port\" : 9093,\n  \"tls\" : true,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n} ]"
  },
  ...
}

This example demonstrates how Server-Side Apply allows Strimzi to reliably enforce the fields it owns, while safely coexisting with other actors managing the same resource.

Removal of fields

In Server-Side Apply, every actor have a possibility to remove the fields - but only those they manage. That means, in case that Strimzi owns the strimzi.io/discovery annotation and we want to remove it with our different-agent field manager, the field will not be deleted after the update. Only the my.annotation/some will be removed, as it is owned by different-agent field manager:

> kubectl apply --server-side --field-manager=different-agent -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  annotations: {} # set annotations to null
  labels:
    app.kubernetes.io/instance: my-cluster
    app.kubernetes.io/managed-by: strimzi-cluster-operator
    app.kubernetes.io/name: kafka
    app.kubernetes.io/part-of: strimzi-my-cluster
    strimzi.io/cluster: my-cluster
    strimzi.io/component-type: kafka
    strimzi.io/discovery: "true"
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka
  name: my-cluster-kafka-bootstrap
  namespace: test
spec:
  clusterIP: 10.97.174.54
  clusterIPs:
  - 10.97.174.54
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: tcp-replication
    port: 9091
    protocol: TCP
    targetPort: tcp-replication
  - name: tcp-clients
    port: 9092
    protocol: TCP
    targetPort: tcp-clients
  - name: tcp-clientstls
    port: 9093
    protocol: TCP
    targetPort: tcp-clientstls
  selector:
    strimzi.io/broker-role: "true"
    strimzi.io/cluster: my-cluster
    strimzi.io/kind: Kafka
    strimzi.io/name: my-cluster-kafka
  sessionAffinity: None
  type: ClusterIP
EOF

The annotations field in the Service after the apply looks like this:

> kubectl get service my-cluster-kafka-bootstrap -o jsonpath='{.metadata}' | jq
{
  "annotations": {
    "strimzi.io/discovery": "[ {\n  \"port\" : 9092,\n  \"tls\" : false,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n}, {\n  \"port\" : 9093,\n  \"tls\" : true,\n  \"protocol\" : \"kafka\",\n  \"auth\" : \"none\"\n} ]"
  },
  ...
}

Conclusion

In this blog post, we described Server-Side Apply, how Strimzi uses it, how to enable it, and how it can simplify working with Strimzi — especially in environments where multiple operators modify the same Kubernetes resources. Although Server-Side Apply has been available in Strimzi since version 0.48.0, it is still in the alpha stage and ready for broader testing. We plan to move it to beta (enabled by default) in next version - Strimzi 0.51.0. In case that you will find any issue with the implementation, or have suggestions related to Server-Side Apply in Strimzi, you can share your feedback with us on Slack, or by opening a discussion or an issue on GitHub.