KRaft controller roles in Kafka 4.0: combined versus dedicated placement after ZooKeeper removal

Apache Kafka 4.0 removes ZooKeeper mode entirely, so brokers configured with zookeeper.connect will not start. Operators migrating from an existing ZooKeeper cluster must therefore choose a KRaft controller topology before the cutover. The migration path is one-way and does not support rolling mixed-mode upgrades, which means the decision cannot be deferred or reversed without downtime.

Client produce and consume protocols remain compatible across this boundary, so the primary impact is operational rather than a wire-protocol change. However, KRaft requires a majority of controller voters to be available for metadata commits; losing quorum halts topic creation and partition reassignment. Custom ZooKeeper znodes and ACLs also require explicit verification because auxiliary data may not be automatically translated. Operators should validate topology choices in a non-production environment against the specific Kafka 4.0 release, as migration tooling and quorum behavior may vary by minor version.

An unresolved deployment decision is whether to colocate broker and controller roles on the same nodes or run dedicated controllers. The optimal failure-isolation strategy is workload-dependent and is not automatically selected by the broker, leaving operators to weigh resource efficiency against blast-radius containment without a universal default.

For a given workload, what metrics or failure modes should determine combined versus dedicated controller placement? How can operators confirm that all custom znodes and ACLs are present in the KRaft metadata log before decommissioning ZooKeeper? What availability trade-offs arise when a single node hosts both broker and controller roles under the majority quorum requirement?