KRaft & the Controller Quorum

Goodbye ZooKeeper — metadata now lives in a Raft log.

0/1 done

Why KRaft

KRaft replaces ZooKeeper

Pre-2.8 Kafka stored cluster metadata in ZooKeeper. Since KIP-500 / Kafka 3.3 GA, Kafka runs in KRaft mode where a small controller quorum (typically 3 or 5 nodes) owns metadata in its own Raft-replicated log. Wins:

One service to operate, monitor, secure, upgrade.
Faster controller failover (milliseconds, not tens of seconds).
Millions of partitions per cluster.

Production rules of thumb: odd quorum size, dedicated controller nodes at scale, never mix controllers across regions (latency kills Raft).

Reflect

Map your existing ZK-dependent runbooks.

›Which alerts fire on ZK quorum health today? Where do they move under KRaft?
›What's the migration path: in-place vs blue/green cluster?
›Who owns the controller nodes' OS patching? Same team as brokers, or split?

Reading in progress · 0 of 1 activity done