Mit KRaft hat Apache Kafka seine Architektur grundlegend modernisiert: Die ehemals zentrale Abhängigkeit von ZooKeeper entfällt, Metadaten werden direkt im Kafka-Cluster verwaltet. Für Architekt:innen, Admins und DevOps-Teams bedeutet das neue Betriebsmodelle, andere Failure-Szenarien – aber auch deutlich mehr Konsistenz und Vereinheitlichung. Dieser Artikel beleuchtet, wie KRaft funktioniert, welche Auswirkungen es auf Design und Betrieb von Kafka-Landschaften hat und worauf Sie bei Migrationen achten sollten.

Begriffserklärung & Einleitung

KRaft steht für Kafka Raft und bezeichnet das in Apache Kafka integrierte Konsensprotokoll, das ZooKeeper als Metadaten- und Koordinationsschicht vollständig ablöst. Technisch basiert KRaft auf einer Variante des Raft-Konsensalgorithmus und wurde im Rahmen von KIP-500 eingeführt, um Kafka von der externen Abhängigkeit zu ZooKeeper zu befreien.

Seit Kafka 4 wird ZooKeeper nicht mehr unterstützt; die Metadatenverwaltung erfolgt ausschließlich im KRaft-Modus. Damit konsolidiert Kafka Controller-Logik, Cluster-Metadaten und Konfigurationsmanagement in einer einheitlichen Architektur.

Für Unternehmen mit bestehenden ZooKeeper-basierten Clustern ist KRaft kein optionales Feature, sondern ein strategischer Migrationspfad. Gleichzeitig verändert KRaft Planungs- und Betriebsfragen: Cluster-Größen, Verfügbarkeitskonzepte und Security-Modelle lassen sich nun konsistenter denken, da es nur noch einen Technologie-Stack (Kafka selbst) gibt.

Funktionsweise & technische Hintergründe

KRaft als integrierte Konsensschicht

In der KRaft-Architektur gibt es kein separates ZooKeeper-Cluster mehr. Stattdessen existiert ein quorum-basierter Controller-Verbund, der den Clusterzustand mithilfe eines Raft-ähnlichen Protokolls repliziert.

Zentrale Bausteine:

• Controller-Quorum
  Eine ungerade Anzahl spezialisierter KRaft-Controller-Knoten (z. B. 3 oder 5) repliziert den Metadatenlog. Einer ist der Leader, die anderen Follower. Schreiboperationen (z. B. Topic-Erstellung) gelten erst nach Bestätigung durch die Mehrheit als committed.
• Metadaten-Log & Snapshots
  Metadaten (Topics, Partitionen, ACLs, Konfigurationen etc.) werden als Ereignisse in einen speziellen Log geschrieben, der intern ebenfalls als Kafka-Topic realisiert ist. Periodische Snapshots verhindern, dass dieser Log unbegrenzt wächst.
• Event-getriebene Controller-Logik
  KRaft-Controller führen ihren Zustand aus dem Metadatenlog, nicht aus externen Stores. Beim Leaderwechsel muss kein State aus ZooKeeper geladen werden; der Controller hat den benötigten Status bereits im Speicher.
  
  

Prozessrollen und Konfiguration im KRaft-Modus

In KRaft wird über process.roles festgelegt, ob ein Node Broker, Controller oder beides ist. Typisch sind zwei Patterns:

• Dedicated Controller-Quorum (empfohlen für größere Cluster)
• Combined Broker/Controller Nodes (für kleinere Umgebungen, Tests, Dev)

Ein vereinfachtes Beispiel für eine Node-Konfiguration im KRaft-Modus:

# Node-Rolle
process.roles=broker,controller
node.id=1

# Quorum-Konfiguration
controller.quorum.voters=1@kafka1:9093,2@kafka2:9093,3@kafka3:9093
controller.listener.names=CONTROLLER

# Listener
listeners=PLAINTEXT://:9092,CONTROLLER://:9093

# Metadaten-Version (Feature-Level des Clusters)
metadata.version=4.0

Wichtige Punkte:

• node.id ersetzt die alte Broker-ID-Generierung via ZooKeeper.
• controller.quorum.voters definiert explizit die KRaft-Controller.
• metadata.version steuert Feature-Kompatibilität und Upgrade-Verhalten.
  
  

Migration von ZooKeeper zu KRaft

Die Migration erfolgt typischerweise in mehreren Phasen:

1. Dual-Write/Migration Mode aktivieren
   Broker werden so konfiguriert, dass sie sowohl mit ZooKeeper als auch mit dem KRaft-Quorum sprechen. Metadaten werden parallel nach ZooKeeper und in den KRaft-Metadatenlog geschrieben.
2. Broker schrittweise auf KRaft-Modus umstellen
   ZooKeeper-Konfiguration entfernen, KRaft-Controller konfigurieren. Rolling Restart, bis alle Broker im KRaft-Modus laufen.
3. Finalisierung & Abschaltung von ZooKeeper
   KRaft-Controller so konfigurieren, dass keine Dual-Writes mehr stattfinden. ZooKeeper-Cluster deprovisionieren.

Cloud-Provider wie Amazon MSK unterstützen teilweise keine In-Place-Migration; dort sind oft Cluster-Neuaufbau und Umzug der Workloads nötig.

Anwendungsbeispiele in der Praxis

Event-Streaming-Plattform im Rechenzentrum (On-Premises)

In großen On-Prem-Umgebungen mit mehreren Hundert oder Tausenden Topics vereinfacht KRaft die Architektur: Weniger Komponenten, kein ZooKeeper-Cluster mehr, einheitliches Security- und Monitoring-Konzept sowie bessere Planbarkeit von Upgrades, da die Metadaten-Schicht Teil des Kafka-Stacks ist. Architekt:innen können KRaft nutzen, um heterogene ZooKeeper-Installationen zu konsolidieren und gleichzeitig die Grundlage für künftige Kafka-Versionen zu legen.

Managed Kafka in der Public Cloud

In Managed-Services-Szenarien spielen KRaft-spezifische Details für Nutzer:innen oft „unter der Haube“. Dennoch sind Aspekte wie Backup-/Restore-Strategien für Metadaten, das neue Fehler- und Kapazitätsverhalten des Controller-Quorums und Migrationspfade von älteren ZooKeeper-basierten Cluster-Versionen auf aktuelle KRaft-only-Versionen relevant.

Edge- und kleinere Dev-/Test-Cluster

Für kleinere Edge-Deployments oder Dev-Umgebungen ist KRaft interessant, weil man single-process-Setups aufbauen kann: ein Node, der Broker und Controller vereint. Die Einstiegshürde sinkt, da kein separates ZooKeeper-Cluster mehr betrieben werden muss.

Vorteile und Herausforderungen

Vorteile von KRaft

• Vereinfachte Architektur
  Wegfall von ZooKeeper reduziert die Zahl kritischer Komponenten und damit die Komplexität im Betrieb.
• Konsistentes Security-Modell
  Es gibt nur noch ein zentrales Rechte- und Zertifikatsmanagement für Kafka. ACLs und Authentifizierung werden einheitlich im Kafka-Stack gehandhabt.
• Bessere Skalierbarkeit & Cluster-Sizing
  KRaft ermöglicht „right-sized clusters“: Controller-Quorum und Broker können getrennt skaliert werden, um Latenz- und Durchsatzanforderungen zu erfüllen.
• Schnellere Controller-Failover
  Da der Controller-Status als replizierter Metadatenlog vorliegt, sind Leadership-Wechsel wesentlich schneller und deterministischer.
• Einfachere lokale Setups
  Entwickler:innen können lokal Kafka ohne ZooKeeper starten, was Onboarding und CI/CD-Umgebungen vereinfacht.
  
  

Herausforderungen und Risiken

• Migrationskomplexität
  Live-Migrationen von produktiven ZooKeeper-Clustern zu KRaft erfordern sorgfältige Planung, Rolling-Strategien und Tests. Nicht alle Cloud-Angebote unterstützen reibungslose In-Place-Upgrades.
• Neues Betriebs- und Fehlerbild
  Teams müssen KRaft-spezifische Metriken, Logging und Failure-Szenarien verstehen (z. B. Quorum-Verlust, Metadatenlog-Korruption, Snapshot-Failure).
• Konfigurationsänderungen
  Zahlreiche ZooKeeper-bezogene Parameter sind obsolet; neue Properties für KRaft müssen verstanden und korrekt gesetzt werden.
• Tooling & Ökosystem
  Monitoring- und Operations-Tools müssen an KRaft angepasst werden: neue MBeans, neue Metriken und geänderte Upgradepfade.
  
  

Alternative Lösungen

KRaft ist heute der Standardweg für Metadatenkonsens in Apache Kafka, aber im breiteren Streaming- und Messaging-Ökosystem existieren Alternativen:

• Kafka im ZooKeeper-Modus (Legacy)
  Für ältere Versionen weiterhin relevant, aber de facto ein Auslaufmodell. ZooKeeper wurde in Kafka 4 entfernt, sodass ein Weiterbetrieb langfristig nicht möglich ist.
• Andere Streaming-Plattformen mit integrierter Koordination
  Systeme wie Apache Pulsar oder Redpanda nutzen eigene Architekturen und Konsensmechanismen; je nach Use Case kann eine andere Plattform sinnvoller sein.
• Managed Services mit eigener Control-Plane
  Manche Cloud-Plattformen kapseln den Konsens-Mechanismus komplett; aus Sicht der Kund:innen steht dann ein „Kafka-kompatibler“ Dienst ohne direkten Zugriff auf die interne KRaft- oder Raft-Implementierung bereit.

Für Organisationen, die bereits stark in Kafka investiert haben, ist KRaft allerdings der natürliche Evolutionspfad innerhalb des bestehenden Ökosystems.

Fazit mit kritischer Bewertung

KRaft ist mehr als ein technisches Detail – es markiert den Übergang von Apache Kafka zu einer konsistenteren, eigenständigen Plattform ohne externe Koordinationsschicht. Durch die Ablösung von ZooKeeper, einheitliche Security- und Konfigurationsmodelle und eine moderne Raft-basierte Metadatenreplikation steigert KRaft die Wartbarkeit und Skalierbarkeit von Kafka-Clustern erheblich.

Für Architekt:innen schafft KRaft klarere Architektur-Blueprints: weniger kritische Komponenten, klar definierte Rollen (Broker vs. Controller) und planbare Migrationspfade. Für Admins und SREs bedeutet KRaft neue Metriken und Failure-Szenarien, aber auch geringere operative Komplexität und schnellere Failover. Für Entscheider:innen ist KRaft ein wichtiges Signal: Investitionen in Kafka bleiben zukunftssicher, erfordern aber kurz- bis mittelfristig Budget und Ressourcen für Migration und Schulung der Teams.

Strategisch führt für produktiv eingesetztes Kafka langfristig kein Weg an KRaft vorbei. Wer frühzeitig KRaft-Cluster aufbaut, Migrationspfade testet und Betriebsprozesse anpasst, reduziert Risiken und schafft die Grundlage für eine robuste, moderne Event-Streaming-Plattform.

Autor

Michael Deinhard

Artikel erstellt: 13.01.2026
Artikel aktualisiert: 14.01.2026

zurück zur Übersicht