Are un cluster Kubernetes în două locații nevoie de trei votanți etcd?

Trei VM-uri de plan de control par trei șanse de a supraviețui unei nopți proaste. Nu sunt, iar distanța dintre aceste două convingeri este ce transformă un design îngrijit cu trei noduri într-un cluster care încetează să accepte scrieri când o clădire pierde curentul. O legătură VPN între locații face mașinile accesibile una pentru cealaltă și ascunde problema în loc să o rezolve. Voturile se numără pe membru etcd, iar doi dintre acești membri pot sta în continuare în spatele unui singur comutator, unui singur UPS și unei singure legături.

Trei noduri de plan de control, un singur domeniu de defect

Rulați kubectl get nodes, vedeți trei intrări de plan de control și înregistrați clusterul ca fiind de înaltă disponibilitate. Acel număr descrie capacitatea planificabilă, nu supraviețuirea. În kubeadm fără etcd extern, fiecare nod de plan de control găzduiește și un membru, așa că trei noduri vă dau într-adevăr trei votanți. Dacă acești votanți eșuează independent este o întrebare separată la care lista de noduri nu poate răspunde.

Două VM-uri pe un singur hipervizor, două rack-uri pe o singură alimentare, două legături de la un singur ISP: fiecare pereche este un singur domeniu cu două nume de gazdă. Scrieți plasarea și marcați ce partajează fiecare votant — hipervizor, PDU, comutatorul din vârful rack-ului, matrice de stocare, dispozitiv NAT, concentrator VPN. Apoi eliminați fiecare obiect partajat pe hârtie și renumărați voturile rămase. Un cluster care pierde doi votanți din cauza unei singure gazde defecte a fost un cluster cu un singur votant tot timpul; nimeni nu îi pusese încă întrebarea.

Ce poate și ce nu poate supraviețui o divizare în două locații

Când trei votanți sunt plasați doi și unu în două locații, partea mai mare păstrează cvorumul când cealaltă locație dispare, iar partea cu un singur votant niciodată. Această asimetrie este aritmetică, nu reglaj. Orice cluster etcd bazat pe majoritate răspândit exact pe două locații independente eșuează testul "pierde oricare locație și continuă să confirmi", pentru că ambele părți ar trebui să dețină mai mult de jumătate din voturi în același timp.

Tabelul de mai jos este cel mai rapid mod de a vedea ce defecțiuni ați cumpărat de fapt. Citiți fiecare rând astfel: dacă tot acest rând dispare în noaptea asta, pot supraviețuitorii să confirme încă o scriere?

De ce tunelul nu adaugă niciodată un vot

Un VPN este transport, nu un membru. Poate face accesibil un votant aflat la distanță și poate transforma o partiție în ceva ce arată ca un timeout lent, și aceasta este întreaga sa contribuție la cvorum. Ce adaugă este cost, pentru că fiecare confirmare trebuie să traverseze legătura și etcd plătește acel dus-întors la scrierile care ating jurnalul raft. O cale care oscilează transformă replicarea în reîncercări și alegeri.

Partițiile sunt locul unde oamenii așteaptă magie, așa că fiți precisi. Dacă legătura cade în timp ce liderul vechi stă de partea cu un singur votant, acea parte nu poate confirma și liderul se retrage când expiră timpul de alegeri, în timp ce partea cu doi votanți alege un înlocuitor. Ghidul etcd despre moduri de defectare descrie comportamentul fără ocolișuri: serviciu continuu de partea majorității, niciun al doilea cluster care poate fi scris de partea izolată.

Decideți ce întrerupere cumpărați

Doi plus unu este un design legitim când Locația A este cea primară și acceptați că pierderea ei înseamnă pierderea scrierilor planului de control până când cineva acționează. Ceea ce îl face un defect este să lăsați acea decizie implicită. Scrieți-o în runbook: din ce locație supraviețuiește planul de control și ce face un operator când cealaltă locație se oprește la 03:00.

Dacă cerința este în schimb "orice locație poate eșua", plasarea trebuie să dețină majoritatea în fiecare locație, iar trei votanți în două locații nu pot face asta. Fie adăugați un al treilea domeniu cu adevărat independent — o regiune mică la alt furnizor funcționează dacă drumul spre ea este stabil — fie vă împărțiți în două clustere cu etcd separat și acceptați costul operațional al acelei divizări. Nicio scurtătură cu martor nu evită asta: etcd nu are un membru arbitru ușor, așa că un al treilea votant este un membru complet cu propriile cerințe de disc, memorie și rețea. Desenarea unei casete etichetate martor pe diagramă nu creează una.

Cvorumul nu este același lucru cu serviciul

Cvorumul etcd menține serverul API capabil să accepte scrieri, și asta este tot ce menține. Verificările de sănătate ale balansatorului de încărcare, ingress, accesibilitatea CNI prin tunel, zonele de atașare a volumelor și replicarea aplicațiilor au fiecare nevoie de propriul răspuns. Un cluster poate deține o majoritate curată și totuși să nu ofere nimic util utilizatorilor.

Apoi confirmați apartenența pe care credeți că o aveți, pentru că diagramele derivă:

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

Comparați lista membrilor cu desenul plasării. Dacă doi membri se rezolvă la aceeași gazdă sau același rack, desenul este greșit, nu clusterul, iar redimensionarea în jurul unei topologii greșite cumpără doar o versiune mai scumpă a aceleiași întreruperi.

Înainte de a aproba orice design cu trei votanți, răspundeți la patru întrebări: câți votanți pierd curentul împreună, a cui pierdere de locație mai lasă o majoritate, unde stă liderul când tunelul cade și ce mai poate face locația supraviețuitoare. Un "nu sunt sigur" la oricare dintre ele înseamnă că clusterul încă nu este de înaltă disponibilitate. Sunt trei mașini care au avut noroc.