Apache Kafka Snelstart – Installeer Kafka 4.2 met CLI en lokale voorbeelden

Installeer Kafka 4.2 en stream gebeurtenissen in enkele minuten.

Inhoud

Apache Kafka 4.2.0 is de huidige ondersteunde release, en vormt de beste basis voor een moderne Quickstart, omdat Kafka 4.x volledig vrij is van ZooKeeper en standaard gebouwd is rondom KRaft.

Deze gids is een praktische Quickstart die begint met de commandoregel: het installeren van Kafka, het starten van een lokale broker, het leren van de essentiële Kafka CLI-tools en het afsluiten met twee end-to-end voorbeelden die je direct in je terminal kunt plakken.

distributed message processing infographic apache kafka

Wat Apache Kafka is en waarvoor het wordt gebruikt

Apache Kafka is een event streaming-platform. In praktische termen betekent event streaming het vastleggen van eventdata in realtime vanuit bronnen (databases, sensoren, apps), het duurzaam opslaan van de resulterende streams en het verwerken of routeren ervan in realtime (of later).

Kafka brengt drie kerncapaciteiten samen in één platform: publiceren en abonneren op streams van gebeurtenissen, opslaan van streams duurzaam zolang nodig, en verwerken van streams terwijl ze plaatsvinden of retrospectief. Deze combinatie maakt dat Kafka wordt gebruikt voor realtime datapijplijnen, integratie, messaging en streaming-analyse.

Voor context over waar Kafka past binnen een bredere data-infrastructuur, zie de Data Infrastructure for AI Systems: Object Storage, Databases, Search & AI Data Architecture-pilaar, die S3-compatibele objectopslag, PostgreSQL-architectuur, Elasticsearch-optimalisatie en AI-native datalaag behandelt.

Als je bouwt op AWS en een beheerd alternatief nodig hebt, behandelt Building Event-Driven Microservices with AWS Kinesis het implementeren van event-gedreven microservices met Kinesis Data Streams.

Voor stateful stream processing met Kafka, zie Apache Flink on K8s and Kafka: PyFlink, Go, ops, and managed pricing.

Operationeel is Kafka een gedistribueerd systeem van servers en clients die communiceren via een hoogwaardig TCP-protocol: brokers slaan data op en leveren deze; clients (producenten en consumenten) schrijven en lezen events, vaak op grote schaal en met fouttolerantie.

Enkele concepten die je in de CLI vaak zult tegenkomen:

  • Topics organiseren events. Een topic is multi-producer en multi-subscriber, en events kunnen meerdere keren worden gelezen omdat retentie bepaalt wanneer oude data wordt verworpen.
  • Partities sharden een topic over brokers voor schaalbaarheid; volgorde is gegarandeerd per partitie.
  • Replicatiefactor regelt fouttolerantie. Documentatievoorbeelden adviseren doorgaans replicatiefactoren van 2 of 3 in productie (een single-node dev Quickstart gebruikt typisch 1).

Apache Kafka installeren

De officiële Quickstart van Kafka gebruikt de binaire release (tarball) of het officiële Docker-image. Beide zijn geldig voor lokale ontwikkeling.

Vereisten die je niet mag overslaan

Kafka 4.x vereist modern Java: voor de server en tools is Java 17+ de baseline voor lokaal gebruik, en Kafka 4.0 heeft de ondersteuning voor Java 8 verwijderd.

Als je Kafka speciaal installeert om het te leren, streef dan naar een ondersteunde JDK zoals Java 17 of 21. De Java-ondersteuningspagina van Kafka vermeldt Java 17, 21 en 25 als volledig ondersteund, terwijl Java 11 alleen voor een subset van modules (clients en streams) wordt ondersteund.

Installatie vanaf de officiële binaire release

De officiële Quickstart voor Kafka 4.2.0 begint met het downloaden en extraheren van de binaire distributie:

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

Aantekeningen voor gevorderde lezers:

  • De “2.13” in de bestandsnaam verwijst naar de Scala-buildlijn. Voor Kafka 4.x-binaire is Scala 2.13 de primaire distributielyn, en Kafka 4.0 heeft de ondersteuning voor Scala 2.12 verwijderd.
  • Als je je zorgen maakt over de integriteit van de supply chain, documenteert de downloads-pagina expliciet dat je downloads kunt verifiëren met behulp van de gepubliceerde procedures en KEYS van Apache.

Installatie met Docker

Kafka biedt ook officiële Docker-images op Docker Hub. De Quickstart toont aan dat je Kafka 4.2.0 als volgt kunt ophalen en uitvoeren:

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

Er is ook een “native” imagelijn (gebaseerd op GraalVM native image). Kafka-documentatie en het Kafka Improvement Proposal voor deze imagelijn beschrijven het als experimenteel en bedoeld voor lokale ontwikkeling en testing, niet voor productie.

Platformnotitie voor Windows-gebruikers

Kafka-distributies bevatten Windows-scripts (batchbestanden). Kafka-documentatie merkt historisch op dat je op Windows bin\windows\ en .bat-scripts gebruikt in plaats van de Unix bin/ .sh-scripts.

Start Kafka lokaal met KRaft

Als je vraagt “Heb ik ZooKeeper nodig om Apache Kafka te draaien”, is het moderne antwoord nee. Kafka 4.0 is de eerste grote release die is ontworpen om volledig zonder ZooKeeper te werken, met KRaft-modus als standaard, wat de operationele overhead voor lokaal en productiegebruik vermindert.

Start een single-node lokale broker vanaf de geëxtraheerde tarball

De Kafka 4.2 Quickstart gebruikt drie opdrachten:

  1. Genereer een cluster UUID
  2. Formateer de logbestanden
  3. Start de server
# Genereer een Cluster UUID
KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"

# Formateer Log Directories (standalone lokale format)
bin/kafka-storage.sh format --standalone -t "$KAFKA_CLUSTER_ID" -c config/server.properties

# Start de Kafka broker
bin/kafka-server-start.sh config/server.properties

Waarom de “format”-stap belangrijk is in KRaft: De documentatie voor KRaft-bewerkingen van Kafka legt uit dat kafka-storage.sh random-uuid het cluster-ID genereert en dat elke server moet worden geformatteerd met kafka-storage.sh format. Een van de redenen is dat automatisch formatteren fouten kan verbergen, vooral rondom het metadata-log, dus wordt expliciet formatteren aanbevolen.

Wat je in deze Quickstart uitvoert

Voor lokale ontwikkeling kan Kafka draaien in een vereenvoudigde “combinatie”-opstelling (controllers en brokers samen). De KRaft-documentatie van Kafka noemt gecombineerde servers eenvoudiger voor ontwikkeling, maar niet aanbevolen voor kritieke implementatieomgevingen (waar je controllers wilt isoleren en onafhankelijk schalen).

Voor “echte” clusters zijn KRaft-controllers en brokers aparte rollen (process.roles), en controllers worden typisch geïmplementeerd als een quorum van 3 of 5 knooppunten (beschikbaarheid hangt af van een meerderheid die levend is).

Kafka CLI-essentials en belangrijkste commandoregelparameters

Kafka wordt geleverd met veel CLI-tools onder bin/. De officiële operationele documentatie benadrukt twee nuttige eigenschappen:

  • De gebruikelijke tools bevinden zich in de bin/-map van de distributie.
  • Elk tool toont zijn volledige commandoregelgebruik wanneer het wordt uitgevoerd zonder argumenten.

Ook belangrijk voor Kafka 4.x: AdminClient-opdrachten accepteren geen --zookeeper meer. De compatibiliteitsdocumentatie van Kafka merkt op dat je vanaf Kafka 4.0 --bootstrap-server moet gebruiken om met het cluster te communiceren.

Kafka-verbindingsvlaggen die je constant zult gebruiken

De meeste tools hebben een cluster-ingangspunt nodig:

  • --bootstrap-server host:port
    Gebruik dit voor topic-bewerkingen, consumentengroepen en de meeste broker-gerichte opdrachten. Het is de canonieke vervanger voor op ZooKeeper gebaseerde administratieve workflows in Kafka 4.x.

KRaft introduceert broker- versus controller-endpoints voor sommige tools. Bijvoorbeeld, kafka-features.sh en delen van de metadata-tooling kunnen controller-endpoints gebruiken, terwijl veel administratieve bewerkingen broker-endpoints gebruiken. De KRaft-bewerkingspagina toont beide stijlen in voorbeelden.

Topic-beheer met kafka-topics.sh

Je zult kafka-topics.sh gebruiken voor de kernlevenscyclus:

  • Maak topics aan, beschrijf en list ze (Quickstart toont --create, --describe, --topic).
  • Specificeer schaal en duurzaamheid via partities en replicatiefactor. De operationele gids toont --partitions en --replication-factor en legt uit hoe deze schaalbaarheid en fouttolerantie beïnvloeden.
  • Voeg per-topic overrides toe bij het aanmaken met --config key=value (topic-config documenten tonen concrete voorbeelden).

Een goed “productie-gericht” aanmaakcommando ziet er zo uit (deze exacte vorm wordt gebruikt in de officiële operationele documenten):

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

Produceren en consumeren met console-clients

De Quickstart gebruikt de console-producer en -consument omdat ze snel zijn voor validatie en rooktesten:

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

Kafka 4.2 bevat ook verbeteringen voor CLI-consistentie. In de upgrade-notes:

  • kafka-console-producer maakt --max-partition-memory-bytes verouderd en adviseert --batch-size in plaats daarvan.
  • kafka-console-consumer maakt --property (formatter-eigenschappen) verouderd ten gunste van --formatter-property.
  • kafka-console-producer maakt --property (message reader-eigenschappen) verouderd ten gunste van --reader-property.

Als je interne runbooks onderhoudt, zijn deze notities het waard om nu bij te werken, voordat Kafka 5.0 de verouderde vlaggen verwijdert.

Consumentenachterstand inspecteren met kafka-consumer-groups.sh

Voor echte systemen is “Houdt mijn consument bij” een dagelijkse vraag. De operationele gids demonstreert:

  • Lijst groppen: --list
  • Beschrijf een groep met offsets en achterstand: --describe --group ...
  • Beschrijf leden en toewijzingen: --members en --verbose
  • Verwijder groppen: --delete
  • Reset offsets veilig: --reset-offsets

Voorbeeld:

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

Een configuratiewaarschuwing voor lokale Docker en externe clients

Als je Kafka in containers draait of achter load balancers, zul je uiteindelijk de noodzaak ondervinden om luisteraars correct in te stellen. De broker-configuratie-documenten van Kafka leggen advertised.listeners uit als de adressen die brokers aan clients en andere brokers adverteren, vooral wanneer het bind-adres niet het adres is dat clients moeten gebruiken.

Quickstart-voorbeelden die je nu kunt uitvoeren

De onderstaande voorbeelden zijn opzettelijk gebaseerd op de CLI, zodat je een lokale Kafka-opstelling kunt valideren voordat je applicatiecode schrijft.

Voorbeeld: voer een topic uit en stream berichten end-to-end

Dit is de canonieke “aanmaken, produceren, consumeren”-flow uit de Kafka 4.2 Quickstart.

Open terminal A en maak een topic aan:

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

Beschrijf het nu (optioneel maar nuttig als je partities en replicatiefactor leert):

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

Open terminal B en start een producer:

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

Typ een paar regels (elke regel wordt een event), en laat de producer draaien:

This is my first event
This is my second event

Open terminal C en start een consument vanaf het begin:

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

Je zou dezelfde regels moeten zien worden afgedrukt.

Waarom dit meer valideert dan “het werkt”: De Kafka Quickstart legt uit dat brokers events duurzaam opslaan en dat events meerdere keren en door meerdere consumenten kunnen worden gelezen. Die duurzaamheid is waarom dit Quickstart-patroon het eerste ding is dat je moet doen na elke installatie of upgrade.

Voorbeeld: voer een eenvoudige Kafka Connect-pijplijn uit van bestand naar topic naar bestand

Kafka Connect beantwoordt de terugkerende vraag “Hoe verplaats ik data naar en uit Kafka zonder voor alles custom producers en consumers te schrijven”. De Kafka Connect-overzicht beschrijft het als een tool voor schaalbare, betrouwbare streaming tussen Kafka en andere systemen, via connectoren.

De Kafka 4.2 Quickstart bevat een minimale, lokale Connect-demo met de file-source en file-sink connectoren.

Vanaf je Kafka-map, stel eerst de worker-pluginpath in om de meegeleverde file-connector jar te bevatten:

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

Maak een klein invoerbestand aan:

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

Start de Connect-worker in standalone-modus met zowel een source- als sink-connector-configuratie:

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

Wat er moet gebeuren (en waarom het nuttig is):

  • De source-connector leest regels van test.txt en produceert ze naar het topic connect-test.
  • De sink-connector leest uit connect-test en schrijft naar test.sink.txt.

Verifieer het sink-bestand:

more test.sink.txt

Je zou moeten zien:

foo
bar

Je kunt het topic ook direct verifiëren:

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

Dit tweede voorbeeld is een uitstekende opbouwer van spiergeheugen omdat het je ook leert waar Connect-configuratie zit (worker-config plus connector-configs) en een minimale “ingest, store, export”-lus toont.

Probleemoplossing en vervolgstappen

De meeste “Kafka Quickstart start niet” problemen vallen in een klein aantal oorzaken.

Broker start niet

Begin met de officiële vereisten:

  • Kafka 4.2 Quickstart vereist expliciet Java 17+. Als je op een oudere JDK zit, los dat eerst op.
  • In KRaft-modus is het formatteren van opslag een vereiste expliciete stap. Als je kafka-storage.sh format overslaat, zul je waarschijnlijk startfouten of metadata-fouten zien.

Als je hebt geëxperimenteerd en nu een schone lei wilt, toont de Kafka Quickstart hoe je de lokale datamappen die in de demo worden gebruikt, verwijdert:

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

CLI-opdrachten mislukken terwijl de broker draait

In Kafka 4.x, valideer dat je --bootstrap-server gebruikt (niet --zookeeper). De compatibiliteitsdocumentatie van Kafka wijst expliciet op het verwijderen van --zookeeper uit AdminClient-opdrachten beginnend met Kafka 4.0.

Docker-netwerk verrassingen

Als Kafka in Docker zit en je client-tool buiten Docker (of op een andere machine), heb je mogelijk correcte listener-advertentie nodig. De broker-config documenten leggen uit dat advertised.listeners wordt gebruikt wanneer de adressen waarnaar clients moeten verbinden verschillen van de bind-adressen (listeners).

Waar na de Quickstart vandaan

Als je de voorbeelden in dit bericht hebt voltooid, heb je al de meest voorkomende eerste zoekopdrachten beantwoord:

  • waar Kafka voor wordt gebruikt (event streaming end-to-end)
  • hoe je Kafka lokaal installeert (tarball of Docker)
  • waarom ZooKeeper weg is en KRaft de standaard is in 4.x
  • welke CLI-tools dagelijkse belangrijk zijn (topics, producer, consumer, groppen)

Vandaaruit zijn de meest waardevolle vervolgstappen meestal:

  • Lees de “Inleiding” van Kafka voor dieper mentale modellen van topics, partities en replicatie.
  • Verken de Kafka Streams Quick Start als je een eerste verwerkingsapplicatie wilt (de Streams Quickstart demonstreert het uitvoeren van de WordCount-demo en het inspecteren van resultaten met de console-consument).