Novità in Kafka 4.0 e 4.1

Novità in Kafka 4.0 e 4.1: La Nuova Era della Piattaforma di Event Streaming

Indice Novità in Kafka 4.0 e 4.1

1. Introduzione a Kafka e il contesto delle versioni 4.x
2. KRaft: l’addio definitivo a ZooKeeper
3. Il nuovo protocollo di rebalancing dei consumer (KIP-848)
4. Share Groups e semantica a code (KIP-932)
5. Kafka Streams Rebalance Protocol (KIP-1071)
6. Kafka Connect: gestione multi-versione dei plugin (KIP-891)
7. Requisiti di sistema e aggiornamenti tecnologici
8. Quando e come aggiornare a Kafka 4.x
9. L’importanza della formazione del team IT

1. Introduzione a Kafka e il contesto delle versioni 4.x

Apache Kafka è una piattaforma distribuita di event streaming che consente di pubblicare, memorizzare e processare flussi di eventi in tempo reale. Originariamente sviluppato da LinkedIn e successivamente donato alla Apache Software Foundation, Kafka si è affermato come standard de facto per architetture event-driven e microservizi.

Le versioni 4.0 e 4.1 di Apache Kafka, rilasciate rispettivamente il 18 marzo 2025 e il 4 settembre 2025, rappresentano milestone storiche nell’evoluzione della piattaforma. Kafka 4.0 introduce cambiamenti architetturali fondamentali con la rimozione completa di ZooKeeper, mentre Kafka 4.1 espande ulteriormente le funzionalità con miglioramenti a Kafka Streams, Connect e il passaggio di KIP-932 da early access a preview. Per ingegneri e architetti cloud, comprendere queste innovazioni è essenziale per progettare sistemi scalabili e performanti.

2. KRaft: l’addio definitivo a ZooKeeper

La modifica più significativa di Kafka 4.0 è l’eliminazione totale di Apache ZooKeeper come sistema di gestione dei metadati. Dopo oltre 13 anni di servizio, ZooKeeper viene definitivamente sostituito da KRaft (Kafka Raft), il protocollo di consenso interno di Kafka basato sull’algoritmo Raft.

Vantaggi architetturali di KRaft:

• Semplificazione operativa: non è più necessario mantenere un cluster ZooKeeper separato, riducendo drasticamente la complessità infrastrutturale
• Scalabilità migliorata: KRaft elimina i limiti di scalabilità imposti da ZooKeeper, consentendo cluster con milioni di partizioni
• Prestazioni superiori: la gestione dei metadati è più efficiente, con tempi di startup e recovery significativamente ridotti
• Architettura unificata: Kafka diventa completamente autosufficiente nella gestione del proprio stato distribuito

Migrazione obbligatoria: È fondamentale comprendere che Kafka 4.0 supporta esclusivamente KRaft. I cluster esistenti basati su ZooKeeper devono essere migrati a KRaft prima di poter effettuare l’upgrade alla versione 4.0. La documentazione ufficiale fornisce un processo di migrazione online che minimizza i downtime, articolato in diverse fasi controllate.

Esempio configurazione KRaft (server.properties):

process.roles=broker,controller
node.id=1
controller.quorum.voters=1@localhost:9093
listeners=PLAINTEXT://localhost:9092,CONTROLLER://localhost:9093

3. Il nuovo protocollo di rebalancing dei consumer (KIP-848)

KIP-848 introduce una revisione completa del protocollo di rebalancing dei consumer group, eliminando il paradigma “stop-the-world” che caratterizzava le versioni precedenti. Questo rappresenta un miglioramento critico per deployment su larga scala dove operazioni di scaling o restart sono frequenti.

Caratteristiche principali:

• Gestione server-side: il broker coordina direttamente il rebalancing, eliminando la complessità client-side
• Rebalancing incrementale: solo le partizioni interessate vengono riassegnate, mentre il resto del gruppo continua a processare messaggi
• Latenza ridotta: i test dimostrano riduzioni dei tempi di rebalancing fino a 20 volte rispetto al protocollo classico
• Client semplificati: la logica di coordinamento spostata sul server rende i client più leggeri e facili da implementare

Abilitazione del nuovo protocollo (configurazione consumer Java):

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "my-consumer-group");
props.put("group.protocol", "consumer"); // Nuovo protocollo KIP-848
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);

Per JavaScript (Node.js con KafkaJS):

const { Kafka } = require('kafkajs');

const kafka = new Kafka({
  clientId: 'my-app',
  brokers: ['localhost:9092']
});

const consumer = kafka.consumer({ 
  groupId: 'my-group',
  // Il supporto al nuovo protocollo sarà disponibile nelle versioni future
});

Importante: il nuovo protocollo è abilitato di default sul server, ma i consumer devono opt-in tramite la configurazione group.protocol=consumer. Il protocollo classico rimane disponibile per compatibilità retroattiva.

4. Share Groups e semantica a code (KIP-932)

KIP-932 introduce il concetto rivoluzionario di Share Groups, portando semantica di tipo message queue direttamente in Kafka. Questa funzionalità è passata da early access in Kafka 4.0 a preview in Kafka 4.1, segnalando un progresso significativo verso la stabilità produttiva.

Differenze rispetto ai Consumer Groups tradizionali:

• Consumo cooperativo: multiple consumer possono processare messaggi dalla stessa partizione simultaneamente
• Scalabilità indipendente: il numero di consumer può superare il numero di partizioni
• Acknowledgement individuale: ogni messaggio può essere confermato singolarmente
• Retry automatici: i messaggi non processati vengono automaticamente riassegnati
• Delivery count tracking: Kafka monitora i tentativi di delivery per gestire poison messages

Caso d’uso tipico: workload dove i messaggi sono work item indipendenti che possono essere processati in parallelo, come job queues, task processing o microservizi stateless.

Abilitazione Share Groups (Kafka 4.1):

bin/kafka-features.sh --bootstrap-server localhost:9092 \
  upgrade --feature share.version=1

Esempio Share Consumer Java:

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "my-share-group");

KafkaShareConsumer<String, String> shareConsumer = 
  new KafkaShareConsumer<>(props);

shareConsumer.subscribe(Collections.singleton("work-queue-topic"));

while (true) {
  ConsumerRecords<String, String> records = 
    shareConsumer.poll(Duration.ofMillis(100));
  for (ConsumerRecord<String, String> record : records) {
    try {
      processWorkItem(record.value());
      shareConsumer.acknowledge(record); // ACK individuale
    } catch (Exception e) {
      // Il messaggio verrà automaticamente riassegnato
    }
  }
}

Nota bene: KIP-932 è ancora in preview in Kafka 4.1 e non è raccomandato per ambienti di produzione. Il supporto completo (General Availability) è previsto per Kafka 4.2.

5. Kafka Streams Rebalance Protocol (KIP-1071)

Una delle novità più significative di Kafka 4.1 è l’introduzione del nuovo protocollo di rebalancing specifico per Kafka Streams (KIP-1071), attualmente in early access. Questo protocollo, basato su KIP-848, sposta la logica di coordinamento dal client al broker, rendendo Kafka Streams più affidabile e scalabile.

Vantaggi del nuovo protocollo:

• Coordinamento centralizzato: l’assegnazione dei task viene gestita direttamente dal broker
• Creazione automatica dei topic interni: il broker gestisce la creazione di changelog e repartition topics
• Rebalancing più stabili: riduzione drastica degli incidenti legati alla logica di rebalancing
• Eliminazione dei probing rebalances: non sono più necessari i dummy rebalance per propagare lo stato
• Gestione semplificata: meno configurazioni da gestire per gli operatori

Configurazione per abilitare il nuovo protocollo:

Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "my-streams-app");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.GROUP_PROTOCOL_CONFIG, "streams"); // Nuovo protocollo

Nuovi tool amministrativi: Kafka 4.1 introduce kafka-streams-groups.sh per gestire i streams groups separatamente dai consumer groups classici:

bin/kafka-streams-groups.sh --bootstrap-server localhost:9092 \
  --describe --group my-streams-app

Limitazioni attuali (early access in 4.1):

• Static membership non supportato
• Solo sticky assignor disponibile
• Pattern-based topic subscription non supportato
• Migrazione online tra protocolli non disponibile

Il protocollo raggiungerà General Availability in Kafka 4.2 con interfacce, record e RPC marcati come stabili.

6. Kafka Connect: gestione multi-versione dei plugin (KIP-891)

Kafka 4.1 introduce KIP-891, una funzionalità molto attesa che permette di eseguire multiple versioni dello stesso plugin Connect simultaneamente. Questo semplifica notevolmente gli upgrade e le operazioni di rollback.

Vantaggi principali:

• Upgrade graduali: possibilità di testare nuove versioni su connettori specifici senza impattare l’intero cluster
• Rollback semplificati: ritorno a versioni precedenti senza riavvio completo del cluster
• Consolidamento infrastrutturale: non è più necessario mantenere cluster Connect separati per versioni diverse
• Testing sicuro: validazione di nuove versioni in produzione su workload limitati

Configurazione multi-versione:

{
  "name": "my-connector",
  "connector.class": "org.example.MyConnector",
  "connector.plugin.version": "2.0.0",
  "tasks.max": "3",
  "transforms": "addTimestamp",
  "transforms.addTimestamp.type": "org.example.TimestampTransform",
  "transforms.addTimestamp.plugin.version": "1.5.0"
}

Struttura directory plugin.path:

plugins/
├── my-connector-v1.0.0/
│   └── my-connector-1.0.0.jar
├── my-connector-v2.0.0/
│   └── my-connector-2.0.0.jar
└── transforms/
    ├── timestamp-v1.5.0/
    │   └── timestamp-transform-1.5.0.jar
    └── timestamp-v2.0.0/
        └── timestamp-transform-2.0.0.jar

I plugin devono essere installati in subdirectory separate sotto plugin.path per garantire l’isolamento classloader. KIP-891 supporta versioning per connettori, converters, transformations e predicates.

7. Requisiti di sistema e aggiornamenti tecnologici

Le versioni 4.0 e 4.1 modernizzano significativamente i requisiti runtime, allineandosi con le versioni LTS di Java che offrono miglioramenti sostanziali in termini di performance, sicurezza e garbage collection.

Requisiti Java obbligatori:

• Kafka Clients e Kafka Streams: Java 11+ obbligatorio
• Kafka Brokers, Connect e Tools: Java 17+ obbligatorio
• Versioni supportate: Java 17 e Java 23

Il supporto per Java 8 è stato completamente rimosso. Questa scelta garantisce l’utilizzo di algoritmi GC moderni (come ZGC e Shenandoah), miglioramenti nelle performance delle API Collections, e patch di sicurezza a lungo termine.

Altri aggiornamenti importanti:

• Log4j2: transizione completa da Log4j a Log4j2, motivata dalla vulnerabilità Log4Shell. Kafka fornisce il tool log4j-transform-cli per convertire automaticamente le configurazioni esistenti
• Protocolli API: rimozione di versioni obsolete (baseline ora Kafka 2.1+)
• MirrorMaker 1: completamente rimosso, necessario migrare a MirrorMaker 2
• Message formats v0 e v1: deprecati in Kafka 3.0, completamente rimossi in 4.0

Novità Kafka 4.1:

• KIP-1050: gestione errori migliorata per transazioni con categorie di eccezioni più chiare
• KIP-1109: unificazione metriche consumer topic (i nomi topic con dots non vengono più convertiti in underscores)
• KIP-1118: protezione deadlock nel network thread del producer
• KIP-1139: supporto OAuth jwt-bearer grant type oltre a client_credentials

8. Quando e come aggiornare a Kafka 4.x

Prerequisiti per l’upgrade:

1. Versione minima: il cluster deve essere in KRaft mode e versione software 3.3.x o superiore per Kafka 4.0
2. Client compatibility: tutti i client devono essere versione 2.1+ prima dell’upgrade
3. Test approfonditi: validare l’applicazione in ambiente non-produttivo

Strategia di upgrade consigliata:

Per cluster ZooKeeper-based → Kafka 4.0:

1. Upgrade a Kafka 3.9.x (ultima versione con supporto ZooKeeper)
2. Eseguire migrazione ZooKeeper → KRaft secondo la documentazione ufficiale
3. Validare stabilità del cluster in KRaft mode
4. Upgrade a Kafka 4.0

Per cluster già in KRaft mode → Kafka 4.0:

1. Verificare compatibilità client e applicazioni
2. Aggiornare JDK a versione 17+ (broker) e 11+ (client)
3. Convertire configurazioni Log4j a Log4j2
4. Rolling upgrade dei broker
5. Finalizzare l’upgrade: bin/kafka-features.sh --bootstrap-server localhost:9092 upgrade --release-version 4.0

Da Kafka 4.0 → Kafka 4.1:

1. Verificare che il cluster sia stabile su 4.0
2. Eseguire rolling upgrade dei broker a 4.1
3. Valutare opt-in graduale per nuove funzionalità:
   • KIP-848 consumer protocol (production-ready)
   • KIP-932 Share Groups (preview, non per produzione)
   • KIP-1071 Streams protocol (early access, non per produzione)
   • KIP-891 Connect multi-version (production-ready)

Best practices operative:

• Testare in staging con carichi di lavoro realistici
• Pianificare finestre di manutenzione per il rolling restart
• Monitorare metriche critiche (latency, throughput, rebalancing time) durante e dopo l’upgrade
• Mantenere un piano di rollback documentato
• Non abilitare feature early-access o preview in produzione
• Per Kafka Streams, considerare il nuovo protocollo solo in 4.2 quando raggiungerà GA
• Utilizzare il nuovo protocollo consumer (KIP-848) progressivamente, iniziando da consumer group non critici

Considerazioni per Kafka 4.1:

La migrazione online tra protocolli (classic ↔ streams per Kafka Streams) non è disponibile in 4.1. È necessario pianificare una finestra di manutenzione per la migrazione. KIP-932 (Share Groups) è ora in preview ma ancora non pronto per produzione; si consiglia di attendere Kafka 4.2 per il supporto completo.

9. L’importanza della formazione del team IT – Novità in Kafka 4.0 e 4.1

L’adozione di Kafka 4.0 e 4.1 non è solo una questione tecnica, ma richiede un investimento strategico nella formazione del team IT. Le modifiche architetturali introdotte – dalla rimozione di ZooKeeper ai nuovi protocolli per consumer, Streams e Connect – richiedono competenze aggiornate per essere gestite efficacemente.

Aree critiche di formazione:

• Comprensione approfondita di KRaft e differenze con ZooKeeper
• Procedure di migrazione e troubleshooting
• Ottimizzazione delle performance con il nuovo protocollo di rebalancing (KIP-848)
• Gestione operativa di cluster KRaft-based
• Kafka Streams con il nuovo protocollo (KIP-1071)
• Utilizzo di Share Groups per casi d’uso a code (KIP-932)
• Gestione multi-versione dei plugin Connect (KIP-891)
• Monitoring e observability delle nuove metriche
• Gestione errori migliorata per transazioni

Un team adeguatamente formato è in grado di:

• Pianificare ed eseguire migrazioni complesse senza errori
• Risolvere rapidamente problemi in produzione
• Sfruttare appieno le nuove funzionalità per migliorare le architetture esistenti
• Ridurre i rischi durante gli upgrade critici
• Valutare correttamente quando adottare feature in early access o preview
• Implementare best practices operative per KRaft, il nuovo consumer protocol e Kafka Streams

Formazione aziendale personalizzata

Per supportare le aziende in questo percorso di aggiornamento alle versioni 4.x, è fondamentale investire in programmi di formazione strutturati. Innovaformazione offre corsi specializzati su Apache Kafka, progettati per team IT che necessitano di competenze pratiche e immediatamente applicabili.

Il Corso Apache Kafka è disponibile in modalità online classe virtuale, con calendario concordabile in base alle esigenze aziendali. Il percorso formativo copre sia i fondamenti di Kafka che le novità introdotte nelle ultime release, con particolare focus su scenari reali e best practices operative specifiche per le versioni 4.0 e 4.1.

Accesso alla formazione finanziata: Le aziende possono accedere alla formazione completamente gratuita attraverso Fondimpresa, il fondo interprofessionale per la formazione continua. Innovaformazione gestisce l’intero processo – dalla progettazione del piano formativo alla rendicontazione finale – semplificando l’accesso ai finanziamenti disponibili e permettendo alle aziende di formare il proprio personale tecnico senza costi diretti.

Investire nella formazione significa garantire che il proprio team sia preparato ad affrontare le sfide tecnologiche di Kafka 4.x, riducendo il rischio di errori costosi durante progetti critici e massimizzando il ritorno sull’investimento infrastrutturale. Con l’introduzione di funzionalità complesse come KRaft, il nuovo consumer protocol, Share Groups e il protocollo Streams, la formazione diventa ancora più cruciale per evitare configurazioni errate e ottimizzare le performance del sistema.

Per richiedere un preventivo personalizzato e valutare le opzioni di finanziamento disponibili tramite Fondimpresa, è possibile contattare Innovaformazione attraverso il sito ufficiale. Il team di esperti può progettare percorsi formativi su misura che coprono specificatamente le novità delle versioni 4.0 e 4.1, garantendo che il personale IT acquisisca le competenze necessarie per gestire efficacemente l’infrastruttura Kafka moderna.

INFO: info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)

(fonte) (fonte) (fonte)

Per altri articoli tecnici consigliamo di navigare sul nostro blog QUI.