Apache Kafka Schnellstart – Installation von Kafka 4.2 mit CLI und lokalen Beispielen

Apache Kafka 4.2.0 ist die aktuell unterstützte Release-Linie und stellt die beste Basis für einen modernen Quickstart dar, da Kafka 4.x standardmäßig vollständig ohne ZooKeeper auskommt und auf KRaft aufbaut.

Dieser Leitfaden ist ein praktischer, auf die Kommandozeile fokussierter Quickstart: Installation von Kafka, Start eines lokalen Brokers, Erlernen der essenziellen Kafka-CLI-Tools und Abschluss mit zwei durchgehenden Beispielen, die Sie direkt in Ihr Terminal kopieren können.

Was Apache Kafka ist und wofür es verwendet wird

Apache Kafka ist eine Event-Streaming-Plattform. In der Praxis bedeutet Event-Streaming, dass Ereignisdaten in Echtzeit aus Quellen (Datenbanken, Sensoren, Apps) erfasst, die resultierenden Streams dauerhaft gespeichert und diese Streams in Echtzeit (oder später) verarbeitet oder weitergeleitet werden.

Kafka vereint drei Kernfunktionen in einer Plattform: Veröffentlichen und Abonnieren von Ereignisströmen, Dauerhafte Speicherung von Strömen für so lange wie benötigt und Verarbeitung von Strömen im Moment ihres Auftretens oder nachträglich. Diese Kombination ist der Grund, warum Kafka für Echtzeit-Datenpipelines, Integration, Messaging und Streaming-Analysen eingesetzt wird.

Für den Kontext, wo Kafka innerhalb einer breiteren Dateninfrastruktur positioniert ist, sehen Sie die Säule Dateninfrastruktur für KI-Systeme: Objekt-Speicher, Datenbanken, Suche & KI-Datenarchitektur, die S3-kompatible Objektspeicher, PostgreSQL-Architektur, Elasticsearch-Optimierung und KI-native Datenschichten abdeckt.

Wenn Sie auf AWS entwickeln und eine verwaltete Alternative benötigen, behandelt Aufbau ereignisgesteuerter Microservices mit AWS Kinesis die Implementierung ereignisgesteuerter Microservices mit Kinesis Data Streams.

Für zustandsbehaftete Stream-Verarbeitung mit Kafka siehe Apache Flink auf K8s und Kafka: PyFlink, Go, Betrieb und verwaltetes Preismodell.

Operativ gesehen ist Kafka ein verteiltes System aus Servern und Clients, die über ein leistungsstarkes TCP-Protokoll kommunizieren: Broker speichern und bereitstellen Daten; Clients (Producer und Consumer) schreiben und lesen Ereignisse, oft in großem Maßstab und mit Fehlertoleranz.

Einige Konzepte, die Sie in der CLI wiederholt sehen werden:

• Topics organisieren Ereignisse. Ein Topic ist multi-producer und multi-subscriber, und Ereignisse können mehrfach gelesen werden, da Retention-Steuerungen bestimmen, wann alte Daten verworfen werden.
• Partitions sharden ein Topic über Broker hinweg für Skalierbarkeit; die Reihenfolge ist pro Partition garantiert.
• Replikationsfaktor steuert die Fehlertoleranz. Dokumentationsbeispiele empfehlen in der Produktion üblicherweise Replikationsfaktoren von 2 oder 3 (ein Single-Node-Dev-Quickstart verwendet typischerweise 1).

Apache Kafka installieren

Der offizielle Quickstart von Kafka nutzt die Binär-Release (Tarball) oder das offizielle Docker-Image. Beide Varianten sind für die lokale Entwicklung gültig.

Voraussetzungen, die Sie nicht überspringen sollten

Kafka 4.x erfordert modernes Java: Für Server und Tools ist Java 17+ die Basis für den lokalen Betrieb, und Kafka 4.0 hat die Unterstützung für Java 8 entfernt.

Wenn Sie Kafka installieren, um es zu lernen, sollten Sie auf eine unterstützte JDK-Version wie Java 17 oder 21 abzielen. Die Java-Unterstützungsseite von Kafka listet Java 17, 21 und 25 als voll unterstützt auf, während Java 11 nur für eine Teilmenge der Module (Clients und Streams) unterstützt wird.

Installation aus dem offiziellen Binär-Release

Der offizielle Quickstart für Kafka 4.2.0 beginnt mit dem Herunterladen und Extrahieren der Binärverteilung:

tar -xzf kafka_2.13-4.2.0.tgz
cd kafka_2.13-4.2.0

Hinweise für erfahrene Leser:

• Die “2.13” im Dateinamen spiegelt die Scala-Build-Linie wider. Für Kafka 4.x Binärdateien ist Scala 2.13 die primäre Verteilungslinie, und Kafka 4.0 hat die Unterstützung für Scala 2.12 entfernt.
• Wenn Ihnen die Integrität der Lieferkette wichtig ist, dokumentiert die Download-Seite explizit, dass Sie Downloads unter Verwendung der von Apache veröffentlichten Verfahren und KEYS überprüfen können.

Installation mit Docker

Kafka stellt auf Docker Hub ebenfalls offizielle Docker-Images bereit. Der Quickstart zeigt, dass Sie Kafka 4.2.0 wie folgt ziehen und ausführen können:

docker pull apache/kafka:4.2.0
docker run -p 9092:9092 apache/kafka:4.2.0

Es gibt auch eine “native” Image-Linie (basierend auf GraalVM-Native-Images). Die Kafka-Dokumentation und der Kafka Improvement Proposal für diese Image-Linie beschreiben sie als experimentell und für lokale Entwicklung und Tests gedacht, nicht für den Produktivbetrieb.

Plattformhinweis für Windows-Benutzer

Kafka-Verteilungen enthalten Windows-Skripte (Batch-Dateien). Die Kafka-Dokumente bemerken historisch, dass auf Windows bin\windows\ und .bat-Skripte anstelle der Unix-bin/ .sh-Skripte verwendet werden.

Starten von Kafka lokal mit KRaft

Wenn Sie fragen: “Brauche ich ZooKeeper, um Apache Kafka auszuführen?”, lautet die moderne Antwort nein. Kafka 4.0 ist die erste große Release-Version, die entwickelt wurde, um vollständig ohne ZooKeeper zu operieren und standardmäßig im KRaft-Modus läuft, was den Betriebsaufwand für lokale und produktive Nutzung reduziert.

Starten eines Single-Node-lokalen Brokers aus dem extrahierten Tarball

Der Kafka 4.2 Quickstart verwendet drei Befehle:

1. Cluster-UUID generieren
2. Log-Verzeichnisse formatieren
3. Server starten

# Cluster-UUID generieren
KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"

# Log-Verzeichnisse formatieren (standalone lokales Format)
bin/kafka-storage.sh format --standalone -t "$KAFKA_CLUSTER_ID" -c config/server.properties

# Kafka-Broker starten
bin/kafka-server-start.sh config/server.properties

Warum der “Format”-Schritt in KRaft wichtig ist: Die KRaft-Operations-Dokumentation von Kafka erklärt, dass kafka-storage.sh random-uuid die Cluster-ID generiert und dass jeder Server mit kafka-storage.sh format formatiert werden muss. Ein genannter Grund ist, dass automatisches Formatieren Fehler verbergen kann, insbesondere rund um das Metadaten-Log, daher wird explizites Formatieren bevorzugt.

Was Sie in diesem Quickstart ausführen

Für die lokale Entwicklung kann Kafka in einer vereinfachten “kombinierten” Konfiguration laufen (Controller und Broker zusammen). Die KRaft-Dokumentation von Kafka hebt kombinierte Server als einfacher für die Entwicklung hervor, empfiehlt sie jedoch nicht für kritische Bereitstellungsumgebungen (wo Controller isoliert und unabhängig skalierbar sein sollen).

Für “echte” Cluster sind KRaft-Controller und Broker separate Rollen (process.roles), und Controller werden typischerweise als Quorum aus 3 oder 5 Knoten bereitgestellt (die Verfügbarkeit hängt davon ab, dass eine Mehrheit am Leben ist).

Kafka-CLI-Essentials und Hauptparameter der Kommandozeile

Kafka wird mit einer Vielzahl von CLI-Tools unter bin/ ausgeliefert. Die offiziellen Operations-Dokumente betonen zwei nützliche Eigenschaften:

• Die gängigen Tools befinden sich im bin/-Verzeichnis der Distribution.
• Jedes Tool gibt seine vollständige Kommandozeilen-Nutzung aus, wenn es ohne Argumente ausgeführt wird.

Ebenfalls wichtig für Kafka 4.x: AdminClient-Befehle akzeptieren --zookeeper nicht mehr. Die Kompatibilitätsdokumentation von Kafka weist darauf hin, dass Sie ab Kafka 4.0 --bootstrap-server verwenden müssen, um mit dem Cluster zu interagieren.

Kafka-Verbindungsfahnen, die Sie ständig verwenden werden

Die meisten Tools benötigen einen Cluster-Zugangspunkt:

• --bootstrap-server host:port
  Verwenden Sie dies für Topic-Operationen, Consumer-Gruppen und die meisten broker-zentrierten Befehle. Es ist der kanonische Ersatz für ZooKeeper-basierte Admin-Workflows in Kafka 4.x.

KRaft führt für einige Tools Broker- vs. Controller-Endpunkte ein. Zum Beispiel können kafka-features.sh und Teile der Metadaten-Tooling Controller-Endpunkte verwenden, während viele Admin-Operationen Broker-Endpunkte verwenden. Die KRaft-Operations-Seite zeigt beide Stile in Beispielen.

Topic-Verwaltung mit kafka-topics.sh

Sie werden kafka-topics.sh für den Kernlebenszyklus verwenden:

• Erstellen, beschreiben, auflisten von Topics (Quickstart zeigt --create, --describe, --topic).
• Skalierung und Beständigkeit über Partitions und Replikationsfaktor angeben. Der Operations-Leitfaden zeigt --partitions und --replication-factor und erklärt, wie sie Skalierbarkeit und Fehlertoleranz beeinflussen.
• Erstellen von pro-Topic-Überschreibungen zum Erstellungszeitpunkt mit --config key=value (Topic-Konfig-Docs zeigen konkrete Beispiele).

Ein guter “produktionsorientierter” Erstellungs-Befehl sieht so aus (diese exakte Form wird in den offiziellen Operations-Dokumenten verwendet):

bin/kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic my_topic_name \
  --partitions 20 --replication-factor 3 \
  --config x=y

Produzieren und Konsumieren mit Konsolen-Clients

Der Quickstart verwendet den Konsolen-Producer und -Consumer, da sie für Validierung und Smoke-Tests schnell sind:

• kafka-console-producer.sh --topic ... --bootstrap-server ...
• kafka-console-consumer.sh --topic ... --from-beginning --bootstrap-server ...

Kafka 4.2 enthält auch Verbesserungen der CLI-Konsistenz. In den Upgrade-Notizen:

• kafka-console-producer macht --max-partition-memory-bytes veraltet und empfiehlt stattdessen --batch-size.
• kafka-console-consumer macht --property (Formatter-Eigenschaften) veraltet zugunsten von --formatter-property.
• kafka-console-producer macht --property (Nachrichtenleser-Eigenschaften) veraltet zugunsten von --reader-property.

Wenn Sie interne Runbooks pflegen, ist es jetzt sinnvoll, diese Notizen zu aktualisieren, bevor Kafka 5.0 die veralteten Flags entfernt.

Prüfen des Consumer-Lags mit kafka-consumer-groups.sh

Für reale Systeme ist “Hält mein Consumer mit?” eine tägliche Frage. Der Operations-Leitfaden demonstriert:

• Gruppen auflisten: --list
• Eine Gruppe mit Offsets und Lag beschreiben: --describe --group ...
• Mitglieder und Zuordnungen beschreiben: --members und --verbose
• Gruppen löschen: --delete
• Offsets sicher zurücksetzen: --reset-offsets

Beispiel:

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

Eine Konfigurationsfalle für lokale Docker- und Remote-Clients

Wenn Sie Kafka in Containern oder hinter Load-Balancern betreiben, werden Sie schließlich die Notwendigkeit haben, Listener korrekt zu setzen. Die Broker-Konfigurationsdokumente von Kafka erklären advertised.listeners als die Adressen, die Broker an Clients und andere Broker bekannt geben, insbesondere wenn die Bind-Adresse nicht die Adresse ist, die Clients verwenden sollten.

Quickstart-Beispiele, die Sie jetzt ausführen können

Die folgenden Beispiele sind bewusst CLI-basiert, damit Sie eine lokale Kafka-Umgebung validieren können, bevor Sie Anwendungscode schreiben.

Beispiel: Ein Topic ausführen und Nachrichten durchgehend streamen

Dies ist der kanonische “Erstellen, Produzieren, Konsumieren”-Ablauf aus dem Kafka 4.2 Quickstart.

Öffnen Sie Terminal A und erstellen Sie ein Topic:

bin/kafka-topics.sh --create --topic quickstart-events --bootstrap-server localhost:9092

Beschreiben Sie es nun (optional, aber nützlich, wenn Sie Partitions und Replikationsfaktor lernen):

bin/kafka-topics.sh --describe --topic quickstart-events --bootstrap-server localhost:9092

Öffnen Sie Terminal B und starten Sie einen Producer:

bin/kafka-console-producer.sh --topic quickstart-events --bootstrap-server localhost:9092

Geben Sie ein paar Zeilen ein (jede Zeile wird zu einem Ereignis), und lassen Sie den Producer laufen:

Dies ist mein erstes Ereignis
Dies ist mein zweites Ereignis

Öffnen Sie Terminal C und starten Sie einen Consumer von Beginn an:

bin/kafka-console-consumer.sh --topic quickstart-events --from-beginning --bootstrap-server localhost:9092

Sie sollten dieselben Zeilen ausgegeben sehen.

Warum dies mehr validiert als nur “es funktioniert”: Der Kafka-Quickstart erklärt, dass Broker Ereignisse dauerhaft speichern und dass Ereignisse mehrfach und von mehreren Consumern gelesen werden können. Diese Beständigkeit ist der Grund, warum dieses Quickstart-Muster das erste ist, das Sie nach jeder Installation oder jedem Upgrade tun sollten.

Beispiel: Eine einfache Kafka-Connect-Pipeline von Datei zu Topic zu Datei ausführen

Kafka Connect beantwortet die wiederkehrende Frage: “Wie verschiebe ich Daten in und aus Kafka, ohne für alles benutzerdefinierte Producer und Consumer zu schreiben”. Die Kafka-Connect-Übersicht beschreibt es als ein Werkzeug für skalierbares und zuverlässiges Streaming zwischen Kafka und anderen Systemen über Connectors.

Der Kafka 4.2 Quickstart enthält eine minimale, lokale Connect-Demo unter Verwendung der File-Source- und File-Sink-Connectors.

Setzen Sie aus Ihrem Kafka-Verzeichnis zuerst den Worker-Plugin-Pfad, um das bereitgestellte File-Connector-Jar einzuschließen:

echo "plugin.path=libs/connect-file-4.2.0.jar" >> config/connect-standalone.properties

Erstellen Sie eine winzige Eingabedatei:

echo -e "foo\nbar" > test.txt

Starten Sie den Connect-Worker im Standalone-Modus mit sowohl einer Source- als auch einer Sink-Connector-Konfiguration:

bin/connect-standalone.sh \
  config/connect-standalone.properties \
  config/connect-file-source.properties \
  config/connect-file-sink.properties

Was passieren sollte (und warum es nützlich ist):

• Der Source-Connector liest Zeilen aus test.txt und produziert sie zum Topic connect-test.
• Der Sink-Connector liest aus connect-test und schreibt in test.sink.txt.

Überprüfen Sie die Sink-Datei:

more test.sink.txt

Sie sollten sehen:

foo
bar

Sie können das Topic auch direkt überprüfen:

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic connect-test --from-beginning

Dieses zweite Beispiel ist ein großartiger Muskelgedächtnis-Aufbauer, da es Ihnen auch beibringt, wo Connect-Konfigurationen sitzen (Worker-Konfiguration plus Connector-Konfigurationen) und eine minimale “Erfassen, Speichern, Exportieren”-Schleife zeigt.

Fehlerbehebung und weitere Schritte

Die meisten “Kafka Quickstart startet nicht”-Probleme fallen in eine kleine Menge von Ursachen.

Broker startet nicht

Beginnen Sie mit den offiziellen Anforderungen:

• Kafka 4.2 Quickstart erfordert explizit Java 17+. Wenn Sie eine ältere JDK haben, beheben Sie dies zuerst.
• Im KRaft-Modus ist das Formatieren des Speichers ein erforderlicher expliziter Schritt. Wenn Sie kafka-storage.sh format überspringen, werden Sie wahrscheinlich Startfehler oder Metadatenfehler sehen.

Wenn Sie experimentiert haben und nun einen sauberen Neuanfang wünschen, zeigt der Kafka-Quickstart, wie Sie die im Demo verwendeten lokalen Datenverzeichnisse löschen:

rm -rf /tmp/kafka-logs /tmp/kraft-combined-logs

CLI-Befehle schlagen fehl, obwohl der Broker läuft

In Kafka 4.x stellen Sie sicher, dass Sie --bootstrap-server (nicht --zookeeper) verwenden. Die Kompatibilitätsdokumentation von Kafka weist explizit auf die Entfernung von --zookeeper aus AdminClient-Befehlen ab Kafka 4.0 hin.

Überraschungen bei der Docker-Netzwerkung

Wenn Kafka in Docker läuft und Ihr Client-Tool außerhalb von Docker (oder auf einer anderen Maschine) ist, benötigen Sie möglicherweise eine korrekte Listener-Anzeige. Die Broker-Konfigurationsdokumente erklären, dass advertised.listeners verwendet wird, wenn die Adressen, zu denen Clients verbinden sollen, von den Bind-Adressen (listeners) abweichen.

Wohin geht es nach dem Quickstart

Wenn Sie die Beispiele in diesem Beitrag abgeschlossen haben, haben Sie bereits die häufigsten ersten Suchanfragen beantwortet:

• wofür Kafka verwendet wird (Ende-zu-Ende-Event-Streaming)
• wie man Kafka lokal installiert (Tarball oder Docker)
• warum ZooKeeper weg ist und KRaft in 4.x der Standard ist
• welche CLI-Tools im Alltag wichtig sind (Topics, Producer, Consumer, Gruppen)

Von hier aus sind die wertvollsten nächsten Schritte normalerweise:

• Lesen Sie die “Einführung” von Kafka für tiefergehende mentale Modelle von Topics, Partitions und Replikation.
• Erkunden Sie den Kafka Streams Quick Start, wenn Sie eine erste Verarbeitungsanwendung wünschen (der Streams Quickstart demonstriert das Ausführen des WordCount-Demos und das Inspektion der Ergebnisse mit dem Konsolen-Consumer).