What Is Kafka KRaft Mode? Architecture, Configuration, and Readiness
Kafka KRaft (Kafka Raft) is Kafka's built-in metadata layer: a small quorum of controller nodes that stores cluster metadata in an internal, replicated Kafka log. It replaces Apache ZooKeeper entirely — no external coordination system, no second cluster to run.
KRaft now appears in every modern Kafka conversation: in release notes, in the process.roles line of every new config file, in vendor migration deadlines. This post explains the thing itself — what KRaft is, how the architecture works, which properties define a KRaft node, and where it stands on production readiness.
KRaft moves cluster metadata into Kafka itself, as an event log replicated by a Raft quorum of controllers. It has been production-ready for new clusters since Kafka 3.3 and is the only mode in Kafka 4.x. It changes the coordination plane — not where your topic data lives.
What is KRaft in Kafka?
KRaft is the metadata mode, proposed in KIP-500, in which a small quorum of controller processes keeps Kafka's cluster metadata in a replicated internal log. Topic definitions, partition assignments, broker registrations, configs, and ACLs all live inside Kafka, managed by Kafka's own consensus protocol.
That work used to belong to ZooKeeper. In the old architecture, ZooKeeper elected the controller, tracked which brokers were alive, and stored the cluster's coordination state in its znode tree — What Is ZooKeeper in Kafka? covers that world in full. KRaft keeps every one of those responsibilities, but performs them inside the Kafka cluster itself.
The name answers the "kafka raft" question directly: KRaft is Kafka's own implementation of the Raft consensus algorithm. KIP-595 adapted Raft to Kafka's idioms — replication is pull-based, with followers fetching from the leader the same way Kafka replicas fetch partition data, rather than the push model described in the original Raft paper.
Kafka KRaft architecture: how metadata becomes a log
The core idea of the KRaft architecture is that cluster metadata is an event-sourced log. Every metadata change — a topic created, a config altered, a broker registered, a partition leader moved — is a record appended to an internal, single-partition topic named __cluster_metadata. The current state of the cluster is what you get by replaying that log.
Three roles operate on it:
The active controller is the leader of the metadata partition, elected by Raft from among the controller quorum. It is the only node that writes to the log, and it handles broker registrations and heartbeats.
Standby controllers are the other voters in the quorum. They replicate the metadata log and hold the current state in memory. That is why controller failover in KRaft is near-instant: a standby that wins the election already has everything loaded. In ZooKeeper mode, a newly elected controller first had to read the full cluster state out of ZooKeeper — a wait that grew with partition count.
Brokers are observers. They fetch the metadata log from the active controller, apply it to a local copy, and serve client traffic from that view.
The log itself does not grow forever. Controllers and brokers periodically write snapshots of the metadata state, so a restarting node loads the latest snapshot plus the tail of the log instead of replaying all of history.
Here is how each cluster function maps between the two architectures:
| Cluster function | ZooKeeper mode | KRaft mode |
|---|---|---|
| Controller election | ZooKeeper leader election | Raft election within the controller quorum |
| Metadata storage | Znode tree in an external ensemble | __cluster_metadata log inside Kafka |
| Broker liveness | Ephemeral znodes | Heartbeats to the active controller |
| Configs and ACLs | Znodes | Records in the metadata log |
| Client connections | Brokers, via bootstrap.servers | Unchanged — clients never touched ZooKeeper |
The last row matters for anyone worried about application impact: producers and consumers bootstrap through bootstrap.servers in both modes, so client code does not know or care which metadata plane is running.
Quorum mechanics — voter management, election tuning, observer lag — are a deeper topic than a definition post needs. This is the architecture level: a quorum of controllers, one active leader, an event log everyone else follows.
KRaft mode configuration: what defines a node
A KRaft node is defined by four properties:
process.roles— whether this node is abroker, acontroller, or both.node.id— the node's unique identifier in the cluster.controller.quorum.voters— the controller quorum, as a list ofid@host:portentries.controller.listener.names— which listeners carry controller traffic.
A dedicated controller in a three-node quorum looks like this:
process.roles=controller
node.id=1
controller.quorum.voters=1@controller1:9093,2@controller2:9093,3@controller3:9093
controller.listener.names=CONTROLLER
process.roles splits the world into two deployment shapes. Combined mode — process.roles=broker,controller in a single process — is convenient for development and testing. Production clusters run isolated mode: dedicated controller nodes, separate from the brokers, so metadata quorum health never competes with data traffic for disk and network.
How many controllers? Three for most clusters, five for large ones. A Raft quorum needs a majority to make progress, so three controllers tolerate the loss of one, and five tolerate the loss of two. Even numbers add no fault tolerance — the same rule ZooKeeper ensembles followed.
One more architectural tell: a KRaft cluster's identity is stamped into its own log directories with kafka-storage.sh format before first boot, not registered in an external tree. The full no-ZooKeeper quickstart — cluster ID generation, storage formatting, startup — is in Kafka Without ZooKeeper.
Is Kafka KRaft production ready?
Yes. KRaft has been production-ready for new clusters since Kafka 3.3 (KIP-833), and in Kafka 4.x it is the only mode that exists. The milestone history:
| Milestone | Kafka version |
|---|---|
| KRaft early access | 2.8 (2021) |
| Production-ready for new clusters (KIP-833) | 3.3 |
| ZooKeeper mode deprecated | 3.5 |
| ZooKeeper-to-KRaft migration production-ready (KIP-866) | 3.6 |
| Last release with ZooKeeper support | 3.9 |
| KRaft-only — will not start against ZooKeeper | 4.0 |
The nuance lives between the rows: what each version lets you do without ZooKeeper, including the multi-disk JBOD parity story, is the version-by-version matrix in Kafka Without ZooKeeper. Moving an existing cluster is a migration, not an upgrade — the ZooKeeper to KRaft migration guide covers the procedure on every platform, with the condensed task version at migrate ZooKeeper to KRaft. And if you want the two modes weighed side by side, that is the KRaft vs ZooKeeper comparison.
What KRaft changes for operators — and what it does not
The operational wins are real. There is one system to size, patch, secure, and monitor instead of two, and one security model instead of a Kafka-plus-ZooKeeper split. Controller failover stops being proportional to metadata size, which is what makes very large partition counts practical. And cluster identity lives in Kafka's own formatted log directories rather than in an external service.
What KRaft does not change is where your data lives. Topic data sits in partition logs on the brokers in both modes. Consumer offsets have lived in the internal __consumer_offsets topic on the brokers since Kafka 0.9 — never in ZooKeeper, never in the KRaft quorum. The metadata quorum protects metadata consistency; it does nothing for data durability. And replication is not backup, in either mode: replicas copy corruption and accidental deletion as faithfully as they copy good data.
Two implications follow. First, a KRaft cluster still needs an independent, off-cluster copy of topic data and offsets. Kafka Backup writes both to S3, S3-compatible storage, Azure Blob, GCS, or filesystem targets, with consumer group offset preservation built in and point-in-time recovery to the millisecond. Second, backups are metadata-mode-agnostic — a useful property when your road to KRaft is a new-cluster move rather than an in-place migration, the scenario the migration use case is built around.
On Kubernetes, the Kafka Backup operator is Strimzi compatible and works the same against KRaft-mode clusters.
FAQ
Frequently asked questions
What is KRaft mode in Kafka?
KRaft mode is Kafka running its own metadata layer instead of ZooKeeper. A small quorum of controller nodes stores cluster metadata — topics, partitions, configs, ACLs, broker registrations — in an internal replicated log called __cluster_metadata, and brokers follow that log to learn the cluster state.
What does KRaft stand for?
KRaft stands for Kafka Raft. It is Kafka's own implementation of the Raft consensus algorithm, proposed in KIP-500 and specified in KIP-595, adapted to use pull-based replication in the same style as Kafka's partition replication.
Is Kafka KRaft production ready?
Yes. KRaft has been production-ready for new clusters since Kafka 3.3 (KIP-833), the ZooKeeper-to-KRaft migration has been production-ready since 3.6 (KIP-866), and Kafka 4.x supports no other mode.
How many KRaft controllers does a Kafka cluster need?
Three controllers for most clusters, five for very large ones. A Raft quorum needs a majority to operate, so three controllers tolerate one failure and five tolerate two. Development and test environments can run a single combined broker-controller process.
Does KRaft change where Kafka stores topic data?
No. Topic data stays in partition logs on the brokers, and consumer offsets stay in the __consumer_offsets topic, exactly as in ZooKeeper mode. KRaft replaces the metadata plane only — so an independent backup of topic data and offsets is just as necessary in KRaft mode.
Conclusion
KRaft is not a bolt-on substitute for ZooKeeper; it is a redesign of Kafka's metadata plane around the idea Kafka already trusted most — the replicated log. Defined once: a quorum of controllers, an event-sourced metadata log, and brokers as observers that follow it. That design is what removed the external dependency, made controller failover instant, and set the ceiling on cluster size higher than the old architecture could.
The metadata plane now takes care of itself. The data plane still does not — topic data and offsets live only on the brokers until you copy them somewhere independent.
KRaft keeps cluster metadata consistent, but topic data and consumer offsets still live only on the brokers. Kafka Backup copies both to S3, Azure, GCS, or filesystem storage with point-in-time recovery. Get started.