...

This KIP proposes to mark KRaft as production-ready (aka GA, or general access) for new clusters in the upcoming Kafka 3.4 3 release. We would also like to deprecate ZooKeeper mode, and plan to remove entirely it in Kafka 4.0.

...

KIP-746: Revise KRaft Metadata Records fixed several issues with the original record definitions established in Kafka 2.8. KIP-778: KRaft upgrades spelled out a clear path for handling changes to KRaft metadata in a backwards-compatible way. Overall, we feel that the next release of Kafka, the 3.4 release3 release, will be a good time to  remove the "only for testing" warning from KRaft and mark it as ready for production.

The rationale for deprecating ZK in the 3.4 release 3 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.

...

The last omission (upgrade from ZK) is the most significant. We expect to release a KIP soon describing in detail how the upgrade from ZK mode will work. This work is currently targetted at the next release (3.43).

Compatibility, Deprecation, and Migration Plan

...

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.43. 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.43.