Kafka 4.0'da KRaft: Elveda ZooKeeper, Çekirdek Denetleyicisi ve Geçiş
Kafka 4.0 (Mart 2025), KRaft ile üç yıllık bir arada yaşamanın ardından ZooKeeper'ı kalıcı olarak kaldırdı. Bu ayrıntılı kılavuz, yeni Raft tabanlı çekirdek denetleyicisi Path'in nasıl çalıştığını açıklıyor Kafka 3.x'ten gelenler için zorunlu geçiş, gerçek operasyonel faydalar ve tuzaklar üretime geçiş sırasında kaçınılması gereken bir durumdur.
ZooKeeper'la İlgili Sorun
Neredeyse on yıldır her Apache Kafka kümesinin bir topluluğa ihtiyacı var Apache Hayvanat Bahçesi Bekçisi meta verileri yönetmek için ayrı: hangi aracıların etkin olduğu, hangi aracının hangi bölümün, konunun ve ACL meta verilerinin lideri olduğu. ZooKeeper bir koordinasyon sistemidir Sağlam ve güvenilir bir şekilde dağıtıldı, ancak bir dizi önemli operasyonel soruna yol açtı:
- Çift operasyonel karmaşıklık: Kafka'yı yöneten her ekibin ayrıca ayrı bir ZooKeeper kümesini yönetmesi gerekiyordu (tipik olarak 3 veya 5 düğüm), kendi izleme, yükseltme döngüsü ve farklı konfigürasyonu ile.
- Sınırlı meta veri ölçeklenebilirliği: ZooKeeper ~200.000 bölümün ötesinde performans düşüşü gösterdi çünkü her bölümün meta verileri ayrı ZooKeeper düğümleri olarak yazılmıştır.
- Yavaş denetleyici seçimi: Kafka komisyoncu denetleyicisi düştüğünde, yeni denetleyicinin tamsayıyı okuması gerekiyordu ZooKeeper'ın çalışmaya başlamadan önce küme durumunu kontrol etmesi, büyük kümeler için onlarca saniye sürebilecek bir işlemdir.
- Felaket kurtarmanın zorluğu: ZooKeeper'da veri kaybı olması durumunda Kafka kümesinin kurtarılması karmaşık ve riskli bir manuel süreçti.
KRaft Zaman Çizelgesi
- KIP-500 (2020): ZooKeeper'ı Kafka'dan kaldırmaya yönelik orijinal teklif
- Kafka'nın 2.8 (Nisan 2021): KRaft'ın erken erişimde olduğu ilk sürüm (yalnızca test amaçlı)
- Kafka'nın 3.3 (Ekim 2022): KRaft yeni kümeler için üretime hazır olduğunu duyurdu
- Kafka'nın 3.5 (Haziran 2023): ZooKeeper'dan KRaft'a geçiş aracı kullanıma sunuldu
- Kafka'nın 3.7 (Mart 2024): ZooKeeper modu kullanımdan kaldırıldı
- Kafka'nın 4.0'ı (Mart 2025): ZooKeeper modu kalıcı olarak kaldırıldı
KRaft Nasıl Çalışır: Raft Konsensus Günlüğü
Meta Veri Günlüğü Kavramı
KRaft'ta (Kafka Raft) benimsenen çözüm zariftir: meta veriler için harici bir sisteme bağlı olmak yerine,
Kafka meta verilerini bir Dahili Kafka konusu isminde @metadata.
Bu konu, denetleyici düğümleri arasında bir Raft protokolü aracılığıyla çoğaltılır.
KRaft'ta küme aracıları iki rolden birini (veya küçük kümelerde her ikisini de) üstlenirler:
- Kontrolörler: Küme meta verilerini yönetir. Bir üretim kümesinde 3 denetleyiciden oluşan bir çoğunluk önerilir. Aktif denetleyici (Raft lideri) tüm meta veri değişikliklerini işler ve bunları diğer denetleyicilere kopyalar.
- Komisyoncu: bölüm günlüklerini yönetir, üreticilere ve tüketicilere hizmet eder. Komisyoncular bir kopyasını saklar akış sırasında güncellenen, denetleyiciden alınan meta verilerin önbelleği.
Kafka'daki Raft Protokolü
Raft, anlaşılır olacak şekilde tasarlanmış (Paxos'tan farklı olarak) dağıtılmış bir fikir birliği algoritmasıdır. Kısacası: tüm yetersayı düğümleri arasından biri seçilir lider. Lider tüm kutsal yazıları alır, bunları takipçilere yayar ve düğümlerin çoğunluğu yazıyı onayladığında bunun taahhüt edildiğini düşünür.
KRaft'ta bu şöyle tercüme edilir:
- Lider denetleyiciye bir meta veri işlemi (konu oluşturma, bölüm lideri atama vb.) ulaşır
- Lider denetleyici, işlemi meta veri günlüğüne serileştirilmiş bir olay olarak yazar
- Olay, protokol aracılığıyla denetleyici takipçilerine kopyalanır
FETCH(mevcut Kafka kodundan yararlanılarak) - Denetleyicilerin çoğunluğu onayladığında (yesap), işlem gerçekleştirilir
- Aracılar, etkin denetleyiciden iletilen meta veri güncellemelerini şu şekilde alır:
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
Çekirdek Denetleyicisi: Boyutlandırma
Yeter sayı denetleyicisi fikir birliği kurallarına uyar: tolere etmek f başarısızlık, onlara ihtiyaç var 2f+1 düğüm.
- 3 kontrolör: 1 arızayı tolere eder (üretim için minimum konfigürasyon)
- 5 kontrolör: 2 eşzamanlı arızayı tolere eder (kritik kümeler için önerilir)
- 1 denetleyici: Yalnızca yerel geliştirme/test amaçlıdır, hata toleransı yoktur
Kontrolörler olabilir özel (yalnızca denetleyici rolü, kullanıcı bölümlerini yönetme) veya kombine (aynı zamanda komisyoncu görevi gören aynı makineler). Küçük kümeler için (< 10 aracı) denetleyiciler birleştiklerinde gayet iyiler. Büyük veya yüksek verimli kümeler için özel denetleyiciler yönetim yükünü yalıtır G/Ç yükü bölümlerinin meta verileri.
Sıfırdan KRaft Kümesini Yapılandırma
# 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
Önemli: Küme Kimliği Değiştirilemez
Il cluster.id format dosyaya yazıldığında oluşturulur meta.properties her düğümün
ve meta veri günlüğünde. Başlatma işleminden sonra değiştirilemez. Bu dosyayı kaybederseniz ve bir düğüm eklemek istiyorsanız
mevcut kümeye uygun önyükleme prosedürünü kullanmanız gerekir. Küme kimliğini bir sır yönetim sisteminde saklayın.
Docker Compose: Yerel Kalkınma için KRaft Kümesi
# 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:
ZooKeeper ile Kafka 3.x'ten KRaft'a geçiş
ZooKeeper modunda bir Kafka 3.x kümesi yönetiyorsanız ve KRaft'a geçiş yapmanız gerekiyorsa (Kafka 4.0 kullanmak için gereklidir), süreç denir KRaft geçişi ve 3.5 sürümünden beri resmi olarak desteklenmektedir. İyi haber: Göç gerçekleşiyor kesinti olmadan üreticiler ve tüketiciler için.
Göç Aşamaları
Resmi süreç 6 aşamaya ayrılmıştır:
-
Önkoşulları kontrol edin: Kafka 3.7'ye yükseltme (ZooKeeper+KRaft çift yazma desteğine sahip en son sürüm),
tüm brokerlerin sahip olup olmadığını kontrol edin
metadata.versionhizalanmış. - KRaft denetleyici dağıtımı: KRaft denetleyici düğümlerini başlatın (3 yeni düğüm veya mevcut aracılar) ek rol). Denetleyiciler, geçiş aracı aracılığıyla ZooKeeper'dan ilk meta verileri alır.
- Çift yazma modu: Komisyoncular meta verileri hem ZooKeeper'a hem de KRaft meta veri günlüğüne yazar. Bu aşamada sistem tamamen çalışır durumdadır.
- Taşıma tamamlandı: tüm komisyoncular geçiş yapar, ZooKeeper Kafka için salt okunur hale gelir. Üretici ve tüketiciler herhangi bir kesinti algılamıyor.
- ZooKeeper sonlandırıcı: ZooKeeper'dan Kafka meta verilerini temizleyen sonlandırıcıyı çalıştırın.
- ZooKeeper'ı Kapat: ZooKeeper topluluğunun hizmet dışı bırakılması. Tamamen KRaft kümesi.
# 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
Geçişle İlgili Önemli Bildirimler
- Kolayca geri dönmeyin: KRaft geçişi tamamlandıktan ve ZooKeeper kaldırıldıktan sonra, geri alma işlemi çok karmaşıktır. Öncelikle üretime benzer bir hazırlama ortamına geçin.
- ACL'ler ve yapılandırmalar: ZooKeeper aracılığıyla yönetilen ACL'ler ve dinamik yapılandırmalar taşınır meta veri günlüğünde otomatik olarak yer alır, ancak geçişten sonra bunların mevcut olup olmadığını kontrol edin.
- Bağlayıcı Kafka Bağlantısı: Durum için arka uç olarak Kafka kümesini kullanan bağlayıcılar (group.id, offsets) değişmeden çalışmaya devam eder.
- Ayna Yapıcı 2: Coğrafi çoğaltma için MM2 kullanıyorsanız uzak kümeleri aynı Sürüm uyumsuzluklarını önlemek için bakım penceresi.
Gelişmiş Konfigürasyonlu KRaft: Özel Kontrolörler
Verimi yüksek olan veya çok sayıda bölümü yöneten (>50.000) kümeler için, denetleyicilerin aracılardan (özel denetleyiciler) ayrılması tavsiye edilir. Bunu beğen meta veri işlemleri (konu oluşturma, lider seçimi, yapılandırma değişikliği) rekabet etmez aynı disklerde bölüm günlüğü G/Ç ile.
# 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
Confluent Cloud'da ve Amazon MSK (3.6 sürümünden beri KRaft'ı benimseyen) gibi yönetilen ortamlarda, denetleyici/aracı ayrımı otomatik olarak gerçekleşir ve kullanıcı için şeffaftır.
KRaft'ın Operasyonel Faydaları
Daha Hızlı Başlatma ve Kurtarma
ZooKeeper ile Kafka aracı denetleyicisi yeniden başlatıldığında kümenin tüm durumunu okumak zorundaydı Çalıştırmadan önce ZooKeeper'dan. 100.000'den fazla bölüme sahip kümeler için bu, 30-90 saniye denetleyicinin kullanılamaması.
KRaft ile lider denetleyici, meta veri günlüğünü zaten bellekte ve yerel diskte tutar. Yük devretme kontrolörün tipik olarak gerektirdiği 5 saniyeden az, büyük kümeler için bile. Bir vaka çalışması Bir fintech şirketinin raporu (Confluent Engineering Blog, 2025), kurulum süresinde %40'lık bir azalmayı belgeliyor KRaft'a taşındıktan sonra.
Meta Veri Ölçeklenebilirliği
ZooKeeper'ın küme başına yaklaşık 200.000 bölümlük pratik bir sınırı vardı (performansa bakılmaksızın) meta veri işlemlerinin sayısı önemli ölçüde azaldı). KRaft meta veri günlüğünü normal şekilde işler Kafka sıkıştırmayla günlüğe kaydeder ve aşağıdakilerle test edilmiştir: milyonlarca bölüm küme başına.
Operasyonel Basitlik
ZooKeeper'ı kaldırmak şu anlama gelir:
- İki yerine izlenecek tek sistem
- İki yerine bir yükseltme döngüsü (ZooKeeper ve Kafka'nın genellikle karmaşık sürüm kısıtlamaları vardı)
- Kubernetes'te daha kolay dağıtım (daha az StatefulSet, daha az PVC)
- Daha kolay felaket kurtarma (küme durumu meta veri günlüğündedir, Kafka ile ZooKeeper arasında dağıtılmaz)
Strimzi ile Kubernetes'te KRaft
Strimzi Kafka'yı yönetmek için en popüler Kubernetes operatörüdür. 0.38 sürümünden itibaren, Strimzi yerel olarak KRaft'ı desteklemektedir:
# 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
KRaft Cluster'ın durumunu kontrol etme
# 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
Konfigürasyon Farklılıkları: ZooKeeper ve KRaft
ZooKeeper kümesinden gelenlerin bilmesi gereken ana yapılandırma farklılıkları şunlardır:
| Yapılandırma | Hayvanat Bahçesi Bekçisi Modu | KRaft Modu |
|---|---|---|
| Küme bağlantısı | zookeeper.connect |
controller.quorum.voters |
| Düğüm kimliği | broker.id |
node.id |
| Roller | Her zaman komisyoncu | process.roles |
| Dinleyici kontrolörleri | Yok | controller.listener.names |
| Başlatma | Araba (ZK kolları) | kafka-storage.sh format |
| ACL depolama | ZooKeeper znode'ları | Meta veri günlüğü |
KRaft'ta Meta Veri Sürümü ve Özellik Bayrakları
Kafka, KRaft ile konseptini tanıtıyor metadata.version: Meta veri formatının bir versiyonu kümede. Bu, bir kümenin, her seferinde bir düğüm olmak üzere, kesinti olmaksızın sürekli yükseltilmesine olanak tanır. Meta veri sürümü yalnızca kümedeki tüm aracılar yeni sürümü desteklediğinde güncellenir.
# 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
Sürüm 4.0-IV3 (Kafka 4.0 Artımlı Sürüm 3) sürümdeki en son sürümdür
Kafka 4.0 Mart 2025. Her sürüm artışı yeni özellikler ve protokol optimizasyonlarına olanak tanır.
KRaft Sorun Giderme: Yaygın Sorunlar
Küme Başlamıyor: “Çoğunlukta seçmen bulunamadı”
Bu hata, denetleyici düğümlerinin diğer çekirdek seçmenlerini bulamadığını gösterir. Yaygın nedenler:
-
yanlış yapılandırılmış denetleyici.quorum.voters: Formatın doğru olduğunu doğrulayın
(
nodeId@hostname:port) ve ana bilgisayar adlarının tüm düğümler tarafından çözülebilir olduğunu. - CONTROLLER dinleyicisine ulaşılamıyor: Güvenlik duvarının izin verdiğini doğrulayın denetleyici düğümleri arasında denetleyici dinleyici bağlantı noktasındaki iletişim (varsayılan: 9093).
-
Küme kimliği uyuşmazlığı: ile yeniden başlattıysanız
kafka-storage.sh formatDoğru küme kimliğini kullanmadan düğümlerden birinde düğümler kümeye katılmayacaktır.
# 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 Kümeye Eklenmedi
Mevcut bir KRaft kümesine yeni bir aracı eklediğinizde aracının biçimlendirilmesi gerekir mevcut kümeyle aynı küme kimliğiyle:
# 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:"
Serideki Sonraki Adımlar
KRaft dahil olduğunda Kafka konfigürasyonunun daha gelişmiş yönlerini ele almaya hazırsınız:
-
Madde 3 – İleri Üretici ve Tüketici: ayrıntılı yapılandırması
acks,idempotent producerve kopyalar olmadan dayanıklılık sağlamak için stratejileri yeniden deneyin. - Madde 4 – Tam Olarak Bir Kez Anlambilimi: Atomik yazmalar için Kafka işlemleri KRaft meta veri günlüğüne uygulanan yeni işlem koordinatörüyle birden fazla konu hakkında.
- Madde 11 – Üretimde Kafka: KRaft küme boyutlandırması, yapılandırması Denetleyici kopyaları, olağanüstü durum kurtarma ve meta veri günlüğü yedeklemesi.
Diğer Serilerle Bağlantı
- Gelişmiş Kubernet'ler: Strimzi operatörü ile Kafka'nın Kubernetes üzerinde konuşlandırılması, kalıcı depolama yönetimi ve tüketici grubu otomatik ölçeklendirme.
-
gözlemlenebilirlik: JMX Exporter ile KRaft çekirdek takibi, kritik ölçümler
nasıl
kafka.controller:type=KafkaController,name=ActiveControllerCountve lider seçimi konusunda uyarı.







