What is ZooKeeper's role in traditional Kafka and what replaced it?

Historically Kafka depended on Apache ZooKeeper, a separate system, to store metadata about partitions and brokers and to elect a broker as the controller. Brokers registered with ZooKeeper, partition leaders updated the in-sync replica set (ISR) directly in ZooKeeper, and configurations and ACLs were also written there. KRaft (Kafka Raft) replaces it: controller servers form a metadata quorum and store all cluster metadata in memory and on disk, in a Kafka log (the __cluster_metadata log). KRaft was production-ready for new clusters in Kafka 3.3, 3.9 was the last bridge release for migrating from ZooKeeper, and Kafka 4.0 removed ZooKeeper mode. KIP-500 gives the motivation: one fewer system with its own configuration, tools and security to run, and standby controllers that replicate the log as hot standbys, so controller failover does not need a lengthy reloading period. A majority of the controllers must be alive; 3 or 5 controllers are typical.

Expected key concepts: ZooKeeper, metadata, elect, KRaft, __cluster_metadata, metadata quorum, hot standby, bridge release, 3.3, 4.0, KIP-500