Veröffentlicht am

Apache Kafka auf Kubernetes mit Strimzi betreiben

Teilen:
Authors

TL;DR

Strimzi ist ein Kubernetes Operator, der Apache Kafka vollständig über Custom Resources verwaltet. Du definierst Kafka-Cluster, Topics und User als YAML — Strimzi kümmert sich um Deployment, Rolling Updates und Zertifikate. Diese Anleitung zeigt Installation, Cluster-Setup und erste Producer/Consumer-Tests.


Apache Kafka auf Kubernetes mit Strimzi

Kafka auf VMs zu betreiben ist aufwändig: ZooKeeper-Ensemble pflegen, Broker manuell skalieren, TLS-Zertifikate rotieren. Strimzi löst das, indem es Kafka als nativen Kubernetes-Workload behandelt. Ein Operator überwacht Custom Resources und hält den gewünschten Zustand aufrecht.

Voraussetzungen

  • Kubernetes-Cluster (ab v1.23)
  • kubectl konfiguriert
  • Mindestens 8 GB RAM im Cluster verfügbar
  • Storage Class für Persistent Volumes

Cluster-Verbindung prüfen:

kubectl cluster-info
kubectl get storageclass

Strimzi Operator installieren

Die einfachste Methode ist die Installation über die offiziellen YAML-Manifeste. Alternativ geht es per Helm oder OLM.

# Namespace für Kafka erstellen
kubectl create namespace kafka

# Strimzi 0.44.0 installieren (aktuellste Version auf github.com/strimzi prüfen)
kubectl create -f https://strimzi.io/install/latest?namespace=kafka -n kafka

# Warten bis der Operator läuft
kubectl wait --for=condition=Ready pod -l name=strimzi-cluster-operator -n kafka --timeout=180s

Der Operator beobachtet nun alle Namespaces auf Kafka-CRDs. Prüfe den Status:

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

Du solltest CRDs wie kafkas.kafka.strimzi.io, kafkatopics.kafka.strimzi.io und weitere sehen.

Kafka-Cluster deployen

Strimzi nutzt die Custom Resource Kafka für die Cluster-Definition. Hier ein produktionsnahes Setup mit drei Brokern und KRaft-Modus (ohne ZooKeeper):

# kafka-cluster.yaml
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: broker
  namespace: kafka
  labels:
    strimzi.io/cluster: production-cluster
spec:
  replicas: 3
  roles:
    - broker
    - controller
  storage:
    type: persistent-claim
    size: 20Gi
    class: standard
    deleteClaim: false
  resources:
    requests:
      memory: 2Gi
      cpu: 500m
    limits:
      memory: 2Gi
      cpu: "1"
---
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: production-cluster
  namespace: kafka
  annotations:
    strimzi.io/node-pools: enabled
    strimzi.io/kraft: enabled
spec:
  kafka:
    version: 3.9.0
    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
      log.retention.hours: 168
  entityOperator:
    topicOperator: {}
    userOperator: {}

Cluster erstellen und warten:

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

Das dauert einige Minuten. Strimzi erstellt StatefulSets, Services, ConfigMaps und optional TLS-Zertifikate.

KomponenteAnzahlFunktion
Broker Pods3Kafka-Broker mit Controller-Rolle (KRaft)
Entity Operator1Verwaltet Topics und User
PVCs3Persistenter Storage pro Broker

Topics verwalten

Topics werden als KafkaTopic-Ressource deklarativ verwaltet. Der Topic Operator synchronisiert sie automatisch mit dem Cluster.

# kafka-topic.yaml
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: order-events
  namespace: kafka
  labels:
    strimzi.io/cluster: production-cluster
spec:
  partitions: 6
  replicas: 3
  config:
    retention.ms: 604800000     # 7 Tage
    cleanup.policy: delete
    compression.type: lz4
    max.message.bytes: 1048576  # 1 MB
kubectl apply -f kafka-topic.yaml

# Topics auflisten
kubectl get kafkatopic -n kafka

Partitionen lassen sich nachträglich erhöhen (nie verringern). Ändere einfach partitions in der YAML und wende sie erneut an.

Producer und Consumer testen

Strimzi liefert Container-Images für schnelle Tests mit. Starte einen Producer:

# Producer starten
kubectl run kafka-producer -ti --rm \
  --image=quay.io/strimzi/kafka:latest-kafka-3.9.0 \
  --namespace=kafka \
  -- bin/kafka-console-producer.sh \
    --bootstrap-server production-cluster-kafka-bootstrap:9092 \
    --topic order-events

In einem zweiten Terminal den Consumer:

# Consumer starten
kubectl run kafka-consumer -ti --rm \
  --image=quay.io/strimzi/kafka:latest-kafka-3.9.0 \
  --namespace=kafka \
  -- bin/kafka-console-consumer.sh \
    --bootstrap-server production-cluster-kafka-bootstrap:9092 \
    --topic order-events \
    --from-beginning

Nachrichten im Producer-Terminal eingeben — sie erscheinen sofort beim Consumer.

Persistenz und Skalierung

Strimzi verwendet Persistent Volume Claims für Broker-Daten. Beim Neustart eines Pods bleiben alle Partitionen erhalten. Für die Skalierung gibt es zwei Ansätze:

Vertikal: Mehr Ressourcen pro Broker zuweisen. Ändere resources in der KafkaNodePool-Spec. Strimzi führt ein Rolling Update durch.

Horizontal: Broker-Anzahl erhöhen. Ändere replicas im KafkaNodePool. Neue Broker starten automatisch, aber bestehende Partitionen werden nicht umverteilt. Dafür brauchst du KafkaRebalance:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaRebalance
metadata:
  name: rebalance-after-scale
  namespace: kafka
  labels:
    strimzi.io/cluster: production-cluster
spec:
  mode: full
  goals:
    - RackAwareGoal
    - ReplicaCapacityGoal
    - DiskCapacityGoal
SkalierungMethodeDowntime
Vertikalresources ändernRolling Update, keine Downtime
Horizontalreplicas erhöhenKeine Downtime, Rebalance empfohlen

Monitoring

Strimzi exportiert JMX-Metriken über einen Prometheus-Exporter. Aktiviere ihn im Kafka-CR:

spec:
  kafka:
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: kafka-metrics
          key: kafka-metrics-config.yml

Kombiniere das mit dem kube-prometheus-stack und einem Grafana-Dashboard (Strimzi stellt offizielle Dashboards bereit).

FAQ

Brauche ich noch ZooKeeper mit Strimzi?

Nein, seit Strimzi 0.40+ und Kafka 3.7+ ist KRaft der empfohlene Modus. ZooKeeper wird nicht mehr benötigt. Bei bestehenden Clustern bietet Strimzi eine Migration an.

Wie viele Broker brauche ich mindestens?

Für Production empfiehlt sich ein Minimum von drei Brokern mit min.insync.replicas: 2. So überlebt der Cluster den Ausfall eines Brokers ohne Datenverlust.

Kann ich Kafka über ClusterIP von außerhalb des Clusters erreichen?

Nein, dafür brauchst du einen Listener vom Typ nodeport, loadbalancer oder ingress. Strimzi konfiguriert dann automatisch TLS und Advertised-Listeners.

Wie führe ich ein Kafka-Version-Upgrade durch?

Ändere spec.kafka.version in der Kafka-CR. Strimzi führt automatisch ein Rolling Update durch — erst die Broker, dann das Inter-Broker-Protokoll und Log-Format. Der Cluster bleibt dabei verfügbar.


Nächster Schritt: Richte ein Topic-Monitoring ein und definiere Alerts für Consumer-Lag. Hoher Lag bedeutet, dass Consumer nicht schnell genug verarbeiten — ein typisches Frühwarnsignal für Skalierungsbedarf.

Kubernetes-Expertise gesucht?

Managed Services, Beratung, Training oder Security – wir unterstützen deutsche Unternehmen bei allen Kubernetes-Themen.

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen