Event-Streaming: Apache Kafka 3.2.0 ermöglicht sichere Cluster ohne Zookeeper

Inhaltsverzeichnis

Die aktuelle Version 3.2.0 des Projekts Kafka der Apache Software Foundation (ASF) kann mit einer ganzen Reihe neuer Features und einem ebenfalls neuen StandardAuthorizer aufwarten, der nicht mehr auf Zookeeper basiert.

Weiterer Schritt weg vom Zookeeper

Die Umstellung auf ein selbstverwaltetes Metadaten-Quorum steht bereits seit Version 2.8 an. Mit dem vorherigen Release 3.1.0 hatten die Apache-Kafka-Entwickler darüber hinaus davon abgeraten, KRaft im produktiven Einsatz zu verwenden. Diesen Ratschlag wiederholen sie auch bei dieser Version, doch haben sie nun zusammen mit mehreren Verbesserungen und Korrekturen einen auf KRaft-basierenden Authorizer eingeführt. Weiterhin gaben sie in diesem Zusammenhang bekannt, dass in der Community ein Vorschlag zur Kennzeichnung des KRaft-Modus als produktionsreif in Apache Kafka 3.3 diskutiert wird.

Im Kafka Improvement Proposal KIP-801 führt das Apache-Kafka-Team einen in die Software integrierten StandardAuthorizer ein, der nicht auf Zookeeper beruht. Er speichert seine Zugriffskontrolllisten (ACLs) im __cluster_metadata-Thema und wird standardmäßig in KRaft-Clustern verwendet. Damit erledigt dieser StandardAuthorizer laut der Beschreibung in KIP-801 tut all das, was AclAuthorizer bisher für Zookeeper-abhängige Cluster tat.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Hinweise zur Wiederherstellung einer Partition

Weiterhin ist der Controller nun dazu in der Lage, einem neu gewählten Topic-Partition-Leader mitzuteilen, ob er mit der Strategie der "unsauberen Leader-Wahl" (Unclean Leader Election) ausgesucht wurde, womit nicht garantiert ist, dass keine Daten verloren gegangen sind. Der Controller verwendet diese Strategie, wenn keines der In-Sync-Replikate aktiv ist. Benutzer können dann ein Replikat zu wählen, das nicht Teil des In-Sync-Replikatsets war. Diese Vorgehensweise soll in Zukunft beispielsweise dazu dienen, den Transaktionsstatus zu bereinigen, der nach einer solchen unsauberen Wahl möglicherweise inkonsistent geblieben ist.

Connect-APIs zur Auflistung aller Connector-Plugins

Bei den Connect-APIs haben die Entwickler ebenfalls Verbesserungen eingeführt. KIP-769 erweitert Endpunkt GET /connector-plugins um den neuen Abfrageparameter connectorsOnly. Setzt ein Programmierer diesen Parameter auf den Wert false, so listet er nicht nur die Konnektoren, sondern alle verfügbaren Plugins auf. Dieser neue Abfrageparameter soll Entwicklern helfen zu überprüfen, welche Plugins verfügbar sind, ohne dass sie dazu wissen müssen, wie die Connect-Laufzeitumgebung eingerichtet ist. Die Verwendung des neuen Parameters lautet GET /connector-plugins?connectorsOnly=false. Standardmäßig ist connectorsOnly aus Gründen der Kompatibilität mit dem früheren Verhalten auf true gesetzt.

KIP-769 fügt auch einen neuen Endpunkt hinzu, der die Konfigurationen eines bestimmten Plug-ins zurückgibt. Entwickler können den neuen Endpunkt in der folgenden Weise einsetzen:

GET /connector-plugins/<plugin>/config.

Der neue Endpunkt funktioniert mit allen Plugins, die von GET /connector-plugins zurückgegeben werden. Die Release-Notes geben interessierten Entwicklern einen kompletten und umfangreichen Überblick über alle Neuheiten und Veränderung bei Apache Kafka 3.2.0. Ein Download der Software steht ebenfalls auf der Webseite bereit.

(fms)