A Kafka cluster needs a controller to coordinate metadata updates and respond when brokers fail. In KRaft mode, controllers form a quorum with one leader; followers fetch metadata updates from that leader. Leader election lets another controller take over when the leader becomes unavailable. This is distinct from partition leadership: partition leaders serve messages, while the controller manages cluster coordination. section 9.1 section 9.5
When a KRaft leader controller fails, the handover follows a sequence:
- A follower stops receiving timely metadata-fetch responses, treats the leader as unavailable, and becomes a candidate. The timeout is set by controller.quorum.fetch.timeout.ms. section 9.1.3
- Candidates request votes. A controller votes only once per term and only for a candidate whose metadata log is at least as up-to-date as its own. A majority elects the new leader. section 9.1.3
- Before serving brokers, the new leader checks that it has all committed metadata entries and fetches any missing entries. Brokers use their configured controller list to find it and refresh their metadata. section 9.1.3
Planning for controller failure
To tolerate one controller failure, run three controllers: two still form a majority. Without a majority, leader elections and metadata changes halt. This makes quorum size a high-availability decision, not just a deployment detail. section 9.5
Legacy ZooKeeper deployments divide these responsibilities differently. ZooKeeper servers elect a leader for metadata management, while one Kafka broker acts as the active controller. In KRaft deployments, the controller quorum manages metadata directly. KRaft became Kafka’s default metadata-management system in version 3.7.0. section 9.1.4
Figure 9.1 Controllers operate as a quorum, responsible for storing metadata and monitoring cluster health.
The controller-quorum diagram distinguishes controller election and metadata synchronization from broker-to-broker partition replication. section 9.1
