v2.0 ist das letzte Paket des Curriculums. Es fügt vier Module hinzu - schema-registry, authorization, share-groups und capstones - sowie drei Szenarien zu Diskless Topics im Modul storage, eine Active-Active-DR-Übung im Modul dr und rack-bewusste Partitionierung im Modul producer, insgesamt 24 neue Szenarien. Es schaltet die Stufen governance und diskless im Free Play frei und vervollständigt das Curriculum des Kafka Simulators mit 136 von 136.

Es ist außerdem das Release, in dem der Playground rund um diese Szenarien neu gebaut wurde. Seit v1.9 hat sich fast jeder Teil davon verändert: Der Canvas hat drei Ansichten, die Zeitleiste ist etwas geworden, das man lesen kann, die Inspectors beantworten Fragen, statt Felder aufzulisten, und das Terminal verdeckt den Canvas nicht mehr.

Was in v2.0 steckt

Schema Registry (schema-registry, 3 Szenarien). Subjects und Versionen, was Backward-, Forward- und Full-Kompatibilität prüfen und eine inkompatible Änderung, die abgelehnt wird, bevor sie registriert ist.

Autorisierung (authorization, 2 Szenarien). Zugriffskontrolle auf dem Datenpfad - wie eine ACL oder ein RBAC-Role-Binding einen Produce erlaubt oder verweigert, wenn der Authorizer standardmäßig ablehnt.

Beide kommen mit der neuen Governance-Stufe in den Free Play: Schema Registry, Steuerelemente für ACLs und RBAC sowie kafka-acls im Terminal, sodass Sie alles, was die Szenarien zeigen, von Hand nachbauen und kaputt machen können.

Share Groups (share-groups, 9 Szenarien). Die Queue-Semantik von Kafka, eingeführt mit KIP-932:

Share Groups verändern, wie Kafka konsumiert wird, und wer sie neben klassischen Consumer Groups sieht, erkennt, was anders ist.

Capstones (capstones, 5 Szenarien). End-to-End-Szenarien, die Haltbarkeit, Transaktionen, Storage, Multi-DC und Governance kombinieren, mit mehr als einer Sache, die gleichzeitig passiert: eine Exactly-once-Zahlungspipeline, die den Verlust einer Region übersteht, ein regionales Failover ohne Datenverlust, eine Migration ohne Downtime mit Cluster Linking, ein Active/Active-Backbone über mehrere DCs und eine Pipeline, die gleichzeitig auf Durchsatz und Latenz getunt ist.

Disaster Recovery (dr, 1 weiteres Szenario). Eine Active-Active-DR-Übung: Die Region west fällt aus, ihr Producer und ihre Consumer Group ziehen nach east um und schreiben weiter, dann startet west neu und beide ziehen zurück. Nichts wird promotet, und die Records, die west nie gespiegelt hat, sind der Preis.

Producer (producer, 1 weiteres Szenario). Rack-bewusste Partitionierung, neu in Kafka 4.4: Ein Producer hält seine Records ohne Schlüssel in seiner eigenen Availability Zone, bis diese Zone ihre Leader verliert. Mehr dazu unten unter Apache Kafka 4.4.

Diskless Topics (Richtung KIP-1150, Entwurf KIP-1163/1164)

Ein Diskless Topic hält seine Partitionsdaten in Object Storage statt auf den Platten der Broker. Ein Broker puffert Records aus vielen Partitionen und lädt sie als ein einziges WAL-Objekt hoch; ein Diskless-Coordinator vergibt die Offsets, wenn er dieses Objekt committet, und der Produce wird beim Commit bestätigt. Replikate bauen ihr Log auf, indem sie das Objekt aus dem Storage zurücklesen, statt vom Leader zu fetchen, und Producer und Consumer nutzen ein Replikat in ihrer eigenen Availability Zone.

Der Stand: KIP-1150 ist als Richtung angenommen, während KIP-1163 und KIP-1164, die festlegen, wie es funktioniert, noch Under Discussion sind (KAFKA-19161 verfolgt die Implementierung). Wir modellieren den aktuellen Entwurf und kennzeichnen ihn im gesamten Simulator als „KIP draft”. Namen und Verhalten können sich ändern, bevor irgendetwas davon in Kafka ausgeliefert wird.

Drei Szenarien (storage, 05.4.1-05.4.3):

  • Diskless: der Schreibpfad - zwei Producer und zwei Partitionen teilen sich ein WAL-Objekt, es gibt keinen Offset, bis der Coordinator es committet, und die Replikate lesen die Daten aus Object Storage zurück.
  • Keine Replikation über AZs hinweg - dieselben 3 Records gehen an ein klassisches und an ein Diskless Topic über drei AZs; die Karte Cross-AZ traffic endet bei 7 Hops für klassisch und 0 für diskless.
  • Der Preis ist Latenz - derselbe Produce mit acks=all wird auf einem klassischen Topic nach 300 ms bestätigt und auf einem Diskless Topic nach 1300 ms, während ein Burst, der den Puffer füllt, nach 800 ms bestätigt wird. Die Zeiten sind hochskaliert, damit jeder Schritt sichtbar ist.

Im Free Play: ein Preset Diskless 3 AZ, ein Diskless-Schalter pro Topic und Schieberegler für das Diskless-Timing. Der Canvas bekommt eine Object-Storage-Spur mit eigener Zeitachse, WAL-Ablagen unter jedem Broker und ein Coordinator-Badge, das Metrik-Panel eine Karte Cross-AZ traffic. Im Terminal legt kafka-topics --create --config diskless.enable=true ein Diskless Topic an, und kafka-diskless-metadata (selbst ein Tool aus dem Entwurf, noch nicht in Apache Kafka) zeigt die Offsets pro Partition und listet die WAL-Objekte im Storage auf.

Der Trade-off in Kürze: weniger Replikationsverkehr über AZs hinweg, langsamere Produces - der Entwurf zielt auf eine Produce-Latenz von etwa 500 ms bei P50 und 1-2 s bei P99. Klassisches Kafka kann bereits von einem Follower in derselben AZ lesen (KIP-392); was Diskless hinzufügt, ist also der Wegfall der Replikation von Broker zu Broker und ein Produce, der den Leader nicht erreichen muss.

Apache Kafka 4.4

Das Modell folgt jetzt Apache Kafka 4.4, das diese Woche erschienen ist. Wir haben 4.3.0 mit 4.4.0 verglichen und keinen Standardwert, keine CLI-Ausgabe und keine Fehlermeldung gefunden, auf die sich der Simulator stützt und die sich geändert hätte; in den Szenarien verhält sich also alles wie bisher.

v2.0 modelliert eine Neuerung aus 4.4: rack-bewusste Partitionierung im Producer (KIP-1123). Mit partitioner.rack.aware=true und einem client.rack schickt der Standard-Partitioner Records ohne Schlüssel an Partitionen, deren Leader in der Availability Zone des Producers liegt, und an jede Partition, wenn diese Zone keinen Leader hat; so bleibt der Produce-Verkehr in der Zone. Das neue Szenario Rack-bewusste Partitionierung zeigt beide Fälle. Im Free Play hat der Producer-Inspector den Schalter, und die Producer, mit denen eine Sandbox startet, können ihr client.rack wählen. Ohne client.rack lehnt der Producer die Einstellung ab, wie in Kafka.

Dead-Letter-Queues für Share Groups (KIP-1191), eine weitere Neuerung aus 4.4, sind noch nicht modelliert.

Ein neu gebauter Playground

Drei Ansichten auf einen Cluster

Der Canvas hat jetzt drei Ansichten, umschaltbar über seine Toolbar:

  • Brokers ist das vertraute Bild: Producer links, der Cluster in der Mitte, Consumer und Share Groups rechts.
  • Lanes zeichnet eine Zeile pro Partition auf einer gemeinsamen Offset-Achse: die Replikate untereinander, der Leader zuerst, die High Watermark als eine Linie durch alle hindurch. Ein zurückliegender Follower hat sichtbar ein kürzeres Log, das Log eines gestoppten Brokers steht still, und jeder Consumer sitzt an seiner Leseposition, mit committetem Offset und Lag. Sie sehen auf einen Blick, wo sich jeder im Log befindet.
  • Matrix ist für Cluster, die zu groß zum Zeichnen sind: eine Tabelle mit Topics in den Zeilen und Brokern in den Spalten und vier Linsen - Failures, Balance, Lag und Traffic -, die sie einfärben und das Schlimmste nach oben sortieren. Fahren Sie mit der Maus über einen Broker, sehen Sie, was der Cluster verlieren würde, Topic für Topic, bevor Sie ihn stoppen. Ein großer Free-Play-Cluster öffnet sich von selbst in der Matrix.

Der Canvas zeigt, was sich geändert hat

Zustandsänderungen spielen sich jetzt an dem Element ab, das sich geändert hat, statt als allgemeines Pulsieren: Die Marker der High Watermark gleiten zu ihrem neuen Offset, die Krone des Leaders wandert vom alten zum neuen Leader, und das ISR-Tag eines Followers nimmt die Farbe der Änderung an. Ein produzierter Record landet in seiner eigenen Log-Zelle, ein voller Canvas zeichnet Records als kurze Spuren, und ein gestoppter Broker bleibt verblasst auf dem Canvas, sodass Sie sehen, was vorher dort war. Auf Multi-Region-Canvases zeigt der Mirror-Link seinen RPO, jedes DC-Band sagt, was sein Verlust kosten würde, eine Netzwerkpartition zeigt, welche Seite weiter bedient, der KRaft-Streifen zählt seine Mehrheit, und die Spur einer Share Group zeigt für jeden Record den Lock-Timer und die Anzahl der Zustellungen.

Eine Zeitleiste, die sich lesen lässt

Auf dem Desktop ist das untere Dock jetzt eine einzeilige Schiene: Die Frames stehen an ihrer echten Simulationszeit, sodass ein Burst als Häufung und eine ruhige Phase als Lücke erscheint, und Sie spulen, indem Sie daran entlangziehen. Öffnen Sie ihre Event-Spuren, und jedes Event des Laufs wird auf den Spuren für Produce, Replikation, Broker und Consume ausgelegt, Ausfälle in Rot, mit dem Haupt-Event jedes Frames markiert.

Inspectors, die Fragen beantworten

Das rechte Panel geht jetzt von den Fragen aus, die Sie stellen. Eine Partition liest sich als Lineal ihrer Offsets, ein Broker als das, was Sie verlieren, wenn er stoppt, ein Topic als eine Spur pro Partition, ein Producer als sein Sendepfad und eine Consumer Group als Spuren oder als Partitionsraster. Why listet auf, was kaputtgegangen ist und warum, Metrics sind nach Rolle gruppiert, und manche Inspectors zeigen, was als Nächstes passieren wird, nicht nur den aktuellen Zustand. Die Multi-Region-Ansichten bekommen eine DR-Karte, die das Log jeder Region und den nicht gespiegelten Rest als RPO zeigt.

Der Canvas macht dem Terminal Platz

Das Kafka-CLI-Terminal dockt weiterhin unter dem Canvas an, aber der Canvas macht ihm jetzt Platz, statt dahinter zu verschwinden - so sind kafka-server-stop und der Ausfall von broker-1 gleichzeitig auf dem Bildschirm, und das Terminal hat die volle Breite des Canvas für das, was Sie eingeben, und das, was die Tools ausgeben. Auf einem breiten Bildschirm verschiebt dock side in seiner Titelleiste es stattdessen in eine Spalte neben dem Canvas. Die Ausgabe behält ihre Spalten, und das Host-Menü ist eine ssh-Tabelle aller Broker und Controller. Die Broker-Konfigurationsdateien entsprechen Kafka 4.4, und kafka-reassign-partitions --generate sowie das Leeren eines Brokers vor dem Entfernen funktionieren so wie auf einem echten Cluster.

Der Einstieg, ohne Tour

Die modale Tour mit 13 Schritten ist weg. An ihrer Stelle steht eine Karte Getting started in der Ecke des Canvas: dieselben Themen als Checkliste, die Sie in beliebiger Reihenfolge abarbeiten, jedes mit einem „Show me”. Die Hilfe ist jetzt eine Referenz zum Nachschlagen, ein geskriptetes Szenario lässt sich in eine Sandbox mit Undo abzweigen, Szenarien schlagen eigene „Try it yourself”-Schritte vor und was als Nächstes zu tun ist, und ein geteilter Link spielt jetzt ab, wie er zu dem Zustand gekommen ist, den er zeigt.

Ein neuer Look und ein Durchgang bei der Barrierefreiheit

Die gesamte Website, einschließlich Playground, hat einen neuen Look, inspiriert von der Dohle in unserem Namen: dunkle Tinte, ein blauer Schimmer und Grau, wobei jedes Textfarbenpaar WCAG AA erfüllt. Dazu kamen Skip-Links und benannte Regionen, eine Szenario-Leiste mit nur einem Tab-Stopp, AA-Kontrast für inaktive Regionen, Feedback beim Drücken und größere Touch-Ziele sowie Bewegung, die prefers-reduced-motion respektiert, indem Überblendungen bleiben und Bewegung wegfällt. Das Telefon-Layout bekam einen eigenen Durchgang, bis hin zu einem Test, der prüft, dass jedes Label noch passt.

Außerhalb des Playgrounds

Der Playground selbst ist nicht indexierbar, deshalb haben Suchmaschinen den Text seiner Szenarien nie gesehen. Jetzt hat jedes Szenario eine eigene Seite unter /kafka-simulator/scenarios/: mit Einleitung und Fazit, jedem Schritt samt Link „Open at this step”, einem echten Canvas-Frame, durch den Sie schrittweise gehen können, und den Kafka-Konfigurationen, die es berührt. Mit v2.0 sind das 136 Seiten.

Daneben stehen Troubleshooting-Seiten zu Kafka-Fehlern und -Symptomen - was das Problem bedeutet, die wahrscheinlichen Ursachen, die Lösungen und was man besser lässt, ob der Client es erneut versucht -, jeweils verlinkt mit den Szenarien, in denen es auftritt, geöffnet genau in dem Moment, in dem es passiert. Mit diesem Release kommt die Seite zur Autorisierung hinzu. Das Changelog liest sich jetzt als Release Notes auf einer Zeitleiste.

Noch eine Sache

In diesem Release haben wir etwas versteckt. Es zu finden überlassen wir Ihnen.

Das Ende der Roadmap

v2.0 vollendet, was mit v1.0 begonnen hat: elf zweiwöchentliche Pakete, 136 Szenarien, von der Anatomie eines einzelnen Brokers bis zu Queues und Capstones über die gesamte Plattform. Alles läuft im Browser, deterministisch, mit der Semantik von Apache Kafka 4.4, ohne Backend und ohne Telemetrie über Ihre Szenarien.

Das Curriculum ist vollständig, aber der Simulator ist eine Sandbox, kein Kurs, den man abschließt. Öffnen Sie den Simulator, bauen Sie etwas und machen Sie es kaputt.