Overview
Before KRaft, Kafka depended on Apache ZooKeeper for cluster metadata such as broker registration, controller election, configuration and ACLs. KIP-500 gives the reasons for replacing it: administrators had to learn to deploy and manage two separate distributed systems, and Kafka's own metadata was kept outside Kafka. It describes the goal as managing metadata in a more scalable and robust way, with support for more partitions, and a controller failover that does not require a lengthy reloading period. KRaft was marked production-ready for new clusters in Kafka 3.3 (KIP-833), and Kafka 4.0 supports only KRaft.
Analogy
Production tip
Check yourself
Which is one reason Kafka moved off ZooKeeper?
Sources
- KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum (opens in a new tab)
- KIP-833: Mark KRaft as Production Ready (opens in a new tab)
- Kafka 3.5.0 release announcement (opens in a new tab)
- Kafka 3.9.0 release announcement (opens in a new tab)
- Upgrading (4.2 documentation) (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.