Run Kafka on Kubernetes with Strimzi

By Khimananda Oli | Last reviewed: August 2026

Deploying Apache Kafka directly on Kubernetes often leads to fragile StatefulSets, manual certificate rotation, and operational debt that compounds during outages. To reliably run Kafka on Kubernetes with Strimzi, you should adopt the operator pattern, which encapsulates years of streaming expertise into Custom Resource Definitions (CRDs) that manage the full lifecycle automatically. This approach shifts your focus from maintaining broker pods to defining declarative intent, ensuring your event streaming platform remains resilient, secure, and compliant with standards like SOC 2.

How do you install the Strimzi operator to run Kafka on Kubernetes?

Before you can understand how operators extend the Kubernetes API, you need a working installation. The Strimzi Cluster Operator is the control plane component that watches for Kafka, KafkaTopic, and KafkaUser resources. In 2026, Helm is the standard installation method for most teams because it simplifies upgrades and value overrides compared to raw manifests.

Install via Helm

Add the official repository and install the operator into a dedicated namespace. This isolates operator permissions and makes RBAC management cleaner.

helm repo add strimzi https://strimzi.io/charts/
helm repo update

kubectl create namespace kafka
helm install strimzi-operator strimzi/strimzi-kafka-operator \
  --namespace kafka \
  --set watchNamespaces="{kafka}" \
  --set replicas=2 \
  --version 0.45.0

Setting replicas=2 enables leader election so the operator itself is highly available. If you are running in a multi-tenant cluster, restrict watchNamespaces to prevent the operator from reconciling resources in unrelated namespaces. For single-tenant clusters or development environments, omit this flag to watch all namespaces.

Verify the installation

Confirm the operator pods are running and the CRDs are registered:

kubectl get pods -n kafka
kubectl get crd | grep strimzi

You should see kafkas.kafka.strimzi.io, kafkatopics.kafka.strimzi.io, and at least ten other CRDs. If the operator pod enters CrashLoopBackOff, check logs for RBAC errors — this usually means the ServiceAccount lacks permission to list or patch resources in the target namespace.

How do you configure a production-ready Kafka cluster with Strimzi?

A minimal Kafka resource gets you started, but production workloads require explicit storage, resource, and listener configuration. A common mistake is deploying without persistent volumes or with ephemeral storage — this guarantees data loss on pod restart. Always use persistent volumes provisioned by a CSI driver backed by network-attached storage or local NVMe.

Define the Kafka custom resource

This example provisions a three-broker cluster using KRaft (ZooKeeper-less mode, stable since Strimzi 0.40+) with encrypted internal communication and an internal-only listener:

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: production-cluster
  namespace: kafka
spec:
  kafka:
    version: 3.9.0
    replicas: 3
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
    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
    storage:
      type: jbod
      volumes:
        - id: 0
          type: persistent-claim
          size: 500Gi
          deleteClaim: false
          class: gp3-encrypted
    resources:
      requests:
        memory: "8Gi"
        cpu: "2"
      limits:
        memory: "12Gi"
        cpu: "4"
  entityOperator:
    topicOperator: {}
    userOperator: {}
  kafkaExporter:
    topicRegex: ".*"
    groupRegex: ".*"

Key configuration decisions here:

• min.insync.replicas: 2 with replication factor 3 ensures writes succeed only when two replicas acknowledge, preventing data loss if one broker fails.
• deleteClaim: false prevents accidental PVC deletion when the Kafka resource is removed. Set this to true only in disposable dev environments.
• jbod storage allows multiple disks per broker later without reconfiguration. Even with a single volume now, this avoids migration pain.
• kafkaExporter exposes Prometheus metrics natively. Pair this with Prometheus metric fundamentals to build dashboards tracking under-replicated partitions and consumer lag.

Apply and validate

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

The Ready condition confirms all brokers are in-sync and the entity operator is functional. If the wait times out, inspect kubectl describe kafka/production-cluster for reconciliation errors — often insufficient storage quota or missing StorageClass.

How does Strimzi compare to other Kafka Kubernetes deployment methods?

Teams evaluating how to run Kafka on Kubernetes with Strimzi often ask whether simpler alternatives suffice. The choice depends on operational maturity, compliance requirements, and team size. Here is a practical comparison based on production deployments I have audited:

For Nepali fintech or healthtech companies requiring data to stay within national borders while meeting ISO 27001 controls, Strimzi provides the auditability of self-management without the fragility of raw manifests. Managed services simplify operations but introduce vendor lock-in and potential compliance conflicts with local data residency regulations.

How do you secure Kafka topics and users with Strimzi CRDs?

Security cannot be bolted on after deployment. Strimzi treats authorization as a first-class concern through KafkaUser and KafkaTopic resources. This aligns with Kubernetes secrets management best practices by keeping credentials out of application code and rotating them automatically.

Create a TLS-authenticated producer user

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: order-service-producer
  labels:
    strimzi.io/cluster: production-cluster
spec:
  authentication:
    type: tls
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: orders
          patternType: literal
        operation: Write
        host: "*"
      - resource:
          type: topic
          name: orders
          patternType: literal
        operation: Describe
        host: "*"

This creates a client certificate signed by Strimzi’s internal CA and grants write-only access to the orders topic. The certificate is stored in a Kubernetes Secret named order-service-producer. Mount this secret in your application pod and configure the Kafka client to use it for mutual TLS.

Define topics declaratively

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: orders
  labels:
    strimzi.io/cluster: production-cluster
spec:
  partitions: 12
  replicas: 3
  config:
    retention.ms: 604800000
    segment.bytes: 1073741824
    min.insync.replicas: 2

Never create topics via admin CLI in production. Declarative topics ensure partition count and replication survive cluster upgrades and are version-controlled alongside your infrastructure code. Changing partitions triggers a controlled rebalance; reducing partitions is blocked to prevent data loss.

What monitoring and observability practices are essential for Strimzi Kafka?

Running Kafka without observability is operating blind. Strimzi exports JMX metrics via the built-in Kafka Exporter, but you must define meaningful SLIs. Focus on these four golden signals adapted for streaming:

1. Under-replicated partitions: Any value above zero indicates broker failure or disk issues. Alert immediately.
2. Consumer group lag: Rising lag means consumers cannot keep up. Correlate with processing latency.
3. Request latency p99: Produce/fetch latency spikes signal GC pauses, network saturation, or disk I/O bottlenecks.
4. Active controller count: Must always be exactly 1. Zero means cluster unavailability; more than one indicates split-brain.

Integrate with your existing stack by configuring Prometheus scraping on the kafka-exporter service. Build Grafana dashboards using the official Strimzi mixin or community templates. For deeper tracing, instrument producers and consumers with OpenTelemetry to correlate message flow across microservices — see OpenTelemetry as the observability standard for implementation patterns.

Log aggregation matters equally. Configure structured logging in broker pods to emit JSON, making it parseable by Loki or Elasticsearch. Include correlation IDs in log messages to trace specific messages through partition reassignments or consumer rebalances during incidents.

Next steps for running Kafka on Kubernetes with Strimzi

To successfully run Kafka on Kubernetes with Strimzi in production, start with a non-critical workload to validate your storage class, network policies, and monitoring alerts before migrating core business streams. Treat your Kafka CRDs as code: store them in Git, review changes via pull requests, and deploy through your CI/CD pipeline just like application code. This discipline transforms Kafka from an ops burden into a reliable platform capability.

If your team needs help designing a compliant, observable Kafka deployment on Kubernetes — especially for regulated workloads in Nepal or multi-cloud environments — reach out to discuss your architecture. I help teams build streaming platforms that pass audits and survive traffic spikes without 3 AM pages.