Problém se ZooKeeperem

Téměř deset let vyžaduje každý klastr Apache Kafka soubor Apache ZooKeeper samostatné pro správu metadat: kteří makléři byli aktivní, který makléř byl vedoucím kterého oddílu, tématu a metadat ACL. ZooKeeper je koordinační systém distribuovaný robustní a spolehlivý, ale přinesl řadu významných provozních problémů:

  • Dvojitá provozní složitost: Každý tým spravující Kafku musel také spravovat samostatný cluster ZooKeeper (typicky 3 nebo 5 uzlů), s vlastním monitorováním, cyklem upgradu a odlišnou konfigurací.
  • Omezená škálovatelnost metadat: ZooKeeper vykázal snížení výkonu nad ~200 000 oddílů na cluster, protože metadata každého oddílu byla zapsána jako samostatné uzly ZooKeeper.
  • Pomalá volba kontrolora: Když Kafka broker controller spadl, nový controller musel přečíst celé číslo stav clusteru ze ZooKeeperu, než mohl fungovat, což je proces, který může u velkých clusterů trvat desítky sekund.
  • Obtížnost při obnově po havárii: obnovení clusteru Kafka v případě ztráty dat na ZooKeeper byl to složitý a riskantní manuální proces.

Časová osa KRraft

  • KIP-500 (2020): Původní návrh na odstranění ZooKeepera z Kafky
  • Kafka 2.8 (duben 2021): první verze s KRaft v předběžném přístupu (pouze pro testování)
  • Kafka 3.3 (říjen 2022): KRaft prohlásil, že je připraven na výrobu pro nové clustery
  • Kafka 3.5 (červen 2023): K dispozici je nástroj pro migraci ZooKeeper na KRaft
  • Kafka 3.7 (březen 2024): Podpora režimu ZooKeeper byla ukončena
  • Kafka 4.0 (březen 2025): Režim ZooKeeper byl trvale odstraněn

Jak KRaft funguje: The Raft Consensus Log

Koncept protokolu metadat

Řešení přijaté v KRaft (Kafka Raft) je elegantní: namísto závislosti na externím systému pro metadata, Kafka nakládá se svými metadaty jako a Vnitřní kafkovské téma volal @metadata. Toto téma je replikováno prostřednictvím protokolu Raft mezi řídicími uzly.

V KRaft přebírají cluster brokeři jednu ze dvou rolí (nebo obě v malých clusterech):

  • Ovladače: Spravuje metadata clusteru. V produkčním clusteru se doporučuje kvorum 3 řadičů. Aktivní kontrolor (vůdce raftu) zpracovává všechny změny metadat a replikuje je na jiné kontrolory.
  • Makléř: spravuje logy oddílů, slouží výrobcům a spotřebitelům. Makléři si ponechávají kopii mezipaměť metadat přijatých z ovladače, aktualizovaná ve streamování.

Raftový protokol v Kafkovi

Raft je distribuovaný konsensus algoritmus navržený tak, aby byl srozumitelný (na rozdíl od Paxosu). Stručně řečeno: ze všech uzlů kvora je zvolen jeden vůdce. Vedoucí přijímá všechna písma, rozšíří je mezi následovníky, a když většina uzlů zápis potvrdí, považuje to za potvrzené.

V KRaft se to překládá takto:

  1. Operace metadat (vytvoření tématu, přiřazení vedoucího oddílu atd.) dorazí do řídicího řadiče
  2. Vedoucí kontrolér zapíše operaci do protokolu metadat jako serializovanou událost
  3. Událost je replikována na sledující ovladače prostřednictvím protokolu FETCH (využití stávajícího Kafkova kódu)
  4. Když většina kontrolorů potvrdí (kvorum), operace je potvrzena
  5. Brokeři dostávají aktualizace metadat posílané z aktivního správce prostřednictvím 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

Kontrolor kvora: Dimenzování

Správce kvora se řídí konsensuálními pravidly: tolerovat f selhání, jsou potřeba 2f+1 uzly.

  • 3 ovladače: toleruje 1 selhání (minimální konfigurace pro výrobu)
  • 5 ovladačů: toleruje 2 simultánní selhání (doporučeno pro kritické clustery)
  • 1 ovladač: Pouze pro místní vývoj/testování, bez tolerance chyb

Ovladače mohou být oddaný (pouze role řadiče, nespravovat uživatelské oddíly) nebo kombinovaný (stejné stroje, které fungují také jako makléři). U malých clusterů (< 10 brokerů) řadiče dohromady jsou fajn. U velkých clusterů nebo clusterů s vysokou propustností izolují zátěž správy vyhrazené řadiče metadata z načtení I/O oddílů.

Konfigurace clusteru KRaft od nuly

# 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

Důležité: ID clusteru je neměnné

Il cluster.id generované při zápisu formátu do souboru meta.properties každého uzlu a v protokolu metadat. Po inicializaci jej nelze změnit. Pokud tento soubor ztratíte a chcete přidat uzel do existujícího clusteru, musíte použít příslušnou bootstrap proceduru. Uložte ID clusteru v systému správy tajných klíčů.

Docker Compose: KRaft Cluster pro místní rozvoj

# 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:

Migrace z Kafka 3.x pomocí ZooKeeper na KRaft

Pokud spravujete cluster Kafka 3.x v režimu ZooKeeper a potřebujete migrovat na KRaft (vyžadováno pro použití Kafka 4.0), proces se nazývá Migrace KRraftů a je oficiálně podporován od verze 3.5. Dobrá zpráva: Migrace probíhá bez prostojů pro výrobce a spotřebitele.

Fáze migrace

Oficiální proces je rozdělen do 6 fází:

  1. Zkontrolujte předpoklady: upgrade na Kafka 3.7 (nejnovější verze s podporou duálního zápisu ZooKeeper+KRaft), zkontrolujte, zda mají všichni makléři metadata.version zarovnané.
  2. Nasazení ovladače KRraft: Spusťte uzly ovladače KRaft (3 nové uzly nebo stávající brokery s další role). Kontroloři získávají počáteční metadata od ZooKeeper prostřednictvím nástroje pro migraci.
  3. Režim duálního zápisu: Brokeři zapisují metadata do protokolu metadat ZooKeeper i KRaft. Během této fáze je systém plně funkční.
  4. Migrace dokončena: všichni brokeři migrují, ZooKeeper se pro Kafku stává pouze pro čtení. Výrobci ani spotřebitelé žádné přerušení nevnímají.
  5. Finalizátor ZooKeeper: Spusťte finalizátor, který vyčistí metadata Kafka ze ZooKeeperu.
  6. Vypnutí ZooKeeper: Vyřaďte soubor ZooKeeper z provozu. Plně KRraft 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

Důležitá upozornění pro migraci

  • Nevracejte se snadno: Jakmile je migrace KRaft dokončena a ZooKeeper je odstraněn, rollback je velmi složitý. Nejprve migrujte do pracovního prostředí identického s produkčním prostředím.
  • ACL a konfigurace: ACL a dynamické konfigurace spravované přes ZooKeeper jsou migrovány automaticky v protokolu metadat, ale zkontrolujte, zda jsou po migraci přítomny.
  • Konektor Kafka Connect: Konektory, které používají cluster Kafka jako backend pro stav (group.id, offsety) nadále fungovat beze změny.
  • MirrorMaker 2: Pokud používáte MM2 pro geografickou replikaci, aktualizujte vzdálené clustery v tomtéž okno údržby, aby se předešlo nekompatibilitě verzí.

KRaft s pokročilou konfigurací: Vyhrazené ovladače

Pro clustery s vysokou propustností nebo správou velkého počtu oddílů (>50 000) je vhodné oddělit controllery od brokerů (dedicated controllers). Takhle operace s metadaty (vytvoření tématu, volba lídra, změna konfigurace) nesoutěží s logem oddílu I/O na stejných discích. 

# 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

V Confluent Cloud a ve spravovaných prostředích, jako je Amazon MSK (který přijal KRaft od verze 3.6), k oddělení správce/zprostředkovatele dochází automaticky a je pro uživatele transparentní.

Provozní výhody KRraft

Rychlejší spouštění a obnova

Se ZooKeeperem, když se řadič zprostředkovatele Kafka restartoval, musel přečíst celý stav clusteru od ZooKeeper, než budete moci pracovat. U clusterů s více než 100 000 oddíly to může trvat 30-90 sekund nedostupnost ovladače.

S KRaft vedoucí řadič uchovává protokol metadat již v paměti a na místním disku. A failover ovladač obvykle vyžaduje méně než 5 sekundi pro velké shluky. Případová studie fintech společnosti (Confluent Engineering Blog, 2025) dokumentuje 40% zkrácení doby nastavení po migraci na KRaft.

Škálovatelnost metadat

ZooKeeper měl praktický limit kolem 200 000 oddílů na cluster (bez ohledu na výkon operace s metadaty výrazně degradovány). KRaft zpracovává protokol metadat jako normálně Kulatina Kafka se zhutněním a byla testována s miliony oddílů na shluk.

Provozní jednoduchost

Odstranění ZooKeeper znamená:

  • Jeden systém k monitorování místo dvou
  • Jeden cyklus upgradu místo dvou (často měli ZooKeeper a Kafka složitá omezení verze)
  • Jednodušší nasazení na Kubernetes (méně StatefulSet, méně PVC)
  • Snazší zotavení po havárii (stav clusteru je v protokolu metadat, není distribuován mezi Kafka a ZooKeeper)

KRaft na Kubernetes se Strimzi

Strimzi je nejoblíbenějším operátorem Kubernetes pro správu Kafky. Od verze 0.38, Strimzi nativně podporuje 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

Kontrola stavu KRaft Clusteru

# 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

Konfigurační rozdíly: ZooKeeper vs KRaft

Pro ty, kteří přicházejí z clusteru ZooKeeper, jsou zde hlavní rozdíly v konfiguraci, které je třeba znát:

Konfigurace ZooKeeperMode KRaftMode
Spojení clusteru zookeeper.connect controller.quorum.voters
ID uzlu broker.id node.id
Role Vždy makléř process.roles
Ovladače posluchačů N/A controller.listener.names
Inicializace Auto (kliky ZK) kafka-storage.sh format
ACL úložiště Znody ZooKeeper Protokol metadat

Příznaky verze metadat a funkcí v KRaft

S KRaft zavádí Kafka koncept metadata.verze: Verze formátu metadat v klastru. To umožňuje postupné upgrady clusteru bez prostojů, jeden uzel po druhém. Verze metadat se aktualizuje pouze tehdy, když všichni brokeři v clusteru novou verzi podporují. 

# 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

Verze 4.0-IV3 (Kafka 4.0 Incremental Version 3) je nejnovější dostupná ve vydání Kafka 4.0 březen 2025. Každé zvýšení verze umožňuje nové funkce a optimalizace protokolů.

Odstraňování problémů KRaft: Běžné problémy

Cluster se nespouští: „Žádní voliči nebyli v kvoru“

Tato chyba označuje, že uzly řadiče nemohou najít jiné voliče kvora. Běžné příčiny:

  • špatně nastavený kontrolor.kvórum.voliče: Ověřte, zda je formát správný (nodeId@hostname:port) a že názvy hostitelů jsou rozlišitelné všemi uzly.
  • Posluchač CONTROLLER je nedostupný: Ověřte, že firewall umožňuje komunikace na portu naslouchacího zařízení řadiče (výchozí: 9093) mezi uzly řadiče.
  • Neshoda ID clusteru: pokud jste restartovali pomocí kafka-storage.sh format na jednom z uzlů bez použití správného ID clusteru se uzly ke clusteru nepřipojí. 
# 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 nebyl přidán do clusteru

Když přidáte nového zprostředkovatele do existujícího clusteru KRaft, zprostředkovatel musí být naformátován se stejným ID clusteru jako stávající 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:"

Další kroky v sérii

Se součástí KRaft jste připraveni řešit pokročilejší aspekty konfigurace Kafka:

  • Článek 3 – Pokročilý výrobce a spotřebitel: podrobná konfigurace acks, idempotent producera zopakujte strategie, abyste zajistili trvanlivost bez duplikátů.
  • Článek 4 – Sémantika přesně jednou: Transakce Kafka pro atomické zápisy na více témat, s novým transakčním koordinátorem implementovaným v protokolu metadat KRaft.
  • Článek 11 – Kafka ve výrobě: KRaft cluster dimenzování, konfigurace replik řadičů, zotavení po havárii a zálohování protokolu metadat.

Propojení s ostatními sériemi

  • Pokročilý Kubernetes: nasazení Kafky na Kubernetes s operátorem Strimzi, správa trvalého úložiště a automatické škálování skupiny spotřebitelů.
  • Pozorovatelnost: Monitorování kvora KRaft pomocí nástroje JMX Exporter, kritické metriky jak kafka.controller:type=KafkaController,name=ActiveControllerCount a upozornění na volbu vůdce.