...

In Kafka 2.8, KRaft mode was released in early access. By Kafka 3.0, it was in preview.

This KIP proposes to mark :

1. Mark KRaft as production-ready

...

1. for new clusters in the upcoming Kafka 3.3 release.

...

1. This is also known as "GA" or "general access."
2. Deprecate ZooKeeper mode in the upcoming Kafka 3.4 release
3. Plan to remove ZooKeeper mode entirely in Kafka 4.0.

Rationale

Over the last year and a half, we have gained a lot of confidence in the KRaft implementation. Our JUnit test coverage has grown as we have converted existing tests and written brand new tests. We have added support for KRaft mode to Kafka's "ducktape" system test framework. We have also run load tests and stress tests on KRaft clusters.

...

The rationale for deprecating ZK in the 3.3 release 4 release is so that we can remove it in the 4.0 release. (In general, Kafka requires features to be deprecated for at least one release before they can be removed in the following major release.) During the deprecation period, ZK mode would continue to be fully supported. However, we would let people know that KRaft mode is the future.

Once ZK mode is removed in Kafka 4.0, we will be able to avoid maintaining parallel codebases for important infrastructure such as the Kafka controller.

Timeline

Note: this timeline is very rough and subject to change. However, it's intended to help people associated dates with release numbers. We are assuming that Kafka will continue to use time-based releases that happen every 4 months.

• 2022/08: KRaft mode declared production-ready in Kafka 3.3
• 2022/12: Upgrade from ZK mode supported in Kafka 3.4. ZooKeeper mode deprecated.
• 2023/04: Kafka 3.5 released with both KRaft and ZK support
• 2023/08: Kafka 4.0 released with only KRaft mode supported.

Missing Features

As of the date of writing, several features have not yet been implemented in KRaft mode.

...

One possible objection is that we should not declare KRaft to be production ready until it has reached full feature parity with ZooKeeper mode. My response to this is that we expect to close the feature gaps relatively quickly – especially upgrade, which should be fully taken care of in 3.34. There is still a lot of value in marking KRaft as production ready now. In addition to enabling more usage, it will ensure that we do not end up with more feature gaps to fill over the next few months.

Another possible objection is that we should keep ZooKeeper mode around in the 4.x series of releases. My response here is that supporting both modes is a burden for people maintaining and adding to the code. Also, it's worth keeping in mind that even if we commit to removing ZK in 4.0, we always have the option of doing a 3.5 release if we are not ready to fully remove ZK in the release after 3.3more 3.x releases.