Ar dviejų vietų Kubernetes klasteriui reikia trijų etcd rinkėjų?
Trys valdymo plokštumos mazgai dviejose VPN vietose vis dar praranda kvorumą, kai didesnė vieta išsijungia. Suskaičiuokite tikruosius etcd rinkėjus ir pasirinkite praradimą, kurį išgyvensite.
Trys valdymo plokštumos VM atrodo kaip trys šansai išgyventi blogą naktį. Tačiau taip nėra, ir būtent atstumas tarp šių dviejų įsitikinimų paverčia tvarkingą trijų mazgų projektą klasteriu, kuris nustoja priimti įrašus, kai vienas pastatas praranda maitinimą. VPN ryšys tarp vietų daro mašinas pasiekiamas viena kitai ir slepia problemą, o ne ją išsprendžia. Balsai skaičiuojami pagal etcd narį, ir du iš tų narių vis dar gali sėdėti už vieno jungiklio, vieno UPS ir vienos linijos.
Trys valdymo plokštumos mazgai, viena gedimų sritis
Paleidžiate kubectl get nodes, matote tris valdymo plokštumos įrašus ir įrašote klasterį kaip labai prieinamą. Šis skaičius apibūdina planuojamą talpą, o ne išgyvenimą. kubeadm be išorinio etcd kiekvienas valdymo plokštumos mazgas taip pat talpina narį, todėl trys mazgai tikrai duoda tris rinkėjus. Ar tie rinkėjai sugenda nepriklausomai, yra atskiras klausimas, į kurį mazgų sąrašas negali atsakyti.
Dvi VM viename hipervizoriuje, du stelažai viename maitinimo šaltinyje, dvi linijos iš vieno ISP: kiekviena pora yra viena sritis su dviem prieglobos vardais. Užrašykite išdėstymą ir pažymėkite, ką bendrina kiekvienas rinkėjas — hipervizorius, PDU, stelažo viršaus jungiklis, saugyklos masyvas, NAT įrenginys, VPN koncentratorius. Tada popieriuje pašalinkite kiekvieną bendrą objektą ir iš naujo suskaičiuokite likusius balsus. Klasteris, kuris dėl vieno sugedusio prieglobos praranda du rinkėjus, visą laiką buvo vieno rinkėjo klasteris; niekas jo dar to nebuvo paklausęs.
Ką dviejų vietų padalijimas gali atlaikyti, o ko ne
Kai trys rinkėjai išdėstomi dviejose vietose po du ir vieną, didesnė pusė išlaiko kvorumą, kai kita vieta dingsta, o vieno rinkėjo pusė niekada. Ta asimetrija yra aritmetika, o ne derinimas. Bet kuris daugumos pagrindu veikiantis etcd klasteris, paskirstytas tiksliai dviejose nepriklausomose vietose, nepraeina testo „prarask bet kurią vietą ir toliau fiksuok“, nes abi pusės vienu metu turėtų turėti daugiau nei pusę balsų.
Žemiau esanti lentelė yra greičiausias būdas pamatyti, kokius gedimus iš tikrųjų nusipirkote. Skaitykite kiekvieną eilutę taip: jei šiąnakt išnyks visa ši eilutė, ar išgyvenusieji vis dar galės fiksuoti įrašą?
| 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 |
Kodėl tunelis niekada neprideda balso
VPN yra transportas, o ne narys. Jis gali padaryti nuotolinį rinkėją pasiekiamą ir gali paversti padalijimą kažkuo, kas atrodo kaip lėtas laiko limitas, ir tai yra visas jo indėlis į kvorumą. Ką jis prideda, tai kaina, nes kiekvienas fiksavimas turi kirsti ryšį, o etcd moka už tą kelionę pirmyn ir atgal įrašuose, kurie liečia raft žurnalą. Kelias, kuris plazda, paverčia replikaciją pakartojimais ir rinkimais.
Padalijimai yra vieta, kur žmonės tikisi magijos, todėl būkite tikslūs. Jei ryšys nutrūksta, kai senasis lyderis sėdi vieno rinkėjo pusėje, ta pusė negali fiksuoti ir lyderis pasitraukia, kai baigiasi rinkimų laiko limitas, o dviejų rinkėjų pusė išrenka pakaitalą. etcd vadovas apie gedimų režimus aiškiai aprašo elgseną: tęsiama paslauga daugumos pusėje, jokio antro rašomo klasterio izoliuotoje pusėje.
Nuspręskite, kokį sutrikimą perkate
Du plius vienas yra teisėtas projektas, kai A vieta yra pagrindinė ir sutinkate, kad jos praradimas reiškia valdymo plokštumos įrašų praradimą, kol kas nors imsis veiksmų. Tai daro defektu tai, kad paliekate tą sprendimą numanomą. Įrašykite jį į runbook: iš kurios vietos jūsų valdymo plokštuma išgyvena ir ką operatorius daro, kai kita vieta užgęsta 03:00.
Jei reikalavimas yra „bet kuri vieta gali sugesti“, išdėstymas turi turėti daugumą kiekvienoje vietoje, o trys rinkėjai dviejose vietose to padaryti negali. Jūs arba pridedate tikrai nepriklausomą trečią sritį — mažas regionas pas kitą tiekėją tinka, jei kelias į jį stabilus — arba skaidotės į du klasterius su atskiru etcd ir priimate to skaidymo operacines išlaidas. Jokia liudytojo apėjimo gudrybė to neišvengia: etcd neturi lengvo arbitro nario, todėl trečiasis rinkėjas yra pilnas narys su savo disko, atminties ir tinklo reikalavimais. Nubraižyti schemoje laukelį su užrašu liudytojas liudytojo nesukuria.
Kvorumas nėra tas pats kaip paslauga
etcd kvorumas palaiko API serverį galintį priimti įrašus, ir tai yra viskas, ką jis palaiko. Apkrovos balansuotojo būsenos patikros, ingress, CNI pasiekiamumas per tunelį, tomų prijungimo zonos ir programų replikacija kiekviena reikalauja savo atsakymo. Klasteris gali turėti švarią daugumą ir vis tiek nieko naudingo nepasiūlyti naudotojams.
Tada patvirtinkite narystę, kurią, jūsų manymu, turite, nes schemos dreifuoja:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
Palyginkite narių sąrašą su išdėstymo brėžiniu. Jei du nariai išsprendžiami į tą patį prieglobą ar tą patį stelažą, neteisingas yra brėžinys, o ne klasteris, ir dydžio keitimas aplink klaidingą topologiją nusiperka tik brangesnę to paties sutrikimo versiją.
Prieš patvirtindami bet kurį trijų rinkėjų projektą, atsakykite į keturis klausimus: kiek rinkėjų kartu praranda maitinimą, kurios vietos praradimas dar palieka daugumą, kur sėdi lyderis, kai tunelis krinta, ir ką dar gali padaryti išgyvenusi vieta. „Nežinau“ į bet kurį iš jų reiškia, kad klasteris dar nėra labai prieinamas. Tai trys mašinos, kurioms pasisekė.