Should I choose KRaft mode or ZooKeeper mode?

KRaft mode is the modern, ZooKeeper-free consensus mechanism built into Kafka itself, and is the default and recommended choice for new clusters from Kafka 3.3+ onward (mandatory from Kafka 4.0). ZooKeeper mode remains relevant only for older Kafka versions or existing clusters that haven't yet migrated.

What's the difference between broker.id and node.id?

broker.id is the legacy identifier used in both modes for the broker role itself. node.id is KRaft's identifier for a node's role in the metadata quorum (controller, broker, or both) and must be unique across all nodes in the cluster, including dedicated controller-only nodes that don't have a separate broker.id.

What does controller.quorum.voters look like in practice?

It's a comma-separated list of ' @ : ' entries identifying every node participating in the KRaft controller quorum, for example '1@localhost:9093,2@localhost:9093,3@localhost:9093' for a three-node quorum, required so nodes can find and elect among the controller voters.

What does process.roles control in KRaft mode?

It declares what a given node does: 'broker' for a data node, 'controller' for a metadata-quorum-only node, or 'broker,controller' for a combined node that does both, common in smaller KRaft clusters.

Kafka Config Generator - server.properties (KRaft or ZooKeeper)

Overview

Introduction

Kafka's server.properties differs meaningfully depending on whether a cluster runs KRaft or the older ZooKeeper-based consensus, and mixing settings from both modes into one file produces a broker that won't start.

This tool generates server.properties from a form with a single mode toggle, emitting only the KRaft fields (process.roles, node.id, controller.quorum.voters) or only the ZooKeeper field (zookeeper.connect), never both at once.

What Is Kafka Config Generator?

A generator for Kafka's server.properties covering the settings every broker needs regardless of mode, broker.id, listeners, log.dirs, num.partitions, and offsets.topic.replication.factor, plus a mode-specific block.

The mode toggle switches between KRaft (process.roles, node.id, controller.quorum.voters) and legacy ZooKeeper (zookeeper.connect), with each mode's required fields validated only when that mode is selected.

How Kafka Config Generator Works

Core fields are validated and emitted first: broker.id and offsets.topic.replication.factor and num.partitions as integers, listeners and log.dirs as non-empty strings.

Depending on the mode toggle, the generator then validates and appends either the three KRaft-specific fields under a '# KRaft mode' comment, or the single zookeeper.connect field under a '# ZooKeeper mode' comment, so the output never contains a contradictory mix of both consensus mechanisms.

When To Use Kafka Config Generator

Use it when standing up a new Kafka broker and you want a correctly scoped server.properties for whichever consensus mode your cluster uses.

It's also useful as a quick reference for KRaft's exact property names (process.roles, controller.quorum.voters, node.id) when migrating a cluster off ZooKeeper.

Often used alongside RabbitMQ Config Generator.

Features

Advantages

Never mixes KRaft and ZooKeeper settings in one output, a common source of a broker that fails to start with a confusing consensus-related error.
Validates each mode's specific required fields (controller.quorum.voters and node.id for KRaft, zookeeper.connect for ZooKeeper) only when that mode is actually selected.
Covers the core fields (broker.id, listeners, log.dirs, num.partitions, offsets.topic.replication.factor) every broker needs regardless of which consensus mode it runs.

Limitations

Doesn't cover topic-level configuration, ACLs, or SASL/SSL security settings, only the core broker.id/listener/consensus properties.
Models a single broker's server.properties; for a full cluster you'd generate one per node, adjusting broker.id/node.id and listeners each time.
Doesn't validate that controller.quorum.voters entries actually correspond to reachable hosts.

Examples

A single-node KRaft broker acting as both broker and controller

Input

broker.id: 1, listeners: PLAINTEXT://:9092,CONTROLLER://:9093, log.dirs: /var/lib/kafka/data, num.partitions: 3, offsets.topic.replication.factor: 1; mode: KRaft, node.id: 1, process.roles: broker,controller, controller.quorum.voters: 1@localhost:9093

Output

# server.properties
broker.id=1
listeners=PLAINTEXT://:9092,CONTROLLER://:9093
log.dirs=/var/lib/kafka/data
num.partitions=3
offsets.topic.replication.factor=1

# KRaft mode (no ZooKeeper)
process.roles=broker,controller
node.id=1
controller.quorum.voters=1@localhost:9093

Because KRaft mode is selected, no zookeeper.connect line appears anywhere in the output.

Best Practices & Notes

Best Practices

Prefer KRaft mode for any new Kafka deployment; ZooKeeper mode is legacy and unsupported from Kafka 4.0 onward.
Set offsets.topic.replication.factor to at least 3 in any multi-broker production cluster so the internal offsets topic itself is fault-tolerant.
Keep node.id values unique and stable across restarts for every node in a KRaft controller quorum, reusing an ID for a different physical node can corrupt cluster metadata.

Developer Notes

Output is a plain server.properties key=value file; the two consensus modes are modeled as a discriminated toggle so the generator validates and emits only the fields relevant to the selected mode, guaranteeing the output never contains both process.roles/controller.quorum.voters and zookeeper.connect simultaneously, a combination real Kafka brokers reject at startup.

Kafka Config Generator Use Cases

Bootstrapping server.properties for a new single-node or small KRaft cluster
Producing a reference ZooKeeper-mode server.properties for maintaining an existing pre-migration cluster
Comparing the exact property names each consensus mode requires side by side

Common Mistakes

Including both zookeeper.connect and process.roles/controller.quorum.voters in the same server.properties, which Kafka rejects.
Reusing a node.id across two different physical nodes in a KRaft quorum, corrupting quorum metadata.
Setting offsets.topic.replication.factor higher than the number of brokers actually available in the cluster, which prevents the offsets topic from being created.

Tips

For a single-node development KRaft broker, set process.roles to 'broker,controller' so one node handles both responsibilities.
Use the RabbitMQ Config Generator alongside this one if you're evaluating Kafka against RabbitMQ for a given messaging workload.

Kafka Config Generator