Apache Kafka + Kubernetes
Apache Kafka auf Kubernetes betreiben
Architektur, Strimzi, Monitoring und Security für den stabilen Produktivbetrieb einer Kafka-Plattform.
Observability
- Prometheus
- JMX Exporter
- Kafka Exporter
- Grafana
- Alerting
Security
- TLS
- mTLS / SCRAM / OAuth
- ACLs
- RBAC
- Network Policies
Lifecycle
- Upgrades
- Zertifikatsrotation
- Skalierung
- Rebalancing
Grundlagen
Warum Apache Kafka auf Kubernetes?
Ist Kubernetes bereits die Standardplattform, lässt sich Kafka in dieselben Betriebsprozesse einbinden, statt eine separate Umgebung auf eigenen VMs zu pflegen.
- 01
Standardisierte Plattform
Kafka nutzt Nodes, Storage-Klassen sowie Netzwerk- und Sicherheitsvorgaben des bestehenden Clusters. Broker laufen als Pods mit Persistent Volumes. Fällt ein Broker-Pod aus, startet Kubernetes ihn neu. Ist das Volume weiterhin verfügbar, repliziert der Broker anschließend nur die fehlenden Daten nach.
- 02
Deklarative Automatisierung
Kafka-Cluster, Topics und Benutzer werden als Kubernetes-Ressourcen beschrieben. Ein Kafka Operator gleicht den Soll-Zustand fortlaufend mit dem Ist-Zustand ab und führt Änderungen wie Rolling Updates kontrolliert aus.
- 03
Integration & Observability
Bestehende Werkzeuge für Monitoring, Logging, Secret Management und Zugriffskontrolle lassen sich auch für Kafka nutzen. Neben der Plattform entsteht keine separate Betriebsumgebung.
- 04
Portabilität & Infrastructure as Code
Die Konfiguration liegt versioniert in Git und wird per GitOps ausgerollt, etwa mit Argo CD oder Flux. Dieselben Manifeste lassen sich auf AKS, STACKIT SKE, OpenShift oder im eigenen Rechenzentrum einsetzen. Unterschiede betreffen vor allem Storage-Klassen und den externen Zugriff.
Operator
Strimzi: Kafka Operator für Kubernetes
Strimzi ist ein Open-Source-Projekt für den Betrieb von Apache Kafka auf Kubernetes und OpenShift. Der Cluster Operator übersetzt Custom Resources in Pods, Services, Secrets und Broker-Konfiguration und gleicht Abweichungen fortlaufend ab. MILEO SYSTEMS setzt Strimzi ein, hat es aber nicht entwickelt.
Kafka- Clusterweite Konfiguration: Kafka-Version, Listener, Authentifizierung, Autorisierung und Broker-Einstellungen.
KafkaNodePool- Gruppen von Knoten mit Rolle (Broker, Controller oder beides), Anzahl, Ressourcen und Storage. Aktuelle Strimzi-Versionen unterstützen nur noch KRaft; ZooKeeper-basierte Cluster müssen vorher migriert werden.
KafkaTopic- Partitionen, Replication Factor und Topic-Konfiguration. Der Topic Operator überträgt Änderungen an der Ressource nach Kafka.
KafkaUser- Identität und ACLs einer Anwendung. Der User Operator legt die Zugangsdaten, je nach Verfahren Zertifikat oder Passwort, als Kubernetes Secret ab.
- Rolling Updates
- Konfigurations- und Versionsänderungen rollt der Operator Broker für Broker aus und berücksichtigt dabei die Verfügbarkeit der Partitionen.
- Zertifikate
- Strimzi erzeugt standardmäßig eigene CAs für Cluster und Clients und erneuert die Zertifikate vor Ablauf. Alternativ lassen sich eigene CAs einbinden.
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: orders labels: strimzi.io/cluster: kafka-prod spec: partitions: 12 replicas: 3 config: retention.ms: 604800000 min.insync.replicas: 2
Replication Factor 3, Retention sieben Tage. Bei acks=all und min.insync.replicas=2 wird ein Schreibvorgang nur bestätigt, wenn mindestens zwei In-Sync-Replikate verfügbar sind. Andernfalls weist der Broker ihn zurück.
Diese Aufgaben übernimmt MILEO SYSTEMS mit Managed Kafka im laufenden Betrieb.
Architektur
Typische Kafka-on-Kubernetes-Architektur
Die Nummern beziehen sich auf die Referenzarchitektur in Abb. 1. Broker-Anzahl, Replication Factor und Listener richten sich nach Last und Verfügbarkeitsanforderungen.
- 1Operator
- Läuft im selben Cluster und benötigt Berechtigungen für Pods, Services, Secrets und Custom Resources. Die überwachten Namespaces lassen sich einschränken.
- 2Broker und Storage
- Jeder Broker erhält ein eigenes Persistent Volume. Die Storage-Klasse sollte niedrige Latenz bieten und Volume-Erweiterung unterstützen. Mit Rack Awareness verteilt Kafka die Replikate einer Partition auf verschiedene Zonen, sodass der Ausfall einer Zone nicht alle Replikate betrifft.
- 3Topics
- Die Anzahl der Partitionen bestimmt die Parallelität, der Replication Factor die Ausfallsicherheit. Der Replication Factor ist unabhängig von der Broker-Anzahl, kann sie aber nicht überschreiten.
- 4Zugriff
- Clients innerhalb des Clusters verbinden sich über einen Kubernetes Service. Für externe Clients stellt Strimzi Listener vom Typ LoadBalancer, NodePort, Ingress oder Route (OpenShift) bereit.
Monitoring
Kafka Monitoring auf Kubernetes
Kafka stellt Broker-Metriken über JMX bereit; Strimzi kann dafür den Prometheus JMX Exporter konfigurieren. Consumer Lag liefert der Kafka Exporter. Prometheus und Grafana sind verbreitet, aber keine Voraussetzung. Entscheidend sind aussagekräftige Signale und belastbare Schwellenwerte.
| Signal | Bedeutung | Bewertung |
|---|---|---|
| Consumer Lag | Rückstand einer Consumer Group gegenüber dem neuesten Offset je Partition | Als Trend bewerten. Anhaltend steigender Lag ist aussagekräftiger als kurzfristige Spitzen. |
| Under-Replicated Partitions | Partitionen, deren Replikate nicht vollständig synchron sind | Im Normalbetrieb 0, bei Rolling Updates kurzzeitig erhöht. Ein dauerhaft erhöhter Wert reduziert die Ausfallsicherheit. |
| Offline Partitions | Partitionen ohne verfügbaren Leader | Jeder Wert über 0 erfordert sofortiges Handeln: Diese Partitionen sind weder lesbar noch beschreibbar. |
| Broker Availability | Anzahl der aktiven Broker im Kafka-Cluster | Mit der erwarteten Anzahl abgleichen. Ein laufender Pod bedeutet nicht zwingend, dass der Broker aktiv am Cluster teilnimmt. |
| Disk Usage | Belegung der Persistent Volumes je Broker | Erschöpfte Kapazität beeinträchtigt Schreibvorgänge und den stabilen Broker-Betrieb. Auslastung und Wachstum frühzeitig überwachen, Retention prüfen. |
| Request Latency | Antwortzeiten von Produce- und Fetch-Requests | Perzentile wie p99 auswerten, nicht Durchschnittswerte. |
Außerdem relevant: Throughput als Grundlage der Kapazitätsplanung, JVM Heap und Garbage Collection, CPU- und Memory-Nutzung im Verhältnis zu Requests und Limits sowie häufige ISR-Änderungen als frühes Warnsignal.
Security
Kafka Security auf Kubernetes
Ein Listener ohne TLS, Authentifizierung und Autorisierung akzeptiert Verbindungen von jedem Pod, der ihn über das Netzwerk erreicht. In einem gemeinsam genutzten Cluster ist interne Erreichbarkeit kein ausreichender Schutz.
- 01
Transport SecurityTLS / Encryption
Strimzi verschlüsselt die interne Kommunikation zwischen Brokern und Controllern per TLS. Für Client-Listener wird TLS je Listener aktiviert.
- 02
IdentitymTLS / SCRAM / OAuth
Clients authentifizieren sich per mTLS, SCRAM-SHA-512 oder OAuth 2.0. Jede Anwendung erhält eine eigene Identität statt gemeinsam genutzter Zugangsdaten.
- 03
AuthorizationKafka ACLs / KafkaUser
Bei aktivierter Autorisierung werden ACLs über
KafkaUser-Ressourcen verwaltet, etwa Lese- und Schreibrechte je Topic oder der Zugriff auf Consumer Groups. Ohne Autorisierung hat jeder authentifizierte Client Vollzugriff. - 04
Platform SecurityKubernetes RBAC / Network Policies / Secrets
Network Policies begrenzen, welche Pods die Broker erreichen. Kubernetes RBAC regelt, wer Kafka-Ressourcen ändern darf. Wer
KafkaUser-Ressourcen anlegen darf, kann sich selbst Berechtigungen erteilen. Zugangsdaten liegen als Kubernetes Secrets oder in einem vorhandenen Secret Store.
Strimzi erneuert Cluster- und Client-CA innerhalb eines konfigurierbaren Zeitfensters vor Ablauf. Clients, die der CA vertrauen, müssen das neue CA-Zertifikat rechtzeitig übernehmen, sonst schlagen Verbindungen nach der Rotation fehl. Bei eigenen CAs liegt die Erneuerung beim Betreiber.
Day-2 Operations
Der entscheidende Teil: Day-2 Operations
Die Bereitstellung ist nur der Anfang. Im Produktivbetrieb entscheiden Monitoring, Security, Upgrades, Kapazitätsplanung und Incident-Prozesse über die Stabilität der Kafka-Plattform.
Beobachten
- Monitoring
- Alerting
- Performance-Analyse
Reagieren
- Incident Handling
- Disaster-Recovery-Konzept
- Dokumentation
Pflegen
- Upgrades
- Security Updates
- Zertifikatsrotation
Planen
- Kapazitätsplanung
- Skalierung und Rebalancing
- Lifecycle Management
Ein gelöschtes Topic ist auf allen Replikaten gelöscht. Für Disaster Recovery wird häufig MirrorMaker 2 eingesetzt, das Topics asynchron in einen zweiten Kafka-Cluster repliziert. Ob und in welchem Umfang das erforderlich ist, hängt davon ab, ob Kafka Daten dauerhaft vorhält oder nur weiterleitet.
Managed Kafka by MILEO SYSTEMS
Kafka läuft bereits auf Kubernetes?
MILEO SYSTEMS übernimmt den laufenden Betrieb Ihrer Kafka-Plattform auf Ihrer Kubernetes- oder OpenShift-Infrastruktur.
Ihre Infrastruktur.Ihre Daten.Unser Betrieb.
Kafka- und Strimzi-Lifecycle · Monitoring und Alerting · Upgrades · Zertifikate · Incident Support · Capacity Management
FAQ
Häufige Fragen zu Kafka auf Kubernetes
Ist Kubernetes für Apache Kafka geeignet?
Ja, sofern Storage und Netzwerk passen. Kafka benötigt Persistent Volumes mit niedriger Latenz und stabile Netzwerkidentitäten für die Broker. Mit einem Kafka Operator wie Strimzi ist der Betrieb auf Kubernetes ein etablierter Ansatz.
Was ist der Unterschied zwischen Kafka und Strimzi?
Apache Kafka ist die Event-Streaming-Plattform selbst. Strimzi ist ein Kafka Operator, der Kafka auf Kubernetes bereitstellt, konfiguriert und aktualisiert. Er basiert auf den Apache-Kafka-Releases und ersetzt Kafka nicht.
Kann Kafka auf OpenShift betrieben werden?
Ja. Strimzi unterstützt OpenShift, einschließlich externer Zugriffe über OpenShift Routes. Red Hat bietet mit Streams for Apache Kafka zudem eine kommerziell unterstützte Distribution auf Basis von Strimzi an.
Wie werden Kafka Broker auf Kubernetes skaliert?
Die Broker-Anzahl wird über replicas im KafkaNodePool festgelegt und ist vom Replication Factor der Topics zu unterscheiden. Zusätzliche Broker erweitern die Kapazität, bestehende Partitionen werden standardmäßig jedoch nicht neu verteilt. Dafür ist ein Rebalancing erforderlich, etwa mit Cruise Control über die Ressource KafkaRebalance. Vor dem Entfernen eines Brokers müssen dessen Partitionen verschoben werden.
Wie funktionieren Kafka Upgrades mit Strimzi?
Zunächst wird der Strimzi Operator aktualisiert, anschließend die Kafka-Version in der Kafka-Ressource. Der Operator führt daraufhin ein Rolling Update der Broker durch. Welche Kafka- und Kubernetes-Versionen unterstützt werden, hängt von der Strimzi-Version ab und ist vor jedem Upgrade zu prüfen.
Kann MILEO SYSTEMS eine bestehende Kafka-Plattform übernehmen?
Das bewerten wir im Onboarding anhand von Versionen, Konfiguration, Zustand und bestehenden Betriebsprozessen. Daraus ergibt sich, ob die Kafka-Plattform direkt in den laufenden Betrieb übergeht oder zuvor modernisiert wird.
Kann Kafka vollständig in unserer eigenen Infrastruktur bleiben?
Ja. Kafka läuft in Ihrem Kubernetes- oder OpenShift-Cluster, im eigenen Rechenzentrum oder in Ihrer Cloud-Umgebung. Die Nachrichtendaten verbleiben in Ihrer Infrastruktur.
Weiterlesen
Weitere Kafka-Themen
Kafka auf Kubernetes. Produktionsreif betrieben.
Sie planen Kafka auf Kubernetes oder betreiben bereits eine Kafka-Plattform? Wir unterstützen bei Architektur, Einführung und laufendem Betrieb.