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

Installieren Sie Kafka 4.2 und streamen Sie Events in Minuten.

Inhaltsverzeichnis

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

Dieser Leitfaden ist ein praxisorientierter, kommandozeilenbasierter Quickstart: Installation von Kafka, Start eines lokalen Brokers, Erlernen der wesentlichen Kafka-CLI-Tools und Abschluss mit zwei End-to-End-Beispielen, die Sie direkt in Ihr Terminal kopieren können.

distributed message processing infographic apache kafka

Was Apache Kafka ist und wofür es verwendet wird

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

Kafka vereint drei Kernfunktionen in einer Plattform: Publizieren und Abonnement von Ereignisströmen, Speichern von Strömen so lange wie benötigt und Verarbeiten von Strömen, während sie auftreten oder im Nachhinein. Diese Kombination ist der Grund, warum Kafka für Echtzeit-Datenpipelines, Integration, Messaging und Streaming-Analysen verwendet wird.

Für den Kontext, wo Kafka in einer breiteren Dateninfrastruktur passt, siehe den Pfeiler Dateninfrastruktur für KI-Systeme: Objekt-Speicher, Datenbanken, Suche & KI-Datenarchitektur, der S3-kompatiblen Objektspeicher, PostgreSQL-Architektur, Elasticsearch-Optimierung und KI-native Datenschichten abdeckt.

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

Operativ ist Kafka ein verteiltes System aus Servern und Clients, die über ein leistungsfähiges 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 häufig sehen werden:

  • Topics organisieren Ereignisse. Ein Topic ist multi-producer und multi-subscriber, und Ereignisse können mehrfach gelesen werden, da die Aufbewahrungsrichtlinien steuern, 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 häufig Replikationsfaktoren von 2 oder 3 im Produktivbetrieb (ein Single-Node-Dev-Quickstart verwendet typischerweise 1).

Apache Kafka installieren

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

Voraussetzungen, die Sie nicht überspringen sollten

Kafka 4.x erfordert modernes Java: Für den Server und die 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 speziell zum Lernen installieren, sollten Sie auf eine unterstützte JDK wie Java 17 oder 21 abzielen. Die Java-Unterstützungsseite von Kafka listet Java 17, 21 und 25 als vollständig unterstützt auf, während Java 11 nur für einen Teilbereich der Module (Clients und Streams) unterstützt wird.

Installation aus der offiziellen Binärrelease

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 veröffentlichten Verfahren und KEYS von Apache überprüfen können.

Installation mit Docker

Kafka bietet auch offizielle Docker-Images auf Docker Hub an. Der Quickstart zeigt, wie Sie Kafka 4.2.0 wie folgt pullen 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-Image). Die Kafka-Dokumentation und der Kafka Improvement Proposal für diese Image-Linie beschreiben sie als experimentell und für die lokale Entwicklung und Tests gedacht, nicht für den Produktivbetrieb.

Plattformhinweis für Windows-Nutzer

Kafka-Verteilungen enthalten Windows-Skripte (Batch-Dateien). Die Kafka-Dokumente weisen historisch darauf hin, dass Sie unter Windows bin\windows\ und .bat-Skripte statt der Unix bin/ .sh-Skripte verwenden.

Kafka lokal mit KRaft starten

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

Starten eines einzelnen lokalen Brokers aus dem extrahierten Tarball

Der Kafka 4.2 Quickstart verwendet drei Befehle:

  1. Generieren einer Cluster-UUID
  2. Formatieren der Log-Verzeichnisse
  3. Starten des Servers
# 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. Eine der genannten Rationales ist, dass automatisches Formatieren Fehler verbergen kann, insbesondere rund um das Metadaten-Log, daher wird explizites Formatieren empfohlen.

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 aber nicht für kritische Deployments-Umgebungen (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 von 3 oder 5 Knoten bereitgestellt (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/ geliefert. 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.

Außerdem 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-Einstiegspunkt:

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

KRaft führt Broker- und Controller-Endpunkte für einige Tools 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:

  • Topics erstellen, beschreiben, auflisten (Quickstart zeigt --create, --describe, --topic).
  • Skalierung und Dauerhaftigkeit über Partitionen und Replikationsfaktor angeben. Der Operations-Leitfaden zeigt --partitions und --replication-factor und erklärt, wie sie Skalierbarkeit und Fehlertoleranz beeinflussen.
  • Topic-spezifische Überschreibungen zum Erstellungszeitpunkt mit --config key=value hinzufügen (Topic-Konfigurations-Dokumente 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-Hinweisen:

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

Wenn Sie interne Runbooks pflegen, lohnt es sich, diese Hinweise jetzt zu aktualisieren, bevor Kafka 5.0 die deprecated Flags entfernt.

Ein Konfigurationshinweis für lokale Docker- und Remote-Clients

Wenn Sie Kafka in Containern oder hinter Load-Balancern ausführen, werden Sie schließlich die Notwendigkeit haben, Listener korrekt einzustellen. Die Broker-Konfigurations-Dokumente von Kafka erklären advertised.listeners als die Adressen, die Broker an Clients und andere Broker anzeigen, 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-Konfiguration validieren können, bevor Sie Anwendungscode schreiben.

Beispiel: Ein Topic ausführen und Nachrichten End-to-End streamen

Dies ist der kanonische “Erstellen, Produzieren, Konsumieren”-Workflow 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 Partitionen 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 Anfang an:

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

Sie sollten die gleichen Zeilen gedruckt sehen.

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

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

Kafka Connect beantwortet die wiederkehrende Frage “Wie bewege ich Daten in und aus Kafka, ohne für alles benutzerdefinierte Producer und Consumer zu schreiben”. Der Kafka Connect-Überblick beschreibt es als ein Tool für skalierbaren, zuverlässigen Streaming zwischen Kafka und anderen Systemen, über Connectoren.

Der Kafka 4.2 Quickstart enthält eine minimale, lokale Connect-Demo, die die File-Source- und File-Sink-Connectoren verwendet.

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 einer Source- und 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 an das Topic connect-test.
  • Der Sink-Connector liest von 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 hervorragender Muskelgedächtnis-Bildner, da es Ihnen auch beibringt, wo die Connect-Konfiguration sitzt (Worker-Konfiguration plus Connector-Konfigurationen) und eine minimale “Aufnahme, Speichern, Exportieren”-Schleife zeigt.

Fehlerbehebung und nächste Schritte

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

Broker startet nicht

Beginnen Sie mit den offiziellen Anforderungen:

  • Der Kafka 4.2 Quickstart erfordert explizit Java 17+. Wenn Sie auf einer älteren JDK sind, beheben Sie das 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 eine saubere Platte wollen, zeigt der Kafka-Quickstart, wie Sie die lokalen Datenverzeichnisse löschen, die in der Demo verwendet wurden:

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

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

In Kafka 4.x validieren Sie, 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.

Docker-Netzwerküberraschungen

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 die korrekte Listener-Anzeige. Die Broker-Konfigurations-Dokumente erklären, dass advertised.listeners verwendet wird, wenn die Adressen, auf die Clients verbinden sollen, sich von den Bind-Adressen (listeners) unterscheiden.

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 (Event-Streaming End-to-End)
  • wie Kafka lokal installiert wird (Tarball oder Docker)
  • warum ZooKeeper weg ist und KRaft der Standard in 4.x 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 tiefere mentale Modelle von Topics, Partitionen und Replikation.
  • Erkunden Sie den Kafka Streams Quick Start, wenn Sie eine erste Verarbeitungsanwendung wünschen (der Streams Quickstart demonstriert die Ausführung des WordCount-Demos und die Inspektion der Ergebnisse mit dem Konsolen-Consumer).