Heeft een Kubernetes-cluster op twee locaties drie etcd-stemmers nodig?

Drie control-plane-VM's voelen als drie kansen om een slechte nacht te overleven. Ze zijn het niet, en de afstand tussen die twee overtuigingen is wat een netjes drie-node-ontwerp verandert in een cluster dat stopt met schrijven accepteren wanneer één gebouw de stroom verliest. Een VPN-verbinding tussen de locaties maakt de machines onderling bereikbaar en verbergt het probleem in plaats van het op te lossen. Stemmen worden per etcd-lid geteld, en twee van die leden kunnen nog steeds achter één switch, één UPS en één uplink zitten.

Drie control-plane-nodes, één foutdomein

Je draait kubectl get nodes, ziet drie control-plane-vermeldingen en registreert het cluster als hoog beschikbaar. Dat aantal beschrijft planbare capaciteit, niet overleving. In kubeadm zonder externe etcd host elke control-plane-node ook een lid, dus drie nodes geven je echt drie stemmers. Of die stemmers onafhankelijk falen, is een aparte vraag die de nodelijst niet kan beantwoorden.

Twee VM's op één hypervisor, twee racks op één voeding, twee uplinks van één ISP: elk paar is één domein met twee hostnamen. Schrijf de plaatsing op en markeer wat elke stemmer deelt — hypervisor, PDU, switch boven in het rack, storage-array, NAT-apparaat, VPN-concentrator. Verwijder daarna elk gedeeld object op papier en hertel de stemmen die overblijven. Een cluster dat twee stemmers verliest door één mislukte host, is al die tijd een cluster met één stemmer geweest; niemand had het die vraag nog gesteld.

Wat een splitsing over twee locaties wel en niet kan overleven

Als drie stemmers twee en één over twee locaties worden verdeeld, behoudt de grotere kant quorum wanneer de andere locatie verdwijnt, en de kant met één stemmer nooit. Die asymmetrie is rekenwerk, geen afstelling. Elk op meerderheid gebaseerd etcd-cluster dat precies over twee onafhankelijke locaties is verdeeld, faalt voor de test "verlies een van beide locaties en blijf committen", omdat beide kanten tegelijk meer dan de helft van de stemmen zouden moeten houden.

De tabel hieronder is de snelste manier om te zien welke storingen je echt hebt gekocht. Lees elke rij zo: als deze hele rij vannacht verdwijnt, kunnen de overlevenden dan nog een schrijfactie committen?

Waarom de tunnel nooit een stem toevoegt

Een VPN is transport, geen lid. Hij kan een externe stemmer bereikbaar maken en hij kan een partitie veranderen in iets dat op een trage timeout lijkt, en dat is zijn hele bijdrage aan het quorum. Wat hij toevoegt is kosten, omdat elke commit de verbinding moet oversteken en etcd die heen-en-terugreis betaalt bij schrijfacties die het raft-log raken. Een pad dat flappert, verandert replicatie in nieuwe pogingen en verkiezingen.

Partities zijn de plek waar mensen magie verwachten, dus wees er precies over. Als de verbinding wegvalt terwijl de oude leider aan de kant met één stemmer zit, kan die kant niet committen en treedt de leider af zodra de verkiezingstimeout afloopt, terwijl de kant met twee stemmers een vervanger kiest. De etcd-gids over storingsmodi beschrijft het gedrag ronduit: voortgezette dienst aan de meerderheidskant, geen tweede beschrijfbaar cluster aan de geïsoleerde kant.

Bepaal welke onderbreking je koopt

Twee plus één is een legitiem ontwerp wanneer locatie A de primaire is en je accepteert dat het verliezen ervan verlies van control-plane-schrijfacties betekent tot iemand ingrijpt. Wat het tot een gebrek maakt, is die beslissing impliciet laten. Zet hem in de runbook: welke locatie je control plane overleeft, en wat een operator doet wanneer de andere locatie om 03:00 uitvalt.

Als de eis in plaats daarvan "elke locatie mag falen" is, moet de plaatsing op elke locatie een meerderheid houden, en drie stemmers over twee locaties kunnen dat niet. Je voegt ofwel een werkelijk onafhankelijk derde domein toe — een kleine regio bij een andere provider werkt als het pad ernaartoe stabiel is — of je splitst in twee clusters met aparte etcd en accepteert de operationele kosten van die splitsing. Geen enkele sluiproute met een getuige vermijdt dit: etcd heeft geen lichtgewicht arbiter-lid, dus een derde stemmer is een volwaardig lid met eigen eisen aan schijf, geheugen en netwerk. Een vak met het label getuige op het diagram tekenen maakt er geen.

Quorum is niet hetzelfde als dienst

etcd-quorum houdt de API-server in staat schrijfacties te accepteren, en dat is alles wat het houdt. Healthchecks van de loadbalancer, ingress, CNI-bereikbaarheid door de tunnel, volume-attach-zones en applicatiereplicatie hebben elk hun eigen antwoord nodig. Een cluster kan een schone meerderheid houden en toch niets nuttigs aan gebruikers bieden.

Bevestig dan het lidmaatschap dat je denkt te hebben, want diagrammen drijven:

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

Vergelijk de ledenlijst met de plaatsingstekening. Als twee leden naar dezelfde host of hetzelfde rack oplossen, is de tekening fout en niet het cluster, en rond een verkeerde topologie herschalen koopt alleen een duurdere versie van dezelfde onderbreking.

Voordat je een ontwerp met drie stemmers goedkeurt, beantwoord vier vragen: hoeveel stemmers verliezen samen de stroom, welk locatieverlies laat nog een meerderheid over, waar zit de leider wanneer de tunnel wegvalt, en wat kan de overlevende locatie nog doen. Een "niet zeker" op een van deze betekent dat het cluster nog niet hoog beschikbaar is. Het zijn drie machines die geluk hebben gehad.