Kafka-Testumgebung einrichten

Lerne, wie wir eine Multi-Node Kafka-Testumgebung auf einem einzelnen Rechner für Entwicklungs- und Testzwecke einrichten. Diese Anleitung zeigt uns, wie wir drei Kafka-Broker mit korrekter Controller-Konfiguration konfigurieren.

Von Arockia Nirmal Amala Doss

Dieser Blogbeitrag bietet eine praktische Anleitung zum Einrichten einer Kafka-Testumgebung. Wenn ihr mehr über Kafka lernen möchtet, lest die folgenden Artikel:

In diesem Blogbeitrag geben wir einen kurzen Überblick darüber, wie wir eine Kafka-Testumgebung auf einem einzelnen Rechner, wie einem persönlichen Laptop, einrichten. Diese Konfiguration ist ausschließlich für Test- und Entwicklungszwecke gedacht und sollte niemals in einer Produktionsumgebung verwendet werden. Im Gegensatz zu vielen Tutorials, die sich auf Single-Node-Installationen konzentrieren, zeigen wir, wie wir eine Multi-Node Kafka-Umgebung auf einem einzelnen Rechner konfigurieren. Dieser Ansatz ermöglicht es uns, zu beobachten, wie Kafka mit Teilausfällen umgeht und seine verteilte Natur besser zu verstehen.

Testumgebung-Übersicht

Kafka Cluster
Figure 1. Unsere Testumgebung besteht aus drei Kafka-Brokern im Dual-Modus.

In der obigen Abbildung zeigen wir die Testumgebung, die aus drei Kafka-Brokern besteht. Broker 1 lauscht auf Port 9092, Broker 2 auf 9093 und Broker 3 auf 9094. Um das Setup zu vereinfachen, führen wir die Broker im Dual-Modus aus, was bedeutet, dass die drei Broker sowohl als Controller als auch als normale Broker fungieren. Die Controller benötigen zusätzliche Listener, daher lauscht der Controller von Broker 1 auf Port 9192, von Broker 2 auf 9193 und der Controller von Broker 3 auf 9194.

Betriebssystem

Apache Kafka läuft in der Java Virtual Machine (JVM) und unterstützt somit alle gängigen Betriebssysteme. Wir haben diese Umgebung auf Ubuntu 24.04 LTS und auf MacOS getestet. Auf Windows-Systemen empfehlen wir die Verwendung des Windows Subsystem for Linux (WSL).

Kafka herunterladen

Wir finden immer die aktuellste Version von Kafka unter https://kafka.apache.org/downloads. Zum Zeitpunkt des Schreibens ist die neueste Version 3.9.0. Da einige Teile von Kafka noch in Scala geschrieben sind, finden wir Downloads der Form kafka_2.13-3.9.0.tgz, wobei 2.13 die Scala-Version und 3.9.0 die Kafka-Version ist. Wir empfehlen immer, die neueste Scala-Version zu verwenden. Lassen wir uns Kafka herunterladen und in das Verzeichnis ~/kafka extrahieren:

wget "https://downloads.apache.org/kafka/3.9.0/kafka_2.13-3.9.0.tgz"
tar xfz kafka_2.13-3.9.0.tgz
rm kafka_2.13-3.9.0.tgz
mv kafka_2.13-3.9.0/ ~/kafka

Wir finden die folgenden Unterverzeichnisse im ~/kafka-Verzeichnis:

  • LICENSE, NOTICE: Dateien mit Lizenzinformationen

  • bin: Kommandozeilen-Tools zur Interaktion mit Kafka

  • config: Konfigurationsdateien

  • libs: Java-Bibliotheksdateien (*.jar)

  • site-docs: Dokumentation

Voraussetzungen

Zuerst stellen wir sicher, dass Java auf unserem Rechner installiert ist:

java -version

Kafka konfigurieren

Konfigurieren wir zuerst Broker 1:

~/kafka/config/kafka1.properties
# Die ID des Brokers (hier 1)
broker.id=1
# Das Verzeichnis, in dem der Broker die Dateien speichern soll. Bitte passen wir das Verzeichnis an.
log.dirs=<PFAD-ZU-DEINEM-USER-VERZEICHNIS>/kafka/data/kafka1
# Wir verwenden Port 9092 für normale Broker-Kommunikation und Port 9192 für den Controller.
# Wir können die Listener nennen, wie wir möchten
listeners=PLAINTEXT://:9092,CONTROLLER://:9192
# Wir führen den Broker im Dual-Modus aus
process.roles=broker,controller
# Wir stellen die Verbindungszeichenkette für alle unsere Controller bereit
controller.quorum.voters=1@localhost:9192,2@localhost:9193,3@localhost:9194
# Welcher Listener soll für den Controller verwendet werden?
controller.listener.names=CONTROLLER
# Wir verwenden für unsere Testumgebung kein TLS
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT

Konfigurieren wir auch Broker 2:

~/kafka/config/kafka2.properties
broker.id=2
log.dirs=<PFAD-ZU-DEINEM-USER-VERZEICHNIS>/kafka/data/kafka2
listeners=PLAINTEXT://:9093,CONTROLLER://:9193
process.roles=broker,controller
controller.quorum.voters=1@localhost:9192,2@localhost:9193,3@localhost:9194
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT

Konfigurieren wir schließlich Broker 3:

~/kafka/config/kafka3.properties
broker.id=3
log.dirs=<PFAD-ZU-DEINEM-USER-VERZEICHNIS>/kafka/data/kafka3
listeners=PLAINTEXT://:9094,CONTROLLER://:9194
process.roles=broker,controller
controller.quorum.voters=1@localhost:9192,2@localhost:9193,3@localhost:9194
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT

Datenverzeichnisse vorbereiten

Zuerst erstellen wir die Verzeichnisse, in denen die Broker die Daten speichern sollen. Danach müssen wir die Verzeichnisse initialisieren (formatieren), damit wir sie in unserem Cluster verwenden können. Dafür benötigen wir eine Cluster-ID. Auf diese Weise ist es unmöglich, ein Verzeichnis mit einem anderen Cluster zu verwenden, was die Fehler, die wir machen können, begrenzt.

mkdir -p ~/kafka/data/kafka1 ~/kafka/data/kafka2 ~/kafka/data/kafka3
export KAFKA_CLUSTER_ID="$(kafka-storage.sh random-uuid)"
kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c ~/kafka/config/kafka1.properties
kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c ~/kafka/config/kafka2.properties
kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c ~/kafka/config/kafka3.properties

Kafka starten

Jetzt ist es Zeit, unsere Broker zu starten. Zuerst starten wir die Broker im Vordergrund, damit wir mögliche Fehler sehen können, und wenn alles funktioniert, starten wir die Broker im Hintergrund als Daemon. Starten wir den ersten Broker:

~/kafka/bin/kafka-server-start.sh ~/kafka/config/kafka1.properties

Wenn dieser Befehl sofort abstürzt, haben wir den Broker falsch konfiguriert. Bitte überprüfe die Konfiguration und versuche es erneut.

Wenn alles richtig gemacht wurde, sollte der Kafka-Broker sich über Node 2 und 3 beschweren, die nicht erreichbar sind:

WARN [RaftManager nodeId=1] Connection to node 2 (localhost/127.0.0.1:9193) could not be established.
Broker may not be available. (org.apache.kafka.clients.NetworkClient)

Das ergibt Sinn, weil wir die anderen Broker noch nicht gestartet haben. Öffne ein neues Terminal-Fenster und starte den zweiten Broker:

~/kafka/bin/kafka-server-start.sh ~/kafka/config/kafka2.properties

Wir sollten viele Log-Nachrichten sehen. Die Broker werden sich immer noch über den fehlenden Node 3 beschweren, aber zwischen all den Log-Nachrichten können wir die folgende Zeile finden:

[KafkaRaftServer nodeId=2] Kafka Server started

Starten wir schließlich den verbleibenden Broker:

~/kafka/bin/kafka-server-start.sh ~/kafka/config/kafka3.properties

Danach sollten wir die folgende Zeile in den Logs von Broker 3 sehen, und die Broker sollten aufgehört haben, sich darüber zu beschweren, dass sie keine Verbindung zu den anderen Nodes herstellen können:

[KafkaRaftServer nodeId=3] Kafka Server started

Natürlich können wir es so lassen, aber wir können auch die Broker nacheinander stoppen und sie durch Broker im Daemon-Modus ersetzen. So können wir zwar die Logs nicht mehr sehen, aber andererseits müssen wir nicht dauerhaft drei Terminal-Fenster offen haben:

Stoppen wir Broker 1 mit CTRL+C und führen den folgenden Befehl aus, um Broker 1 im Hintergrund zu starten:

~/kafka/bin/kafka-server-start.sh -daemon ~/kafka/config/kafka1.properties

Stoppen wir Broker 2 mit CTRL+C und führen den folgenden Befehl aus, um Broker 2 im Hintergrund zu starten:

~/kafka/bin/kafka-server-start.sh -daemon ~/kafka/config/kafka2.properties

Stoppen wir Broker 3 mit CTRL+C und führen den folgenden Befehl aus, um Broker 3 im Hintergrund zu starten:

~/kafka/bin/kafka-server-start.sh -daemon ~/kafka/config/kafka3.properties

Um zu überprüfen, ob alles noch läuft, können wir den folgenden Befehl verwenden:

~/kafka/bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092

Einerseits gibt er die API-Versionen aus, die jeder Broker unterstützt, aber wichtiger ist, dass er uns einfach zeigt, welche Broker online sind:

localhost:9092 (id: 1 rack: null) -> (
# Viel Text
)
localhost:9093 (id: 2 rack: null) -> (
# Viel Text
)
localhost:9094 (id: 3 rack: null) -> (
# Viel Text
)

Kafka stoppen

Um alle Kafka-Broker zu stoppen, können wir einfach den folgenden Befehl ausführen:

~/kafka/bin/kafka-server-stop.sh

Aber dieser Befehl stoppt alle Kafka-Broker. Um einen einzelnen Broker zu stoppen, können wir ein neues Skript erstellen.

~/kafka/bin/kafka-broker-stop.sh
#!/bin/bash
BROKER_ID="$1"
if [ -z "$BROKER_ID" ]; then
    echo "usage ./kafka-broker-stop.sh [BROKER-ID]"
    exit 1
fi
PIDS=$(ps ax | grep -i 'kafka\.Kafka' | grep java | grep "kafka${BROKER_ID}.properties" | grep -v grep | awk '{print $1}')
if [ -z "$PIDS" ]; then
    echo "No kafka server to stop"
    exit 1
else
    kill -s TERM $PIDS
fi

Wir führen den folgenden Befehl aus, um das Skript ausführbar zu machen:

chmod +x ~/kafka/bin/kafka-broker-stop.sh

Anstatt alle Broker zu stoppen, stoppt es nur denjenigen, dessen Broker-ID übereinstimmt. Um Broker 1 zu stoppen, können wir zum Beispiel den folgenden Befehl verwenden:

~/kafka/bin/kafka-broker-stop.sh 1

Wir können mit dem kafka-broker-api-versions.sh-Skript überprüfen, ob das funktioniert hat:

~/kafka/bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092
Connection to node -1 (localhost/127.0.0.1:9092) could not be established. Node may not be available. (org.apache.kafka.clients.NetworkClient)
WARN [LegacyAdminClient clientId=admin-1] Bootstrap broker localhost:9092 (id: -1 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)
WARN [LegacyAdminClient clientId=admin-1]
Connection to node -3 (localhost/127.0.0.1:9094) could not be established. Node may not be available. (org.apache.kafka.clients.NetworkClient)
WARN [LegacyAdminClient clientId=admin-1] Bootstrap broker localhost:9094 (id: -3 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)
WARN [LegacyAdminClient clientId=admin-1]
Connection to node -2 (localhost/127.0.0.1:9093) could not be established. Node may not be available. (org.apache.kafka.clients.NetworkClient)
WARN [LegacyAdminClient clientId=admin-1] Bootstrap broker localhost:9093 (id: -2 rack: null) disconnected (org.apache.kafka.clients.NetworkClient)

Kafka ist jetzt gestoppt.

Wir wünschen euch frohes Streaming und viel Spaß beim Erkunden von Kafka.

Arockia Nirmal Amala Doss ist ein erfahrener Data Engineer mit über 10 Jahren Expertise in Datenarchitekturen. Als zertifizierter Apache Kafka Entwickler und AWS Data Engineer spezialisiert er sich auf skalierbare Event-Streaming-Pipelines und Cloud-native Datenlösungen. Seine Kunden aus dem DAX-Umfeld schätzen seine praktische Erfahrung mit Amazon MSK, ETL/ELT-Prozessen und der Entwicklung robuster Dateninfrastrukturen.

logo

Wir glauben an eine Welt, in der Unternehmen durch Echtzeitdaten intelligenter entscheiden, nachhaltiger handeln und ihre digitale Zukunft aktiv gestalten.

Copyright 2025, All Right Reserved

Kontakt

Adresse

Commit to Flow GmbH
Wiener Platz 11
01069 Dresden

E-Mail Adresse

kontakt@dataflow.academy

Links