Trenger et Kubernetes-klynge på to steder tre etcd-velgere?
Tre kontrollplannoder på tvers av to VPN-steder mister fortsatt quorum når det største stedet går ned. Tell de ekte etcd-velgerne og velg tapet du overlever.
Tre kontrollplan-VM-er føles som tre sjanser til å overleve en dårlig natt. Det er de ikke, og avstanden mellom de to overbevisningene er det som gjør et ryddig tre-node-design om til en klynge som slutter å ta imot skrivinger når én bygning mister strømmen. En VPN-forbindelse mellom stedene gjør maskinene tilgjengelige for hverandre og skjuler problemet i stedet for å løse det. Stemmer telles per etcd-medlem, og to av disse medlemmene kan fortsatt sitte bak én svitsj, én UPS og én uplink.
Tre kontrollplannoder, ett feildomene
Du kjører kubectl get nodes, ser tre kontrollplanoppføringer og registrerer klyngen som høyt tilgjengelig. Tallet beskriver planleggbar kapasitet, ikke overlevelsesevne. I kubeadm uten ekstern etcd er hver kontrollplannode også vert for et medlem, så tre noder gir deg faktisk tre velgere. Om disse velgerne feiler uavhengig, er et eget spørsmål som nodelisten ikke kan svare på.
To VM-er på én hypervisor, to rack på én strømforsyning, to uplinks fra én ISP: hvert par er ett domene med to vertsnavn. Skriv ned plasseringen og merk hva hver velger deler — hypervisor, PDU, svitsj øverst i racket, lagringsarray, NAT-enhet, VPN-konsentrator. Fjern deretter hvert delte objekt på papiret og tell stemmene som er igjen på nytt. En klynge som mister to velgere på grunn av én feilet vert, har hele tiden vært en klynge med én velger; ingen hadde stilt den spørsmålet ennå.
Hva en todelt løsning på to steder kan og ikke kan overleve
Når tre velgere plasseres to og én på tvers av to steder, beholder den største siden quorum når det andre stedet forsvinner, og siden med én velger aldri. Den asymmetrien er aritmetikk, ikke tuning. Enhver majoritetsbasert etcd-klynge fordelt på nøyaktig to uavhengige steder feiler testen "mist hvilket som helst sted og fortsett å committe", fordi begge sider samtidig måtte holde mer enn halvparten av stemmene.
Tabellen nedenfor er den raskeste måten å se hvilke feil du faktisk har kjøpt. Les hver rad slik: hvis hele denne raden forsvinner i natt, kan de overlevende fortsatt committe en skriving?
| 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 aldri legger til en stemme
En VPN er transport, ikke et medlem. Den kan gjøre en ekstern velger tilgjengelig, og den kan gjøre en partisjon om til noe som ligner en langsom timeout, og det er hele dens bidrag til quorum. Det den legger til, er kostnad, fordi hver commit må krysse forbindelsen, og etcd betaler den rundturen på skrivinger som berører raft-loggen. En sti som flimrer, gjør replikering om til nye forsøk og valg.
Partisjoner er stedet der folk forventer magi, så vær presis om dem. Hvis forbindelsen faller mens den gamle lederen sitter på siden med én velger, kan den siden ikke committe, og lederen går av når valg-timeouten utløper, mens siden med to velgere velger en erstatter. etcd-veiledningen om feilmoduser beskriver oppførselen rett frem: fortsatt tjeneste på majoritetssiden, ingen annen skrivbar klynge på den isolerte siden.
Bestem hvilket avbrudd du kjøper
To pluss én er et legitimt design når sted A er det primære, og du godtar at tapet av det betyr tap av kontrollplanskrivinger til noen handler. Det som gjør det til en mangel, er å la den beslutningen være implisitt. Skriv den i runbooken: hvilket sted kontrollplanet ditt overlever, og hva en operatør gjør når det andre stedet går ned klokken 03:00.
Hvis kravet i stedet er "hvilket som helst sted kan feile", må plasseringen holde flertall på hvert sted, og tre velgere over to steder kan ikke gjøre det. Du legger enten til et virkelig uavhengig tredje domene — en liten region hos en annen leverandør fungerer hvis stien dit er stabil — eller deler i to klynger med egen etcd og godtar driftskostnaden ved den delingen. Ingen snarvei med et vitne unngår dette: etcd har ikke et lettvekts arbiter-medlem, så en tredje velger er et fullt medlem med egne krav til disk, minne og nettverk. Å tegne en boks merket vitne på diagrammet skaper ikke et vitne.
Quorum er ikke det samme som tjeneste
etcd-quorum holder API-serveren i stand til å ta imot skrivinger, og det er alt det holder. Helsesjekker for lastbalansereren, ingress, CNI-tilgjengelighet gjennom tunnelen, volumtilknytningssoner og applikasjonsreplikering trenger hver sin egen svar. En klynge kan ha et rent flertall og likevel ikke tilby noe nyttig til brukerne.
Bekreft deretter medlemskapet 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 plasseringsskissen. Hvis to medlemmer løses til samme vert eller samme rack, er tegningen feil og ikke klyngen, og å endre størrelse rundt en feil topologi kjøper bare en dyrere versjon av det samme avbruddet.
Før du godkjenner et design med tre velgere, svar på fire spørsmål: hvor mange velgere mister strømmen sammen, hvilket stedstap etterlater fortsatt et flertall, hvor sitter lederen når tunnelen faller, og hva kan det overlevende stedet fortsatt gjøre. Et "ikke sikker" på noen av dem betyr at klyngen ennå ikke er høyt tilgjengelig. Det er tre maskiner som har vært heldige.