Event streaming: Apache Kafka 3.3 arms ZooKeeper replacement KRaft

event streaming apache kafka 33 arms zookeeper replacement kraft.jpg
event streaming apache kafka 33 arms zookeeper replacement kraft.jpg

As of Kafka 3.3, KRaft is considered production-ready for new clusters. However, KRaft does not yet fully cover the range of functions that ZooKeeper is used to.

The Kafka message broker project managed by the Apache Software Foundation (ASF) has reached version 3.3.0. Among the numerous innovations, the first release of the ZooKeeper successor KRaft stands out. KRaft, which was introduced in version 2.8 as part of the switch to a self-managed metadata quorum, is now considered ready for production for use in connection with new Kafka clusters.

As early as spring 2021, the Kafka team gave a first glimpse of the future of the message broker without ZooKeeper. Since then, work on the KRaft metadata and APIs has progressed steadily. With version 3.3.0, the self-managing metadata quorum integrated into Apache Kafka has apparently reached the required maturity to now also prove itself in production environments – as can be seen from the Kafka Improvement Proposal KIP-133.

This is the official starting signal for the transition phase from ZooKeeper to KRaft. The current roadmap plans to set KRaft as the standard with the release of Apache Kafka 4.0 in about a year. Previously, ZooKeeper from version 3.5 will initially be marked as deprecated and will be completely omitted in Kafka 4.0. At the moment, however, the use of KRaft is still limited to new clusters. The Kafka team plans to offer an upgrade for older clusters managed with ZooKeeper in version 3.4 at the earliest as part of an Early Access program.

SEE ALSO  Do you need a new computer? These 5 clues show you that yes

KRaft does not yet cover the full range of functions that ZooKeeper is used to. The development team admits, among other things, that the configuration of SCRAM users (Salted Challenge Response Authentication Mechanism) required for authentication purposes via the administrative API is not yet possible. In addition, KRaft is not yet able to work with JBOD configurations that span multiple storage directories. According to their own statements in the blog entry, the Kafka team wants to deliver these and other missing functions listed in KIP-133 as soon as possible.