Overview
KRaft uses the Raft consensus algorithm. A small set of servers, typically 3 or 5, is configured as controllers and forms the metadata quorum; they can be dedicated controllers (process.roles=controller) or, in combined mode, also brokers. One controller is active and the others are hot standbys. A majority of the controllers must be alive for the quorum to stay available, so tolerating N failures takes 2N + 1 controllers: 3 controllers tolerate 1 failure and 5 tolerate 2.
Key configuration
process.roles=controller — dedicated controller node
process.roles=broker,controller — combined mode, for development and small non-critical use
node.id=1
controller.listener.names=CONTROLLER
controller.quorum.bootstrap.servers=host1:9093,host2:9093,host3:9093 — dynamic quorums
# Static quorums use controller.quorum.voters=1@host1:9093,2@host2:9093,3@host3:9093, which KRaft version 1 deprecatedProduction tip
Check yourself
A KRaft cluster has 5 controllers. How many can fail while it can still elect an active controller?
Sources
- KRaft operations (4.2 documentation) (opens in a new tab)
- Broker configs (4.2 documentation) (opens in a new tab)
- KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum (opens in a new tab)
- KIP-595: A Raft Protocol for the Metadata Quorum (opens in a new tab)
Checked against Kafka 4.2 documentation on Oct 2026. Draft: not yet reviewed by a Kafka specialist. Releases move on, so confirm against the current documentation before you act on a number.