Apache Kafka : Confluent fait enfin ses adieux à ZooKeeper

KRaft remplace définitivement Zookeeper

Depuis 2019 et l’annonce de Kafka 3.0, le projet de la communauté et de Confluent est de remplacer ZooKeeper par KRaft. Comme son nom l’indique, KRaft implémente l’algorithme et le protocole de consensus Raft.

Il gère les logs de métadonnées de Kafka (topics, partitions, configurations, etc.) à l’intérieur de la plateforme de streaming, sans recourir à un système tiers. Cette internalisation doit simplifier l’architecture de Kafka et donc sa maintenance.

Déployé sous forme de nœud, KRaft tient le même rôle que ZooKeeper, mais au sein de Kafka. Dans le principe, il se comporte comme son prédécesseur : KRaft a besoin d’un nombre minimum de nœuds pour s’exécuter. « Par exemple, un cluster à trois nœuds peut survivre à une panne. Un cluster à cinq nœuds peut survivre à deux pannes, et ainsi de suite », illustre la documentation de Confluent.

« Le leader du journal des métadonnées est appelé le contrôleur actif. Le contrôleur actif gère tous les appels de procédures distants effectués à partir des brokers. Les contrôleurs suiveurs répliquent les données écrites sur le contrôleur actif et servent de relais en cas de défaillance de ce dernier », y lit-on.

Cela promet une plus forte tolérance aux pannes.

Contrairement à ZooKeeper dont le nœud de contrôle pousse les mises à jour de métadonnées vers les brokers, avec KRaft ces nœuds de clusters « écoutent » le contrôleur actif à la recherche des actualisations, à travers l’API MetadataFetch. Ces données qu’il récupère, le broker les fait persister sur disque. Les états, eux, sont lus depuis la mémoire.

En plus d’une plus grande simplicité et d’une résilience éventuellement supérieure, cette phase de stockage par le broker doit lui permettre « de se lancer rapidement, même s’il y a des centaines de milliers, voire des millions de partitions ». À condition qu’il ait déjà eu accès aux métadonnées gérées par le contrôleur actif, sinon il recevra une image entière des métadonnées.

De son côté, Confluent assure que cela permet de gérer jusqu’à 10 fois plus de partitions qu’avec ZooKeeper, soit 2 millions de partitions au lieu de 200 000, selon ses tests. Toutefois, l’éditeur préfère être prudent et semble confiant sur la gestion de 400 000 partitions maximum.

KRaft avait déjà été introduit dans les versions ultérieures de la plateforme de Confluent. Les clients pouvaient encore s’appuyer sur ZooKeeper. Avec Confluent 8.0, l’ancien gestionnaire de coordination des brokers Kafka n’est plus du tout accessible, même en option. C’est également vrai avec Kafka 4.0, lancé par la communauté en mars 2025.

Des outils pour simplifier la migration

Pour migrer vers la nouvelle plateforme, il convient de suivre les étapes décrites par l’éditeur. L’opération consiste à provisionner au minimum trois à cinq contrôleurs KRaft, et d’y charger les métadonnées des brokers depuis ZooKeeper. Il faut ensuite passer progressivement les brokers gérés par ZooKeeper sous le nouveau mode de gestion. Durant cette période, les contrôleurs KRaft renvoient les métadonnées vers Zookeeper, dans un mode de double écriture. Une fois que tous les brokers sont régis par KRaft, il s’agit de s’assurer que toutes les métadonnées sont écrites et correctement routées avant de débrancher ZooKeeper. Cela veut aussi dire qu’il faudra utiliser Kafka 2.1, ou une version supérieure. Dès la version 3.7, l’API associée à ZooKeeper est dépréciée.

Une fois la migration effectuée, Confluent promet avant tout une simplification des opérations. Confluent fournit des playbooks Ansible pour automatiser ce processus. Un flux est également disponible depuis Confluent for Kubernetes.

Les témoignages des clients collectés par LeMagIT lors de Current London 2025 laissaient à penser que les versions antérieures de Kafka et ZooKeeper sont encore très utilisées, comme en 2023. Reste à voir si la migration se passe dans les meilleures conditions.

Puisqu’il est censé être plus performant, Confluent 8.0 est accompagné d’un nouveau centre de contrôle consacré à la gestion des opérations et à l’observabilité de la plateforme de streaming. Celui-ci est basé sur Prometheus et est connecté à Kafka à travers des intégrations OpenTelemetry. Cette suite d’observabilité affiche des données avec un délai de 2-3 minutes, au lieu de cinq minutes.

Ce centre de contrôle peut gérer jusqu’à 400 000 partitions, soit trois fois plus que le précédent (120 000 partitions). Avec ce centre, vient Confluent Manager for Apache Flink qui doit permettre de contrôler les pipelines associés.

Du chiffrement côté client dans Confluent Platform

L’autre fonctionnalité phare en disponibilité générale est le chiffrement côté client des champs (CSFLE), en sus du TLS et du système RBAC. Ici, l’éditeur s’appuie sur les KMS du marché, ceux d’AWS, GCP, Azure et HashiCorp Vault, déployé par les clients, et un système de chiffrement par encapsulation à l’aide de l’algorithme AES-GCM 256 bits.

Ici, le nom des clés de chiffrement maîtresses (KEK, Key Encryption Key) est enregistré dans un registre « DEK » (Data Encryption Key) associé au Schema Registry (mais gérées depuis le KMS), en sus des labels qui caractérisent la sensibilité des données contenues dans les champs.

Au moment de produire des données, le producteur récupère le schéma et les politiques de chiffrement depuis le « Schema Registry ». Ensuite, le producteur appelle la clé maîtresse depuis le KMS pour créer une clé de chiffrement qui est utilisé pour chiffrer les données. La clé d’encapsulation qui en résulte est stockée dans le registre DEK. Le consommateur reçoit les données avec les champs chiffrés. Il appelle le schéma, reçoit la clé DEK depuis le registre et appelle le KMS pour déchiffrer la clé ouvrant l’accès aux données.

Une même clé DEK semble être utilisée pour les données en provenance d’un producteur tant que la politique reste inchangée. Dans ce cas-là, le producteur utilise la clé DEK du registre pour encapsuler les données labélisées. Cela éviterait de générer des clés en trop grand volume : un KMS coûte cher. Et l’éditeur a bien prévu un système de rotation des clés pour actualiser les clés KEK et DEK.

Queue for Kafka : retour aux premiers émois

Justement, puisque Kafka est une architecture qui fait la relation entre des producteurs et des consommateurs, Confluent entend aussi améliorer la consommation des messages rassemblés en topics (flux de données contenant des partitions). Ainsi le système « de file d’attente » pour Kafka est en accès anticipé.

En réalité, il s’agit plutôt d’un système de « consommation et de traitement coopératif » appelé groupe de partage. L’idée ? Faire en sorte que des systèmes consommateurs souscrivent à une forme « d’abonnement à longue durée » à un ou plusieurs topics, d’où le nom Queue. Avec cela vient un nouveau protocole chargé du « rebalancing », c’est-à-dire de l’opération de coordination des consommateurs au sein d’un groupe.

« Le nombre de consommateurs d’un groupe peut être rapidement augmenté ou réduit selon les besoins, sans qu’il soit nécessaire de repartitionner le topic ».

En revanche, dans ce modèle, chaque consommateur dans un groupe partagé traite individuellement les messages. En clair, Confluent 8.0 et Kafka 4.0 peuvent être utilisés pour gérer la mise en file d’attente de jobs, traditionnellement mieux supportée par RabbitMQ ou ActiveMQ (alors que c’était un des buts premiers du projet Kafka).

« Étant donné que plusieurs membres d’un groupe de partage peuvent traiter les messages d’une seule partition “topic”, le nombre de partitions ne limite plus le degré de parallélisme des consommateurs », explique Gunnar Morling, principal technologist chez Confluent, dans un billet de blog. « Le nombre de consommateurs d’un groupe peut être rapidement augmenté ou réduit selon les besoins, sans qu’il soit nécessaire de repartitionner le topic ».

Cela pourrait servir à accomplir des tâches d’A/B testing par exemple. Toutefois, Gunnar Morling ne recommande pas une utilisation en production. Le système n’est pas encore suffisamment robuste.