Skal et Kubernetes-klynge på to lokationer have tre etcd-vælgere?
Tre control-plane-noder på tværs af to VPN-lokationer mister stadig quorum, når den største lokation går ned. Tæl de rigtige etcd-vælgere og vælg det tab, du overlever.
Tre control-plane-VM'er føles som tre chancer for at overleve en dårlig nat. Det er de ikke, og afstanden mellem de to overbevisninger er det, der forvandler et pænt tre-node-design til en klynge, der holder op med at acceptere skrivninger, når én bygning mister strømmen. En VPN-forbindelse mellem lokationerne gør maskinerne tilgængelige for hinanden og skjuler problemet i stedet for at løse det. Stemmer tælles for hvert etcd-medlem, og to af disse medlemmer kan stadig sidde bag én switch, én UPS og én uplink.
Tre control-plane-noder, ét fejldomæne
Du kører kubectl get nodes, ser tre control-plane-poster og registrerer klyngen som højt tilgængelig. Det tal beskriver planlægningskapacitet, ikke overlevelsesevne. I kubeadm uden ekstern etcd hoster hver control-plane-node også et medlem, så tre noder giver dig faktisk tre vælgere. Om de vælgere fejler uafhængigt, er et separat spørgsmål, som nodelisten ikke kan besvare.
To VM'er på én hypervisor, to racks på én strømforsyning, to uplinks fra én ISP: hvert par er ét domæne med to værtsnavne. Skriv placeringen ned, og markér, hvad hver vælger deler — hypervisor, PDU, top-of-rack-switch, lagerarray, NAT-enhed, VPN-koncentrator. Fjern derefter hvert delt objekt på papiret, og tæl de stemmer, der er tilbage. En klynge, der mister to vælgere til én fejlet vært, har hele tiden været en klynge med én vælger; ingen havde stillet den spørgsmålet endnu.
Hvad en opdeling på to lokationer kan overleve, og hvad den ikke kan
Når tre vælgere er placeret to og én på tværs af to lokationer, beholder den største side quorum, når den anden lokation forsvinder, og siden med én vælger gør aldrig. Den asymmetri er aritmetik, ikke tuning. Enhver majoritetsbaseret etcd-klynge fordelt på præcis to uafhængige lokationer fejler testen "mist en af lokationerne og bliv ved med at committe", fordi begge sider samtidig skulle holde mere end halvdelen af stemmerne.
Tabellen nedenfor er den hurtigste måde at se, hvilke fejl du faktisk har købt. Læs hver række sådan: hvis hele denne række forsvinder i nat, kan de overlevende så stadig committe en skrivning?
| What disappears | Voters left | Writes still commit |
|---|---|---|
| Site B, holding voter 3 | 2 of 3 | Yes |
| Site A, holding voters 1 and 2 | 1 of 3 | No |
| One hypervisor carrying any two voters | 1 of 3 | No |
| The inter-site VPN only | 2 of 3 on one side | Only on the majority side |
Hvorfor tunnelen aldrig tilføjer en stemme
En VPN er transport, ikke et medlem. Den kan gøre en fjern vælger tilgængelig, og den kan gøre en opdeling til noget, der ligner en langsom timeout, og det er hele dens bidrag til quorum. Det, den tilføjer, er omkostninger, fordi hver commit skal krydse forbindelsen, og etcd betaler den rundtur på skrivninger, der rører raft-loggen. En sti, der flimrer, forvandler replikering til gentagelser og valg.
Opdelinger er stedet, hvor folk forventer magi, så vær præcis om dem. Hvis forbindelsen falder, mens den gamle leder sidder på siden med én vælger, kan den side ikke committe, og lederen træder tilbage, når valg-timeouten udløber, mens siden med to vælgere vælger en afløser. etcd-vejledningen om fejltilstande beskriver adfærden rent: fortsat service på majoritetssiden, ingen anden skrivbar klynge på den isolerede side.
Beslut, hvilket udfald du køber
To plus én er et legitimt design, når lokation A er den primære, og du accepterer, at tabet af den betyder tab af control-plane-skrivninger, indtil nogen handler. Det, der gør det til en mangel, er at lade den beslutning være implicit. Skriv den i runbooken: hvilken lokation din control plane overlever, og hvad en operatør gør, når den anden lokation går ned klokken 03:00.
Hvis kravet i stedet er "enhver lokation må fejle", skal placeringen have et flertal på hver lokation, og tre vælgere over to lokationer kan ikke gøre det. Du tilføjer enten et virkelig uafhængigt tredje domæne — en lille region hos en anden udbyder virker, hvis stien dertil er stabil — eller deler op i to klynger med separat etcd og accepterer driftsomkostningen ved den opdeling. Ingen genvej med en witness undgår dette: etcd har ikke et letvægts-arbitermedlem, så en tredje vælger er et fuldt medlem med sine egne krav til disk, hukommelse og netværk. At tegne en boks med ordet witness på diagrammet skaber ikke en.
Quorum er ikke det samme som service
etcd-quorum holder API-serveren i stand til at acceptere skrivninger, og det er alt, hvad det holder. Load balancer-sundhedstjek, ingress, CNI-rækkevidde gennem tunnelen, volumenmonteringszoner og applikationsreplikering har hver især brug for deres eget svar. En klynge kan have et rent flertal og stadig ikke levere noget nyttigt til brugerne.
Bekræft derefter det medlemskab, du tror, du har, fordi diagrammer driver:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
Sammenlign medlemslisten med placeringsdiagrammet. Hvis to medlemmer opløses til den samme vært eller det samme rack, er det diagrammet, der er forkert, ikke klyngen, og at ændre størrelse omkring en forkert topologi køber kun en dyrere version af det samme udfald.
Før du godkender et design med tre vælgere, svar på fire spørgsmål: hvor mange vælgere mister strømmen sammen, hvis lokationstab stadig efterlader et flertal, hvor lederen sidder, når tunnelen falder, og hvad den overlevende lokation stadig kan gøre. Et "ikke sikker" på noget af det betyder, at klyngen endnu ikke er højt tilgængelig. Det er tre maskiner, der har været heldige.