KRaft: adding a controller role group can bootstrap a second quorum

Offen
  • Stimmt etwas nicht?
#1,060 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@razvan arbeitet bereits daran.

Seit 13.11.2026.

  • #1061 von @razvan — offen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

type/bug
Description

In KRaft mode, exactly one controller formats its storage with --standalone and bootstraps the metadata quorum. All other controllers join it later through the quorum-manager
sidecar. This was introduced in #1010, which is not released yet.

The operator picks the bootstrap controller as the one with the lowest node.id in the current spec. Node IDs come from a hash of the role group name, so a controller role
group added later can get lower node IDs than the existing ones. Its first pod starts with an empty volume, formats with --standalone, and becomes the leader of a second,
single-voter quorum under the same cluster ID.

This is not an edge case: any second controller role group added next to it triggers the bug.

Impact
  • The new controller never joins the real quorum and keeps its own metadata log under the same cluster ID.
  • Nothing in the cluster status shows the problem. The KafkaCluster stays Available, and the new controller's quorum-manager sees itself as leader and does nothing.
  • Brokers that are already connected stay on the original quorum, so clients keep working. If the original controller role group is removed later, the brokers crash-loop.
  • As a side effect, adding such a role group changes the start command of every existing controller, which restarts all of them.
Steps to reproduce
  1. Create a KRaft KafkaCluster with a default controller role group (3 replicas) and a broker role group.
  2. Add a controller role group named extra with 1 replica.
  3. Run kafka-metadata-quorum.sh describe --replication against extra-0. It reports a single-voter quorum led by itself, not the original quorum with 4 voters.
Known limitations (out of scope)
  • If the status is lost, the operator chooses the bootstrap controller again from the current spec.
Vorherrschende Sprache
Rust
Sterne
31
Forks
9
Ø Merge
4 T. 5 Std.
Gemergte PRs (30 T.)
14

Entwicklungsumgebung

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus stackabletech/kafka-operator

Alle Issues in stackabletech/kafka-operator

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.