# Kafka KRaft mode

*Learn about Kafka's new consensus protocol in eight minutes*

KRaft (Kafka Raft) mode is Kafka's built-in consensus protocol that replaces ZooKeeper for cluster coordination. This architectural change simplifies Kafka deployments and enables better scalability.

**What you'll learn:**
- Why ZooKeeper is being removed from Kafka
- How KRaft mode works
- Benefits of running Kafka without ZooKeeper
- When to use KRaft mode

## Why remove ZooKeeper from Kafka?

The Kafka project undertook one of its greatest changes with the introduction of [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum) on August 1st 2019: the desire to remove ZooKeeper as a dependency to running Apache Kafka.

Kafka scaling has hit a performance bottleneck with ZooKeeper, which means Kafka has the following limitations with ZooKeeper:

- Kafka clusters only support a limited number of partitions (up to 200,000)
- When a Kafka broker joins or leaves a cluster, a high number of leader elections have to happen which can overload ZooKeeper and slow down the cluster temporarily
- Kafka clusters setup is difficult and depends on another component to setup
- Kafka cluster metadata is sometimes out-of-sync from ZooKeeper
- ZooKeeper security is lagging behind Kafka security

## Kafka KRaft mode

It has been noted as part of KIP-500 that the metadata of Kafka itself is a log and that Kafka brokers should be able to consume that metadata log as an internal metadata topic. Kafka leverages itself!

Removing ZooKeeper means that Kafka has to still act as a quorum to perform controller election and therefore the Kafka brokers implement the [Raft protocol](https://cwiki.apache.org/confluence/display/KAFKA/KIP-595%3A+A+Raft+Protocol+for+the+Metadata+Quorum) thus giving the name KRaft to the new Kafka Metadata Quorum mode.

![Diagram showing the difference between Kafka with Zookeeper and Kafka in KRaft mode with Quorum Controller.](https://www.conduktor.io/assets/kafka/Kafka-KRaft-Mode-1.png)

### Architecture comparison

![Architecture comparison: with ZooKeeper, a separate ZooKeeper ensemble coordinates all brokers; with KRaft, dedicated controllers form a quorum among themselves and coordinate the brokers directly with no external dependency.](https://www.conduktor.io/assets/kafka/diagrams/kafka-kraft-mode.svg)

```mermaid
graph TB
    subgraph ZooKeeper["With ZooKeeper"]
        ZK["ZooKeeper Ensemble"]
        B1["Broker 1"]
        B2["Broker 2"]
        B3["Broker 3"]
        ZK --> B1
        ZK --> B2
        ZK --> B3
    end

    subgraph KRaft["With KRaft"]
        C1["Controller 1"]
        C2["Controller 2"]
        C3["Controller 3"]
        KB1["Broker 1"]
        KB2["Broker 2"]
        C1 <--> C2
        C2 <--> C3
        C1 --> KB1
        C2 --> KB2
    end
```

## Benefits of KRaft mode

Without ZooKeeper, the following benefits are observed in Kafka:

| Benefit | Description |
|---------|-------------|
| **Scale** | Ability to scale to millions of partitions |
| **Simplicity** | Single process to start Kafka, easier to maintain and set up |
| **Stability** | Improved stability, easier to monitor, support, and administer |
| **Security** | Single security model for the whole system |
| **Performance** | Faster controller shutdown and recovery time |

> **Production ready since Kafka 3.3**
> KRaft was officially released as production ready in Kafka version 3.3. For new deployments, KRaft is the recommended approach.

Starting tutorials for [Windows](https://www.conduktor.io/kafka/how-to-install-apache-kafka-on-windows-without-zookeeper-kraft-mode), [Mac](https://www.conduktor.io/kafka/how-to-install-apache-kafka-on-mac-without-zookeeper-kraft-mode) and [Linux](https://www.conduktor.io/kafka/how-to-install-apache-kafka-on-linux-without-zookeeper-kraft-mode).

## KRaft deployment modes

KRaft supports two deployment modes:

### Combined mode
Controllers and brokers run in the same process. Best for:
- Development environments
- Small clusters (3-5 nodes)
- Simplified operations

```properties
process.roles=broker,controller
```

### Isolated mode
Controllers and brokers run as separate processes. Best for:
- Production environments
- Large clusters
- Maximum stability

```properties
# On controller nodes
process.roles=controller

# On broker nodes
process.roles=broker
```

## Migration considerations

| Current setup | Recommendation |
|---------------|----------------|
| New cluster | Use KRaft mode |
| Kafka 2.x | Upgrade to 3.x, then migrate to KRaft |
| Kafka 3.x with ZooKeeper | Migrate to KRaft using official migration tools |
| Kafka 4.x | ZooKeeper not supported, must use KRaft |

> **Migration planning**
> Migrating from ZooKeeper to KRaft requires careful planning. Test thoroughly in non-production environments before migrating production clusters.

## More KRaft resources

- [KIP-833: Mark KRaft as Production Ready](https://cwiki.apache.org/confluence/display/KAFKA/KIP-833%3A+Mark+KRaft+as+Production+Ready)
- [Benefits of KRaft described in the Confluent blog](https://www.confluent.io/blog/kafka-without-zookeeper-a-sneak-peek/)

> **See it in practice with Conduktor**
> [Conduktor Console](https://docs.conduktor.io/guide/manage-kafka/kafka-resources/brokers) supports both ZooKeeper-based and KRaft-based Kafka clusters. Monitor controller status, metadata synchronization, and cluster health regardless of your deployment mode.

## Next steps

- [Get started with a running cluster](https://www.conduktor.io/kafka/starting-kafka) to put these concepts into practice hands-on
- [Set up Kafka with Docker](https://www.conduktor.io/kafka/how-to-start-kafka-using-docker) using KRaft mode
- [Install Kafka on Linux with KRaft](https://www.conduktor.io/kafka/how-to-install-apache-kafka-on-linux-without-zookeeper-kraft-mode) for a native setup