Het probleem met ZooKeeper

Al bijna tien jaar heeft elk Apache Kafka-cluster een ensemble nodig Apache ZooKeeper apart om metadata te beheren: welke makelaars actief waren, welke makelaar leider was van welke partitie, onderwerp en ACL-metagegevens. ZooKeeper is een coördinatiesysteem robuust en betrouwbaar gedistribueerd, maar introduceerde een aantal belangrijke operationele problemen:

  • Dubbele operationele complexiteit: Elk team dat Kafka beheerde, moest ook een afzonderlijk ZooKeeper-cluster beheren (doorgaans 3 of 5 knooppunten), met een eigen monitoring, upgradecyclus en afzonderlijke configuratie.
  • Beperkte schaalbaarheid van metagegevens: ZooKeeper liet prestatieverlies zien boven ~200.000 partities per cluster, omdat de metagegevens van elke partitie zijn geschreven als afzonderlijke ZooKeeper-knooppunten.
  • Trage controleursverkiezingen: Toen de Kafka-makelaarcontroller viel, moest de nieuwe controller het gehele getal lezen clusterstatus van ZooKeeper voordat het kon werken, een proces dat voor grote clusters tientallen seconden kan duren.
  • Moeilijkheden bij herstel na een ramp: herstel van een Kafka-cluster in geval van gegevensverlies op ZooKeeper het was een complex en riskant handmatig proces.

KRaft-tijdlijn

  • KIP-500 (2020): Origineel voorstel om ZooKeeper van Kafka te verwijderen
  • Kafka 2.8 (april 2021): eerste versie met KRaft in vroege toegang (alleen voor testen)
  • Kafka 3.3 (Oktober 2022): KRaft productieklaar verklaard voor nieuwe clusters
  • Kafka 3.5 (juni 2023): Migratietool van ZooKeeper naar KRaft beschikbaar
  • Kafka 3.7 (maart 2024): ZooKeeper-modus verouderd
  • Kafka 4.0 (maart 2025): ZooKeeper-modus permanent verwijderd

Hoe KRaft werkt: het vlot-consensuslogboek

Het concept van metadatalogboek

De oplossing die in KRaft (Kafka Raft) wordt gekozen is elegant: in plaats van afhankelijk te zijn van een extern systeem voor metadata, Kafka verwerkt zijn metadata als een Intern Kafka-onderwerp genaamd @metadata. Dit onderwerp wordt gerepliceerd via een Raft-protocol tussen controllerknooppunten.

In KRaft vervullen clusterbrokers een van de volgende twee rollen (of beide, in kleine clusters):

  • Controleurs: Beheert clustermetagegevens. In een productiecluster wordt een quorum van 3 controllers aanbevolen. De actieve controller (Raft leader) verwerkt alle metadatawijzigingen en repliceert deze naar andere controllers.
  • Makelaar: beheert partitielogboeken, bedient producenten en consumenten. Makelaars bewaren een kopie cache van metagegevens ontvangen van de controller, bijgewerkt tijdens streaming.

Het vlotprotocol in Kafka

Raft is een gedistribueerd consensusalgoritme dat is ontworpen om begrijpelijk te zijn (in tegenstelling tot Paxos). Kortom: onder alle quorumknooppunten wordt er één gekozen leider. De leider ontvangt alle geschriften, het verspreidt ze naar de volgers, en wanneer een meerderheid van de knooppunten het schrijven heeft bevestigd, beschouwt het het als toegewijd.

In KRaft vertaalt dit zich als volgt:

  1. Een metagegevensbewerking (onderwerp maken, partitieleider toewijzen, enz.) arriveert bij de leidercontroller
  2. De leidercontroller schrijft de bewerking naar het metagegevenslogboek als een geserialiseerde gebeurtenis
  3. De gebeurtenis wordt via het protocol gerepliceerd naar controllervolgers FETCH (gebruik makend van bestaande Kafka-code)
  4. Wanneer de meerderheid van de controllers dit heeft bevestigd (quorum), wordt de bewerking doorgevoerd
  5. Makelaars ontvangen metadata-updates die vanaf de actieve controller worden gepusht via MetadataUpdate
# Struttura di una directory dati KRaft (broker+controller combinato)
# /var/lib/kafka/data/

/var/lib/kafka/data/
  meta.properties          # cluster.id, node.id, version
  __cluster_metadata-0/    # il metadata log (partizione 0)
    00000000000000000000.log
    00000000000000000000.index
    00000000000000000000.timeindex
    leader-epoch-checkpoint
  ordini-effettuati-0/     # log di una partizione normale
  ordini-effettuati-1/
  ...

# meta.properties esempio:
node.id=1
version=1
cluster.id=MkU3OEVBNTcwNTJENDM2Qk

Quorumcontroller: maatvoering

De quorumcontroleur volgt de consensusregels: tolereren f falen, ze zijn nodig 2f+1 knopen.

  • 3 controllers: tolereert 1 storing (minimale configuratie voor productie)
  • 5 controllers: tolereert 2 gelijktijdige fouten (aanbevolen voor kritieke clusters)
  • 1 regelaar: Alleen voor lokale ontwikkeling/testen, geen fouttolerantie

Controleurs kunnen dat zijn toegewijd (alleen controllerrol, beheer geen gebruikerspartities) of gecombineerd (dezelfde machines die ook als makelaars fungeren). Voor kleine clusters (< 10 makelaars) de controllers gecombineerd zijn ze prima. Voor grote clusters of clusters met hoge doorvoer isoleren speciale controllers de beheerbelasting metagegevens van de I/O-lading van de partities.

Een KRaft-cluster helemaal opnieuw configureren

# server.properties per un nodo controller+broker combinato (cluster single-node per dev)

# ─── Identity ─────────────────────────────────────────────────────────────────
# In KRaft ogni nodo ha un node.id unico nel cluster (sostituisce broker.id)
node.id=1

# Ruoli: "broker" | "controller" | "broker,controller"
process.roles=broker,controller

# Indirizzo del quorum controller: formato node.id@host:port
controller.quorum.voters=1@localhost:9093

# ─── Listeners ────────────────────────────────────────────────────────────────
# KAFKA: listener per producer/consumer
# CONTROLLER: listener per comunicazione KRaft interna
listeners=KAFKA://localhost:9092,CONTROLLER://localhost:9093
advertised.listeners=KAFKA://localhost:9092

listener.security.protocol.map=KAFKA:PLAINTEXT,CONTROLLER:PLAINTEXT
inter.broker.listener.name=KAFKA
controller.listener.names=CONTROLLER

# ─── Storage ──────────────────────────────────────────────────────────────────
log.dirs=/var/lib/kafka/data

# ─── Replication defaults ─────────────────────────────────────────────────────
default.replication.factor=1        # 1 per dev, 3 per produzione
min.insync.replicas=1               # 1 per dev, 2 per produzione
offsets.topic.replication.factor=1

# ─── Retention ────────────────────────────────────────────────────────────────
log.retention.hours=168             # 7 giorni
log.segment.bytes=1073741824        # 1GB per segmento
# Inizializzare il cluster KRaft (una tantum)
# Step 1: generare un cluster UUID univoco
KAFKA_CLUSTER_ID=$(kafka-storage.sh random-uuid)
echo "Cluster ID: $KAFKA_CLUSTER_ID"

# Step 2: formattare la directory storage con il cluster ID
kafka-storage.sh format \
  --config /etc/kafka/server.properties \
  --cluster-id "$KAFKA_CLUSTER_ID"

# Output:
# Formatting /var/lib/kafka/data with metadata.version 4.0-IV3.

# Step 3: avviare il broker
kafka-server-start.sh /etc/kafka/server.properties

Belangrijk: De cluster-ID is onveranderlijk

Il cluster.id gegenereerd wanneer het formaat naar het bestand wordt geschreven meta.properties van elk knooppunt en in het metadatalogboek. Dit kan na initialisatie niet meer worden gewijzigd. Als u dit bestand kwijtraakt en een node naar het bestaande cluster, moet u de juiste bootstrapprocedure gebruiken. Bewaar de cluster-ID in een geheimbeheersysteem.

Docker Compose: KRaft Cluster voor lokale ontwikkeling

# docker-compose.yml per cluster Kafka 4.0 KRaft (3 broker)
# Immagine: apache/kafka:4.0.0 (immagine ufficiale Apache, non Confluent)

version: "3.9"

services:
  kafka1:
    image: apache/kafka:4.0.0
    container_name: kafka1
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "PLAINTEXT://kafka1:9092,CONTROLLER://kafka1:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://kafka1:9092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka1:9093,2@kafka2:9093,3@kafka3:9093"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
      CLUSTER_ID: "MkU3OEVBNTcwNTJENDM2Qk"
    volumes:
      - kafka1-data:/var/lib/kafka/data

  kafka2:
    image: apache/kafka:4.0.0
    container_name: kafka2
    environment:
      KAFKA_NODE_ID: 2
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "PLAINTEXT://kafka2:9092,CONTROLLER://kafka2:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://kafka2:9092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka1:9093,2@kafka2:9093,3@kafka3:9093"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
      CLUSTER_ID: "MkU3OEVBNTcwNTJENDM2Qk"
    volumes:
      - kafka2-data:/var/lib/kafka/data

  kafka3:
    image: apache/kafka:4.0.0
    container_name: kafka3
    environment:
      KAFKA_NODE_ID: 3
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "PLAINTEXT://kafka3:9092,CONTROLLER://kafka3:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://kafka3:9092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka1:9093,2@kafka2:9093,3@kafka3:9093"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
      CLUSTER_ID: "MkU3OEVBNTcwNTJENDM2Qk"
    volumes:
      - kafka3-data:/var/lib/kafka/data

volumes:
  kafka1-data:
  kafka2-data:
  kafka3-data:

Migratie van Kafka 3.x met ZooKeeper naar KRaft

Als u een Kafka 3.x-cluster beheert in ZooKeeper-modus en moet migreren naar KRaft (vereist om Kafka 4.0 te gebruiken), het proces heet KRaft-migratie en wordt officieel ondersteund sinds versie 3.5. Het goede nieuws: migratie vindt plaats zonder stilstand voor producenten en consumenten.

Fasen van migratie

Het officiële proces is verdeeld in 6 fasen:

  1. Controleer de vereisten: upgrade naar Kafka 3.7 (nieuwste versie met ZooKeeper+KRaft dual-write-ondersteuning), controleer dat alle makelaars dit hebben metadata.version uitgelijnd.
  2. Implementatie van KRaft-controller: Start KRaft-controllerknooppunten (3 nieuwe knooppunten, of bestaande makelaars met extra rol). Controllers verkrijgen de initiële metadata van ZooKeeper via de migratietool.
  3. Dual-schrijfmodus: Makelaars schrijven metadata naar zowel ZooKeeper als het KRaft-metagegevenslogboek. Tijdens deze fase is het systeem volledig operationeel.
  4. Migratie voltooid: alle makelaars migreren, ZooKeeper wordt alleen-lezen voor Kafka. Producenten en consumenten ervaren geen onderbreking.
  5. ZooKeeper-finalizer: Voer de finalizer uit die Kafka-metagegevens van ZooKeeper opschoont.
  6. Sluit ZooKeeper af: Ontmanteling van het ZooKeeper-ensemble. Volledig KRaft-cluster. 
# Step 1: Verifica metadata.version attuale del cluster
# (da eseguire con Kafka 3.7)
kafka-features.sh --bootstrap-server kafka1:9092 describe

# Output:
# Feature: metadata.version
#   SupportedMinVersion: 3.0-IV1
#   SupportedMaxVersion: 3.7-IV4
#   FinalizedVersion: 3.7-IV4

# Step 2: Avvia i controller KRaft con la migration config speciale
# In server.properties dei controller KRaft:
process.roles=controller
zookeeper.connect=zk1:2181,zk2:2181,zk3:2181   # ancora necessario in fase di migrazione
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093

# Step 3: Avvia la migration (da eseguire una volta soli i controller KRaft sono up)
# Modifica server.properties di OGNI broker Kafka esistente:
# Aggiunge il parametro:
zookeeper.metadata.migration.enable=true
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093

# Riavvia i broker uno alla volta (rolling restart, zero downtime)
# I broker entrano in migration mode automaticamente

# Step 4: Monitora lo stato della migrazione
kafka-metadata-shell.sh \
  --snapshot /var/lib/kafka/data/__cluster_metadata-0/00000000000000000000.snapshot

# Step 5: Finalizza (dopo che tutti i broker sono migrati)
kafka-features.sh --bootstrap-server kafka1:9092 upgrade \
  --metadata 3.7-IV4  # o la versione target

# Step 6: Rimuovi zookeeper.connect dai server.properties e riavvia i broker

Belangrijke mededelingen voor migratie

  • Ga niet gemakkelijk terug: Zodra de KRaft-migratie is voltooid en ZooKeeper is verwijderd, terugdraaien is zeer complex. Migreer eerst naar een faseringsomgeving die identiek is aan de productie.
  • ACL's en configuraties: ACL's en dynamische configuraties beheerd via ZooKeeper worden gemigreerd automatisch in het metadatalogboek, maar controleer of ze na de migratie aanwezig zijn.
  • Connector Kafka Connect: Connectors die het Kafka-cluster gebruiken als backend voor state (group.id, offsets) blijven ongewijzigd werken.
  • SpiegelMaker 2: Als u MM2 gebruikt voor geo-replicatie, update dan externe clusters op dezelfde manier onderhoudsvenster om versie-incompatibiliteit te voorkomen.

KRaft met geavanceerde configuratie: speciale controllers

Voor clusters met een hoge doorvoer of het beheer van een groot aantal partities (>50.000), het is raadzaam om verwerkingsverantwoordelijken te scheiden van makelaars (dedicated controllers). Zoals dit Metagegevensbewerkingen (onderwerp maken, leiderverkiezing, configuratiewijziging) concurreren niet met partitielog I/O op dezelfde schijven. 

# server.properties per un CONTROLLER DEDICATO (non gestisce partizioni utente)
node.id=10
process.roles=controller
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093
listeners=CONTROLLER://kc1:9093
listener.security.protocol.map=CONTROLLER:PLAINTEXT
controller.listener.names=CONTROLLER
log.dirs=/var/lib/kafka/metadata

# server.properties per un BROKER PURO (non è controller)
node.id=1
process.roles=broker
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093
listeners=KAFKA://kafka1:9092
advertised.listeners=KAFKA://kafka1:9092
listener.security.protocol.map=KAFKA:PLAINTEXT
inter.broker.listener.name=KAFKA
controller.listener.names=CONTROLLER
log.dirs=/var/lib/kafka/data

# Con questa configurazione:
# - 3 macchine controller dedicati (leggeri, poca RAM, poca CPU)
# - N broker puri (ottimizzati per I/O disco)
# - Nessuna competizione di risorse tra metadata ops e I/O partizioni

In Confluent Cloud en in beheerde omgevingen zoals Amazon MSK (dat KRaft gebruikt sinds versie 3.6), de scheiding tussen controller en makelaar gebeurt automatisch en is transparant voor de gebruiker.

Operationele voordelen van KRaft

Sneller opstarten en herstellen

Met ZooKeeper moest de Kafka-makelaarcontroller, wanneer hij opnieuw opstartte, de volledige status van het cluster lezen van ZooKeeper voordat u het kunt gebruiken. Voor clusters met meer dan 100.000 partities kan dit duren 30-90 seconden onbeschikbaarheid van de controller.

Met KRaft bewaart de leidercontroller het metadatalogboek al in het geheugen en op de lokale schijf. Een failover van de controller is doorgaans vereist minder dan 5 seconden, zelfs voor grote clusters. Een casestudy van een fintech-bedrijf (Confluent Engineering Blog, 2025) documenteert een vermindering van 40% in de insteltijd na de migratie naar KRaft.

Schaalbaarheid van metadata

ZooKeeper had een praktische limiet van ongeveer 200.000 partities per cluster (ongeacht de prestaties van metagegevensbewerkingen aanzienlijk verslechterd). KRaft verwerkt het metadatalogboek zoals normaal Kafka houtt met verdichting en is getest met miljoenen partities per cluster.

Operationele eenvoud

Het verwijderen van ZooKeeper betekent:

  • Eén systeem om te monitoren in plaats van twee
  • Eén upgradecyclus in plaats van twee (vaak hadden ZooKeeper en Kafka complexe versiebeperkingen)
  • Gemakkelijkere implementatie op Kubernetes (minder StatefulSet, minder PVC)
  • Eenvoudiger noodherstel (clusterstatus staat in het metadatalogboek, niet gedistribueerd tussen Kafka en ZooKeeper)

KRaft op Kubernetes met Strimzi

Strimzi is de populairste Kubernetes-operator voor het beheer van Kafka. Vanaf versie 0.38, Strimzi ondersteunt native KRaft: 

# Kafka cluster KRaft con Strimzi Operator (Kubernetes)
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: kafka
  annotations:
    # Abilita KRaft mode (richiede Strimzi 0.38+)
    strimzi.io/kraft: enabled
spec:
  kafka:
    version: 4.0.0
    replicas: 3
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
    config:
      # KRaft-specific
      default.replication.factor: 3
      min.insync.replicas: 2
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      # Retention
      log.retention.hours: 168
      log.segment.bytes: 1073741824
    storage:
      type: persistent-claim
      size: 100Gi
      class: fast-ssd
    # Controller separato (produzione: controller dedicati)
    # Ometti questa sezione per controller combinati (default)
  # entityOperator gestisce topic e utenti tramite CRD
  entityOperator:
    topicOperator: {}
    userOperator: {}
# Creare un topic con Strimzi CRD (invece di kafka-topics.sh)
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: ordini-effettuati
  namespace: kafka
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 6
  replicas: 3
  config:
    retention.ms: "604800000"
    min.insync.replicas: "2"
    compression.type: snappy

De status van het KRaft Cluster controleren

# Verificare chi è il controller leader attuale
kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --status

# Output:
# ClusterId:              MkU3OEVBNTcwNTJENDM2Qk
# LeaderId:               1
# LeaderEpoch:            42
# HighWatermark:          156789
# MaxFollowerLag:         0
# MaxFollowerLagTimeMs:   12
# CurrentVoters:          [{"nodeId":1,"logEndOffset":156789,"lag":0},
#                          {"nodeId":2,"logEndOffset":156789,"lag":0},
#                          {"nodeId":3,"logEndOffset":156789,"lag":0}]
# CurrentObservers:       []

# Verificare i dettagli del quorum
kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --replication

# Leggere il metadata log (per debugging)
kafka-dump-log.sh \
  --files /var/lib/kafka/data/__cluster_metadata-0/00000000000000000000.log \
  --cluster-metadata

Configuratieverschillen: ZooKeeper versus KRaft

Voor degenen die uit een ZooKeeper-cluster komen, zijn hier de belangrijkste configuratieverschillen die u moet weten:

Configuratie ZooKeeper-modus KRaftMode
Clusterverbinding zookeeper.connect controller.quorum.voters
Knooppunt-ID broker.id node.id
Rollen Altijd makelaar process.roles
Luisteraarscontrollers N.v.t controller.listener.names
Initialisatie Auto (ZK-handvatten) kafka-storage.sh format
ACL-opslag ZooKeeper znodes Metagegevenslogboek

Metadataversie en functievlaggen in KRaft

Met KRaft introduceert Kafka het concept van metadata.versie: een versie van het metadataformaat in het cluster. Hierdoor zijn doorlopende upgrades van een cluster mogelijk zonder downtime, één knooppunt tegelijk. De metagegevensversie wordt alleen bijgewerkt als alle makelaars in het cluster de nieuwe versie ondersteunen. 

# Verificare la metadata.version corrente e le versioni supportate
kafka-features.sh \
  --bootstrap-server kafka1:9092 \
  describe

# Output tipico con Kafka 4.0:
# Feature: metadata.version
#   SupportedMinVersion: 3.0-IV1
#   SupportedMaxVersion: 4.0-IV3
#   FinalizedVersion: 4.0-IV3

# Verificare tutti i feature flags disponibili
kafka-features.sh \
  --bootstrap-server kafka1:9092 \
  describe --all

# Aggiornare la metadata.version dopo un upgrade di cluster
# (eseguire DOPO che tutti i broker sono stati aggiornati alla nuova versione)
kafka-features.sh \
  --bootstrap-server kafka1:9092 \
  upgrade --metadata 4.0-IV3

De versie 4.0-IV3 (Kafka 4.0 Incremental Version 3) is de nieuwste versie die beschikbaar is in de release Kafka 4.0 maart 2025. Elke versieverhoging maakt nieuwe functies en protocoloptimalisaties mogelijk.

Problemen met KRaft oplossen: veelvoorkomende problemen

Het cluster start niet: “Geen kiezers gevonden in quorum”

Deze fout geeft aan dat controllerknooppunten geen andere quorumkiezers kunnen vinden. Veelvoorkomende oorzaken:

  • verkeerd geconfigureerde controller.quorum.voters: Controleer of het formaat correct is (nodeId@hostname:port) en dat hostnamen door alle knooppunten kunnen worden opgelost.
  • CONTROLLER-luisteraar onbereikbaar: Controleer of de firewall dit toestaat communicatie op de controller-luisteraarpoort (standaard: 9093) tussen controllerknooppunten.
  • Cluster-ID komt niet overeen: als u opnieuw bent opgestart met kafka-storage.sh format op een van de knooppunten zonder de juiste cluster-ID te gebruiken, zullen de knooppunten niet deelnemen aan het cluster. 
# Verificare il cluster ID su ogni nodo
cat /var/lib/kafka/data/meta.properties
# node.id=1
# version=1
# cluster.id=MkU3OEVBNTcwNTJENDM2Qk  <-- deve essere identico su tutti i nodi

# Verificare che il controller leader sia eletto
kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --status | grep LeaderId

# Se LeaderId=-1, nessun leader è stato eletto (quorum non raggiunto)

# Controllare i log del broker per errori KRaft
grep -E "WARN|ERROR" /var/log/kafka/kafka.log | grep -i "kraft\|quorum\|controller"

Broker niet toegevoegd aan het cluster

Wanneer u een nieuwe makelaar aan een bestaand KRaft-cluster toevoegt, moet de makelaar worden geformatteerd met dezelfde cluster-ID als het bestaande cluster: 

# Recupera il cluster ID dal cluster esistente
CLUSTER_ID=$(kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --status | grep ClusterId | awk '{print $2}')

echo "Cluster ID: $CLUSTER_ID"

# Formatta il nuovo broker con lo stesso cluster ID
kafka-storage.sh format \
  --config /etc/kafka/server.properties \
  --cluster-id "$CLUSTER_ID"

# Avvia il nuovo broker
kafka-server-start.sh /etc/kafka/server.properties

# Verifica che il nuovo broker sia visibile nel cluster
kafka-broker-api-versions.sh \
  --bootstrap-server kafka1:9092 | grep "id:"

Volgende stappen in de serie

Met KRaft inbegrepen, bent u klaar om meer geavanceerde aspecten van de Kafka-configuratie aan te pakken:

  • Artikel 3 – Geavanceerde producent en consument: de gedetailleerde configuratie van acks, idempotent produceren strategieën voor nieuwe pogingen om duurzaamheid zonder duplicaten te garanderen.
  • Artikel 4 – Exactly-Once-semantiek: Kafka-transacties voor atomaire schrijfbewerkingen over meerdere onderwerpen, waarbij de nieuwe transactiecoördinator is geïmplementeerd in het KRaft-metadatalogboek.
  • Artikel 11 – Kafka in productie: KRaft-clustergrootte, configuratie van controllerreplica's, noodherstel en back-up van metadatalogboeken.

Link met andere series

  • Geavanceerde Kubernetes: inzet van Kafka op Kubernetes met Strimzi-operator, persistent opslagbeheer en automatisch schalen van consumentengroepen.
  • Waarneembaarheid: KRaft-quorummonitoring met JMX Exporter, kritische statistieken hoe kafka.controller:type=KafkaController,name=ActiveControllerCount en alert op de verkiezing van leiders.