Braucht ein Kubernetes-Cluster an zwei Standorten drei etcd-Wähler?

Drei Control-Plane-VMs wirken wie drei Chancen, eine schlechte Nacht zu überleben. Sie sind es nicht, und der Abstand zwischen diesen beiden Überzeugungen verwandelt ein sauberes Drei-Knoten-Design in einen Cluster, der keine Schreibvorgänge mehr annimmt, wenn ein Gebäude den Strom verliert. Eine VPN-Verbindung zwischen den Standorten macht die Maschinen füreinander erreichbar und verdeckt das Problem, statt es zu beheben. Stimmen werden pro etcd-Mitglied gezählt, und zwei dieser Mitglieder können weiterhin hinter einem Switch, einer USV und einer Uplink-Leitung sitzen.

Drei Control-Plane-Knoten, eine Fehlerdomäne

Sie führen kubectl get nodes aus, sehen drei Control-Plane-Einträge und führen den Cluster als hochverfügbar. Diese Zahl beschreibt planbare Kapazität, nicht Überlebensfähigkeit. In kubeadm ohne externes etcd hostet jeder Control-Plane-Knoten auch ein Mitglied, sodass drei Knoten tatsächlich drei Wähler ergeben. Ob diese Wähler unabhängig ausfallen, ist eine separate Frage, die die Knotenliste nicht beantworten kann.

Zwei VMs auf einem Hypervisor, zwei Racks an einer Stromversorgung, zwei Uplinks von einem ISP: Jedes Paar ist eine Domäne mit zwei Hostnamen. Schreiben Sie die Platzierung auf und markieren Sie, was jeder Wähler teilt — Hypervisor, PDU, Top-of-Rack-Switch, Storage-Array, NAT-Gerät, VPN-Konzentrator. Entfernen Sie dann jedes geteilte Objekt auf dem Papier und zählen Sie die verbleibenden Stimmen neu. Ein Cluster, der zwei Wähler durch einen einzigen ausgefallenen Host verliert, war die ganze Zeit ein Cluster mit einem Wähler; niemand hatte ihm die Frage gestellt.

Was eine Aufteilung auf zwei Standorte überlebt und was nicht

Wenn drei Wähler mit zwei und eins auf zwei Standorte verteilt sind, behält die größere Seite das Quorum, wenn der andere Standort verschwindet, und die Seite mit einem Wähler nie. Diese Asymmetrie ist Arithmetik, keine Abstimmung. Jeder mehrheitsbasierte etcd-Cluster, der genau auf zwei unabhängige Standorte verteilt ist, scheitert an der Prüfung "verliere einen beliebigen Standort und schreibe weiter", weil beide Seiten gleichzeitig mehr als die Hälfte der Stimmen halten müssten.

Die Tabelle unten ist der schnellste Weg zu sehen, welche Ausfälle Sie tatsächlich gekauft haben. Lesen Sie jede Zeile so: Wenn diese ganze Zeile heute Nacht verschwindet, können die Überlebenden dann noch einen Schreibvorgang festschreiben?

Warum der Tunnel nie eine Stimme hinzufügt

Ein VPN ist Transport, kein Mitglied. Es kann einen entfernten Wähler erreichbar machen und eine Partition in etwas verwandeln, das wie ein langsamer Timeout aussieht, und das ist sein gesamter Beitrag zum Quorum. Was es hinzufügt, sind Kosten, weil jeder Commit die Verbindung überqueren muss und etcd diese Rundreise bei Schreibvorgängen bezahlt, die das raft-Log berühren. Ein Pfad, der flattert, verwandelt Replikation in Wiederholungen und Wahlen.

Partitionen sind der Ort, an dem Menschen Magie erwarten, seien Sie also präzise. Wenn die Verbindung ausfällt, während der alte Leader auf der Seite mit einem Wähler sitzt, kann diese Seite nicht committen, und der Leader tritt zurück, sobald der Wahl-Timeout abläuft, während die Seite mit zwei Wählern einen Ersatz wählt. Der etcd-Leitfaden zu Fehlermodi beschreibt das Verhalten schlicht: fortgesetzter Dienst auf der Mehrheitsseite, kein zweiter beschreibbarer Cluster auf der isolierten Seite.

Entscheiden Sie, welchen Ausfall Sie kaufen

Zwei plus eins ist ein legitimes Design, wenn Standort A der primäre ist und Sie akzeptieren, dass sein Verlust den Verlust von Control-Plane-Schreibvorgängen bedeutet, bis jemand handelt. Was es zu einem Mangel macht, ist, diese Entscheidung implizit zu lassen. Schreiben Sie sie ins Runbook: Welchen Standort Ihre Control Plane überlebt und was ein Operator tut, wenn der andere Standort um 03:00 ausfällt.

Wenn die Anforderung stattdessen lautet "jeder Standort darf ausfallen", muss die Platzierung an jedem Standort eine Mehrheit halten, und drei Wähler über zwei Standorte können das nicht. Entweder fügen Sie eine wirklich unabhängige dritte Domäne hinzu — eine kleine Region bei einem anderen Anbieter funktioniert, wenn der Pfad dorthin stabil ist — oder Sie teilen in zwei Cluster mit getrenntem etcd und akzeptieren die Betriebskosten dieser Teilung. Keine Abkürzung über einen Zeugen vermeidet das: etcd hat kein leichtgewichtiges Arbiter-Mitglied, ein dritter Wähler ist also ein vollwertiges Mitglied mit eigenen Anforderungen an Disk, Speicher und Netzwerk. Ein Kästchen mit der Aufschrift Zeuge ins Diagramm zu zeichnen, erzeugt keinen.

Quorum ist nicht dasselbe wie Dienst

etcd-Quorum hält den API-Server in der Lage, Schreibvorgänge anzunehmen, und mehr hält es nicht. Health-Checks des Load Balancers, Ingress, CNI-Erreichbarkeit durch den Tunnel, Volume-Attach-Zonen und Anwendungsreplikation brauchen jeweils ihre eigene Antwort. Ein Cluster kann eine saubere Mehrheit halten und dennoch nichts Nützliches für Benutzer bereitstellen.

Bestätigen Sie dann die Mitgliedschaft, die Sie zu haben glauben, denn Diagramme driften:

kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table

Vergleichen Sie die Mitgliederliste mit der Platzierungszeichnung. Wenn zwei Mitglieder auf denselben Host oder dasselbe Rack auflösen, ist die Zeichnung falsch und nicht der Cluster, und eine Größenänderung um eine falsche Topologie herum kauft nur eine teurere Version desselben Ausfalls.

Bevor Sie ein Design mit drei Wählern freigeben, beantworten Sie vier Fragen: Wie viele Wähler verlieren gemeinsam den Strom, wessen Standortverlust lässt noch eine Mehrheit übrig, wo sitzt der Leader, wenn der Tunnel ausfällt, und was kann der überlebende Standort noch tun. Ein "nicht sicher" bei einer davon bedeutet, dass der Cluster noch nicht hochverfügbar ist. Es sind drei Maschinen, die Glück hatten.