Imagine a bank-transfer topic spread across several Kafka brokers. Its partitions need broker assignments and leaders, and those decisions must remain consistent when a broker fails. KRaft is Kafka’s Raft-based way to coordinate that cluster state without a separate ZooKeeper system. section 1.3 section 7.1
A KRaft coordination cluster elects an active controller. Controllers manage metadata such as partition assignments and leaders; the active controller monitors brokers and directs changes when the cluster changes. KRaft keeps coordination within Kafka, while the __cluster_metadata topic provides consistent metadata storage. This removes the need to operate ZooKeeper alongside Kafka and avoids its metadata-management bottlenecks. section 4.3.1 section 7.5
Choosing controller nodes
For local development, one controller-broker is enough, but it offers no controller failover. Three controller-brokers can survive one failure; five can survive two. Choose an odd-sized coordination cluster when availability matters. section 7.1
Figure 4.11 Kafka uses either a KRaft-based or a ZooKeeper-based coordination cluster. Both should consist of an odd number of nodes (usually three or five) and use a protocol to find a consensus.
The diagram contrasts KRaft- and ZooKeeper-based coordination clusters and shows why controller-node count is a cluster-design choice. section 4.3.1
Kafka 3.3.0 made KRaft production ready; Kafka 3.5.0 deprecated ZooKeeper coordination, with ZooKeeper-backed support slated for removal in Kafka 4.0. For an existing ZooKeeper cluster, migration is a planned sequence: provision KRaft controllers with the same cluster ID, enable migration settings, verify metadata transfer, then move brokers to KRaft mode and test stability. Do not treat a development single-controller setup as a production failover configuration. section 7.1 section 7.5
