Apache Kafka 2.8 erlaubt ersten Blick auf die Zukunft ohne ZooKeeper

Während die Umbaumaßnahmen zum Abschied von ZooKeeper voranschreiten, erhält der Kafka AdminClient eine neue Describe Cluster API.

Lesezeit: 1 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 8 Beiträge
Apache Kafka 2.8 erlaubt ersten Blick auf die Zukunft ohne ZooKeeper

(Bild: Olga Visavi / Shutterstock.com)

Von
  • Matthias Parbel

Die Community und Confluent haben Version 2.8 des Message Broker Kafka vorgelegt. Das unter dem Dach der Apache Software Foundation (ASF) weiterentwickelte Open-Source-Projekt liefert mit dem neuen Release zahlreiche Verbesserungen, einige neue Funktionen und Fehlerbereinigungen und knüpft dabei unmittelbar am Release 2.7 an. Mit Blick auf Kafka 3.0 zielen viele der Neuerungen auf den angepeilten Abschied von ZooKeeper, den gemäß Kafka Improvement Proposal (KIP-500) ein selbstverwaltetes Metadaten-Quorum ersetzen soll.

Laut Ankündigung im Confluent-Blog soll Kafka 2.8 einen ersten Eindruck vermitteln, wie sich der Message Broker ohne ZooKeeper nutzen lässt. Neue Server und einfache Produce-Consume-Anwendungsfälle lassen sich bereits ohne ihn aufsetzen. Dabei übernimmt das interne Topic @metadata die Topic-Metadaten und Konfigurationen aus ZooKeeper. Es wird auf sämtliche Broker im Cluster repliziert und von einem Raft-Quorum verwaltet. Der Leader im Quorum übernimmt dabei die gleiche Rolle im Cluster, die bisher dem Controller zukommt. Abhängig von der neuen process.roles-Konfiguration kann ein Node künftig als Controller oder Broker fungieren – oder auch beide Rollen einnehmen. Da die Implementierung von KIP-500 jedoch noch nicht abgeschlossen ist und Funktionen fehlen, ist sie noch nicht für den produktiven Einsatz freigegeben.

Tim Berglund aus dem Developer Relations Team bei Confluent gibt im Video einen kompakten Überblick zu Apache Kafka 2.8

Als vorbereitenden Schritt zur Einführung neuer Admin-Funktionen erhält der Kafka AdminClient eine neue Describe Cluster API (KIP-700), über die er Cluster-Informationen vom Broker abrufen kann. Bisher nutzte der AdminClient dafür die primär auf Consumer- und Producer-Client zugeschnittene Metadata API. Die Describe Cluster API soll den AdminClient von der Metadata API und deren Pattern entkoppeln und so den Weg frei machen für neue Admin-Funktionen – und das ohne Einschränken für Consumer und Producer zu verursachen.

Mehr Details und einen vollständigen Überblick sämtlicher Neuerungen liefern der Confluent-Blogbeitrag zur Ankündigung der neuen Version sowie die Release Notes zu Apache Kafka 2.8.

(map)