Run Kafka on Kubernetes with Strimzi

By Kokil Thapa | Last reviewed: September 2026

Event-driven systems need a broker that survives node failures, scales with traffic, and stays operable under load. To run Kafka on Kubernetes with Strimzi, you install a cluster-scoped operator that watches custom resources and reconciles brokers, ZooKeeper or KRaft controllers, listeners, and topics into a working Apache Kafka deployment. If you are new to the broker itself, start with Apache Kafka fundamentals before touching cluster YAML. This guide walks through a production-minded path on any conformant Kubernetes cluster, including EKS, bare-metal, or managed offerings.

What is Strimzi and why should you run Kafka on Kubernetes with Strimzi?

Strimzi is a Kubernetes operator for Apache Kafka. It extends the API with CRDs such as Kafka, KafkaTopic, KafkaUser, and KafkaConnect. You declare desired state in YAML. The operator creates StatefulSets, Services, ConfigMaps, and certificates to match that state.

Running Kafka by hand on Kubernetes is painful. You must handle broker IDs, inter-broker TLS, log directories on persistent volumes, and rolling restarts without losing quorum. Strimzi encodes those operations into tested reconciliation loops. That is why most teams that run Kafka on Kubernetes with Strimzi choose the operator instead of raw StatefulSet manifests.

Strimzi also ships Entity Operator components for topic and user management. Topic creation stays declarative. ACLs and TLS credentials stay in sync with your KafkaUser objects. For teams comparing brokers, see RabbitMQ vs Kafka before committing to Kafka on cluster.

Strimzi vs manual Kafka on Kubernetes

The operator pattern is documented in the Kubernetes operator concept guide. Strimzi applies that model specifically to Kafka. For storage decisions that affect broker performance, read Kubernetes persistent volumes and storage and OpenEBS for Kubernetes storage.

How do you install the Strimzi Kafka operator on Kubernetes?

Start with a cluster that meets Strimzi requirements. You need a supported Kubernetes version, a default StorageClass for broker logs, and enough CPU and memory for at least three brokers in production. A three-broker cluster with replication factor three tolerates one broker loss without data unavailability.

Install from the official release bundle

Download the install YAML for your Strimzi version from the Strimzi documentation. Apply cluster-scoped CRDs first, then namespace-scoped operator resources.

1. Create a dedicated namespace, commonly kafka.
2. Apply CRD manifests from the release bundle.
3. Deploy the Cluster Operator into the namespace.
4. Verify the operator pod is running before creating a Kafka resource.

kubectl create namespace kafka

kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka

kubectl get pods -n kafka
kubectl wait --for=condition=Ready pod -l name=strimzi-cluster-operator -n kafka --timeout=300s

On shared clusters, restrict who can create Kafka resources through Kubernetes RBAC. The operator needs permissions to manage StatefulSets, Services, Secrets, and PVCs in watched namespaces.

GitOps-friendly installation

Teams using Argo CD GitOps for Kubernetes typically commit the operator manifests and a kustomization overlay. Pin the Strimzi version in Git. Upgrade the operator before bumping broker Kafka versions. Never let Argo auto-sync a major Strimzi jump without reading the release notes.

How do you deploy a Kafka cluster with Strimzi custom resources?

The core object is the Kafka CR. It defines Kafka version, broker replicas, listeners, storage, and metadata mode. Modern deployments use KRaft mode, which removes the ZooKeeper dependency. Check your Strimzi release notes for the exact KRaft support matrix before choosing metadata mode.

Minimal production-shaped Kafka manifest

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: prod-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: 100Gi
          deleteClaim: false
  entityOperator:
    topicOperator: {}
    userOperator: {}

Apply the manifest and watch reconciliation:

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

Define topics declaratively with KafkaTopic. This prevents ad-hoc topic creation with wrong partition counts. Partition count affects parallelism for consumers; see Kafka consumer groups and partitions for sizing guidance.

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: orders-events
  namespace: kafka
  labels:
    strimzi.io/cluster: prod-cluster
spec:
  partitions: 12
  replicas: 3
  config:
    retention.ms: 604800000
    cleanup.policy: delete

Application teams often produce JSON payloads. Validate schemas in CI with a JSON formatter and validator before publishing to Kafka. Bad payloads at scale are expensive to replay.

How do you configure storage, networking, and security for Strimzi Kafka?

Storage is the most common production failure point. Kafka brokers are write-heavy. Place PVCs on fast SSD-backed StorageClasses. Set deleteClaim: false on production volumes so accidental cluster deletion does not wipe logs. Snapshot PVCs regularly; pair Strimzi with Velero backup and restore for Kubernetes and volume snapshot workflows from volume snapshots in Kubernetes.

Resource requests and limits

Under-provisioned brokers cause long GC pauses and ISR shrink events. Set CPU and memory requests based on measured throughput, not guesses. Read Kubernetes resource limits and requests before applying defaults. A starting point for moderate traffic is 4 vCPU and 8 GiB RAM per broker, then tune with metrics.

  kafka:
    resources:
      requests:
        memory: 8Gi
        cpu: "2"
      limits:
        memory: 8Gi
        cpu: "4"

Networking and ingress

Internal listeners serve in-cluster producers and consumers. External listeners expose Kafka outside the cluster through LoadBalancer, NodePort, or Ingress routes. Pick the model that matches your cloud or on-prem setup. For ingress-based routing patterns, see Kubernetes ingress controllers explained.

Lock down east-west traffic with Kubernetes network policies. Allow only application namespaces to reach broker ports. Deny everything else by default.

TLS, authentication, and authorization

Enable TLS on every listener that crosses a trust boundary. Strimzi can generate a cluster CA automatically. For enterprise PKI, integrate cert-manager. Create per-application credentials with KafkaUser:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: checkout-service
  namespace: kafka
  labels:
    strimzi.io/cluster: prod-cluster
spec:
  authentication:
    type: tls
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: orders-events
          patternType: literal
        operations:
          - Read
          - Write
          - Describe

Mount the generated Secret into your application pod as keystore and truststore files. Rotate credentials by updating the KafkaUser and rolling app pods. Never share one Kafka user across unrelated services.

How do you connect applications and tune performance after deployment?

Producers and consumers inside the cluster should use the internal bootstrap service Strimzi creates. The address follows the pattern prod-cluster-kafka-bootstrap.kafka.svc:9093 for TLS listeners. Configure client properties for acks, retries, and idempotence based on your delivery guarantees.

Laravel and PHP applications can publish domain events to Kafka through rdkafka or HTTP bridge patterns. For container basics around deploying those apps, see Kubernetes for Laravel getting started. On marketplace platforms like Gulfbizlist, event streams decouple listing updates from search indexing workers.

Monitoring and alerting

Export broker metrics with Strimzi's KafkaExporter or JMX Prometheus rules. Watch these signals:

• Under-replicated partitions — should stay at zero in healthy clusters.
• Offline partitions — immediate page; consumers stall.
• Request handler idle ratio — sustained low values mean CPU saturation.
• Disk usage on PVCs — expand volumes before brokers reject writes.

Pair metrics with log aggregation. Broker logs explain leader elections and slow replicas that dashboards alone miss.

How do you upgrade, scale, and troubleshoot Strimzi Kafka on Kubernetes?

Upgrades are two-step: operator first, Kafka version second. Edit the Kafka CR spec.kafka.version field. Strimzi rolls brokers one at a time. Ensure min.insync.replicas and replication factors stay compatible during the roll.

Scaling brokers and disks

Increase spec.kafka.replicas to add brokers. Reassign partitions with Cruise Control if enabled, or use kafka-reassign-partitions.sh. Expand PVCs only if your StorageClass supports volume expansion. JBOD volumes add disks without replacing existing claims.

Common failure modes

Brokers stuck in CrashLoopBackOff often trace to corrupt logs or wrong storage mounts. Follow debug a CrashLoopBackOff in Kubernetes systematically. Check kubectl describe pod events first.

ISR shrink loops usually mean slow disks or network latency between zones. Avoid spreading brokers across availability zones unless your SLA requires it. Cross-AZ traffic adds latency that hurts Kafka.

Operator reconcile errors appear in Cluster Operator logs. A typo in listener config blocks the entire cluster reconcile. Validate YAML in CI. Use Kubernetes troubleshooting field guide patterns for systemic issues.

For long-running operational ownership, many teams engage support and maintenance services or Linux system administration. Building the full event platform — brokers plus services — falls under enterprise application development. Booking systems such as Adventure Third Pole Trek benefit from reliable async pipelines during peak season traffic.

Consult the Apache Kafka documentation for broker configuration semantics that Strimzi passes through unchanged. Strimzi wraps operations; it does not replace Kafka tuning knowledge.

Key Takeaways

• Install Strimzi CRDs and the Cluster Operator in a dedicated namespace before creating any Kafka resource.
• Use three or more brokers, replication factor three, and min.insync.replicas: 2 for production durability.
• Keep broker logs on fast SSD PVCs with deleteClaim: false and regular snapshots.
• Enable TLS and KafkaUser ACLs per application; never share cluster-wide credentials.
• Upgrade the Strimzi operator first, then bump spec.kafka.version and watch rolling restarts.
• Monitor under-replicated partitions, disk usage, and handler idle ratio — alert before clients fail.

People Also Ask

Does Strimzi support KRaft without ZooKeeper?

Yes. Recent Strimzi releases support KRaft mode for Kafka metadata, removing ZooKeeper pods from the cluster. Check the Strimzi version matrix against your target Kafka release before migrating. Greenfield deployments in 2026 should prefer KRaft when your operator version supports it.

Can Strimzi run Kafka on minimal clusters like k3s?

Strimzi runs on any conformant Kubernetes distribution, including lightweight setups covered in k3s lightweight Kubernetes. Production Kafka still needs sufficient CPU, memory, and SSD storage. A single-node lab cluster is fine for learning; do not use it as a production template.

How do external clients connect to Strimzi Kafka?

Configure an external listener type on the Kafka CR — LoadBalancer, NodePort, or route-based ingress depending on your platform. Clients use the bootstrap address and TLS certificates from a KafkaUser Secret. Document connection strings per environment so mobile and SaaS consumers do not hard-code internal DNS names.

What backup strategy works for Strimzi Kafka?

Combine PVC snapshots with metadata backups of topic configs and ACLs stored in Git as CRDs. Velero covers namespace-level disaster recovery. Message data retention is governed by topic retention.ms; snapshots capture point-in-time broker state for catastrophic failure scenarios.

Run Kafka on Kubernetes with Strimzi in production

You now have a complete path to run Kafka on Kubernetes with Strimzi: operator install, declarative cluster and topic resources, hardened networking, and rolling upgrade discipline. Start in a staging namespace, load-test with realistic producer batch sizes, and promote the same Git-managed manifests to production through your CI pipeline.

Need help designing event-driven architecture, integrating Kafka with your application stack, or operating brokers on managed Kubernetes? Contact us to discuss your workload, or explore related guides on Kubernetes performance tuning and horizontal pod autoscaling.