A ka nevojë një grup Kubernetes në dy vende për tre votues etcd?

Tre VM të rrafshit të kontrollit duken si tre shanse për të mbijetuar një natë të keqe. Nuk janë, dhe distanca midis këtyre dy besimeve është ajo që e kthen një dizajn të rregullt me tre nyje në një grup që ndalon pranimin e shkrimeve kur një ndërtesë humbet energjinë. Një lidhje VPN midis vendeve i bën makinat të arritshme nga njëra-tjetra dhe e fsheh problemin në vend që ta zgjidhë. Votat numërohen për çdo anëtar etcd, dhe dy nga ata anëtarë ende mund të ulen pas një ndërprerësi, një UPS dhe një linje.

Tre nyje të rrafshit të kontrollit, një domen dështimi

Ju ekzekutoni kubectl get nodes, shihni tre hyrje të rrafshit të kontrollit dhe e regjistroni grupin si shumë të disponueshëm. Ai numër përshkruan kapacitetin e planifikueshëm, jo mbijetesën. Në kubeadm pa etcd të jashtëm, çdo nyje e rrafshit të kontrollit pret gjithashtu një anëtar, kështu që tre nyje vërtet ju japin tre votues. Nëse këta votues dështojnë në mënyrë të pavarur është një pyetje më vete të cilën lista e nyjeve nuk mund t'i përgjigjet.

Dy VM në një hipervizor, dy raftet në një furnizim me energji, dy linja nga një ISP: çdo çift është një domen i vetëm me dy emra pritësi. Shkruani vendosjen dhe shënoni çfarë ndan çdo votues — hipervizor, PDU, ndërprerësi i majës së raftit, grupi i ruajtjes, pajisja NAT, koncentratori VPN. Pastaj hiqni në letër çdo objekt të përbashkët dhe rinumëroni votat e mbetura. Një grup që humbet dy votues për shkak të një pritësi të dështuar ka qenë gjatë gjithë kohës një grup me një votues; askush nuk ia kishte bërë ende atë pyetje.

Çfarë mund dhe çfarë nuk mund të mbijetojë një ndarje në dy vende

Kur tre votues vendosen dy dhe një në dy vende, pala më e madhe e mban kuorumin kur vendi tjetër zhduket, dhe pala me një votues kurrë. Kjo asimetri është aritmetikë, jo rregullim. Çdo grup etcd i bazuar në shumicë i shpërndarë saktësisht në dy vende të pavarura dështon në provën "humb njërin vend dhe vazhdo të konfirmosh", sepse të dy palët do të duhej të mbanin njëkohësisht më shumë se gjysmën e votave.

Tabela më poshtë është mënyra më e shpejtë për të parë cilat dështime keni blerë vërtet. Lexoni çdo rresht kështu: nëse sonte zhduket i gjithë ky rresht, a mund të konfirmojnë ende një shkrim të mbijetuarit?

Pse tuneli nuk shton kurrë një votë

Një VPN është transport, jo anëtar. Mund ta bëjë të arritshëm një votues të largët dhe mund ta kthejë një ndarje në diçka që duket si një afat i ngadaltë, dhe ky është i gjithë kontributi i tij në kuorum. Ajo që shton është kostoja, sepse çdo konfirmim duhet të kalojë lidhjen dhe etcd e paguan atë udhëtim vajtje-ardhje në shkrimet që prekin regjistrin raft. Një rrugë që dridhet e kthen replikimin në përpjekje të përsëritura dhe zgjedhje.

Ndarjet janë vendi ku njerëzit presin magji, prandaj jini të saktë për to. Nëse lidhja bie ndërsa udhëheqësi i vjetër është ulur në palën me një votues, ajo palë nuk mund të konfirmojë dhe udhëheqësi tërhiqet kur skadon afati i zgjedhjeve, ndërsa pala me dy votues zgjedh një zëvendësues. Udhëzuesi i etcd për mënyrat e dështimit e përshkruan sjelljen thjesht: shërbim i vazhdueshëm në palën e shumicës, asnjë grup i dytë i shkrueshëm në palën e izoluar.

Vendosni cilën ndërprerje blini

Dy plus një është një dizajn i ligjshëm kur Vendi A është ai primar dhe ju pranoni se humbja e tij do të thotë humbje e shkrimeve të rrafshit të kontrollit derisa dikush të veprojë. Ajo që e kthen në defekt është lënia e asaj vendimi të nënkuptuar. Shkruajeni në runbook: nga cili vend i mbijeton rrafshi juaj i kontrollit, dhe çfarë bën një operator kur vendi tjetër fiket në 03:00.

Nëse kërkesa është në vend të kësaj "çdo vend mund të dështojë", vendosja duhet të mbajë shumicën në çdo vend, dhe tre votues në dy vende nuk mund ta bëjnë këtë. Ju ose shtoni një domen të tretë vërtet të pavarur — një rajon i vogël te një ofrues tjetër funksionon nëse rruga drejt tij është e qëndrueshme — ose ndaheni në dy grupe me etcd të veçantë dhe pranoni koston operacionale të asaj ndarjeje. Asnjë shkurtore me dëshmitar nuk e shmang këtë: etcd nuk ka anëtar arbitri të lehtë, kështu që votuesi i tretë është anëtar i plotë me kërkesat e veta për disk, memorie dhe rrjet. Vizatimi i një kutie me etiketë dëshmitar në diagram nuk krijon një të tillë.

Kuorumi nuk është i njëjtë me shërbimin

Kuorumi i etcd e mban serverin API të aftë të pranojë shkrime, dhe kjo është gjithçka që mban. Kontrollet e shëndetit të balancuesit të ngarkesës, ingress, arritshmëria e CNI përmes tunelit, zonat e lidhjes së vëllimeve dhe replikimi i aplikacioneve secili ka nevojë për përgjigjen e vet. Një grup mund të mbajë një shumicë të pastër dhe ende të mos ofrojë asgjë të dobishme për përdoruesit.

Pastaj konfirmoni anëtarësinë që mendoni se e keni, sepse diagramet lëvizin:

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

Krahasoni listën e anëtarëve me vizatimin e vendosjes. Nëse dy anëtarë zgjidhen në të njëjtin pritës ose të njëjtin raft, vizatimi është i gabuar dhe jo grupi, dhe ndryshimi i madhësisë rreth një topologjie të gabuar blen vetëm një version më të shtrenjtë të së njëjtës ndërprerje.

Përpara se të miratoni çdo dizajn me tre votues, përgjigjuni katër pyetjeve: sa votues humbin energjinë së bashku, humbja e cilit vend lë ende një shumicë, ku ulet udhëheqësi kur tuneli bie, dhe çfarë mund të bëjë ende vendi i mbijetuar. Një "nuk jam i sigurt" për cilëndo prej tyre do të thotë që grupi nuk është ende shumë i disponueshëm. Janë tre makina që kanë pasur fat.