Ĉu Kubernetes-klastero ĉe du retejoj bezonas tri etcd-voĉdonantojn?

Tri regad-ebenaj VM-oj sentiĝas kiel tri ŝancoj postvivi malbonan nokton. Ili ne estas, kaj la distanco inter tiuj du kredoj estas tio, kio transformas ordeman tri-nodan dezajnon en klasteron, kiu ĉesas akcepti skribojn kiam unu konstruaĵo perdas potencon. VPN-ligilo inter la ejoj igas la maŝinojn atingeblaj unu de la alia kaj kaŝas la problemon anstataŭ ripari ĝin. Voĉoj estas kalkulataj laŭ etcd-ano, kaj du el tiuj anoj ankoraŭ povas sidi malantaŭ unu ŝaltilo, unu UPS kaj unu suprenligo.

Tri regad-ebenaj nodoj, unu panea domajno

Vi rulas kubectl get nodes, vidas tri regad-ebenajn enskribojn kaj registras la klasteron kiel alte disponebla. Tiu nombro priskribas planeblan kapaciton, ne postvivadon. En kubeadm sen ekstera etcd, ĉiu regad-ebena nodo ankaŭ gastigas anon, do tri nodoj vere donas al vi tri voĉdonantojn. Ĉu tiuj voĉdonantoj paneas sendepende estas aparta demando, kiun la nodelisto ne povas respondi.

Du VM-oj sur unu hipervizoro, du rakoj sur unu potencprovizo, du suprenligoj de unu ISP: ĉiu paro estas unu domajno portanta du gastigantajn nomojn. Skribu la lokigon kaj marku, kion ĉiu voĉdonanto dividas — hipervizoro, PDU, supro-de-rako ŝaltilo, stokada tabelo, NAT-aparato, VPN-koncentrilo. Poste forigu ĉiun dividatan objekton surpapere kaj rekalkulu la restantajn voĉojn. Klastero, kiu perdas du voĉdonantojn pro unu paneinta gastiganto, estis unu-voĉdonanta klastero la tutan tempon; neniu estis demandinta ĝin la demandon.

Kion divido je du ejoj povas postvivi kaj kion ne

Kiam tri voĉdonantoj estas lokigitaj du kaj unu trans du ejoj, la pli granda flanko konservas kvorumon kiam la alia ejo malaperas, kaj la unu-voĉdonanta flanko neniam. Tiu nesimetrio estas aritmetiko, ne agordado. Iu ajn plimultbaza etcd-klastero disigita ĝuste trans du sendependajn ejojn malsukcesas la teston "perdu iun ajn ejon kaj daŭre enmetu", ĉar ambaŭ flankoj devus samtempe teni pli ol duonon de la voĉoj.

La suba tabelo estas la plej rapida maniero vidi, kiujn paneojn vi efektive aĉetis. Legu ĉiun vicon jene: se ĉi tiu tuta vico malaperas hodiaŭ nokte, ĉu la postvivantoj ankoraŭ povas enmeti skribon?

Kial la tunelo neniam aldonas voĉon

VPN estas transporto, ne ano. Ĝi povas igi malproksiman voĉdonanton atingebla kaj povas transformi dividon en ion, kio aspektas kiel malrapida tempolimo, kaj tio estas la tuta kontribuo de ĝi al kvorumo. Kion ĝi aldonas, estas kosto, ĉar ĉiu enmeto devas transiri la ligilon kaj etcd pagas tiun rondon ĉe skriboj, kiuj tuŝas la raft-protokolon. Vojo, kiu flagras, transformas replikadon en reajn provojn kaj elektojn.

Dividoj estas la loko, kie homoj atendas magion, do estu precizaj pri ili. Se la ligilo falas dum la malnova estro sidas sur la unu-voĉdonanta flanko, tiu flanko ne povas enmeti kaj la estro demetas sin post kiam la elekta tempolimo finiĝas, dum la du-voĉdonanta flanko elektas anstataŭanton. La etcd-gvidilo pri paneaj reĝimoj priskribas la konduton senceremone: daŭra servo sur la plimulta flanko, neniu dua skribebla klastero sur la izolita flanko.

Decidu, kiun paneon vi aĉetas

Du plus unu estas legitima dezajno kiam ejo A estas la ĉefa kaj vi akceptas, ke perdi ĝin signifas perdi regad-ebenajn skribojn ĝis iu agas. Kio igas ĝin difekto, estas lasi tiun decidon implica. Metu ĝin en la rularon: kiun ejon via regado-ebeno postvivas, kaj kion faras operatoro kiam la alia ejo mallumiĝas je 03:00.

Se la postulo estas anstataŭe "iu ajn ejo povas panei", la lokigo devas teni plimulton en ĉiu ejo, kaj tri voĉdonantoj trans du ejoj ne povas tion fari. Vi aŭ aldonas vere sendependan trian domajnon — malgranda regiono ĉe alia provizanto funkcias se la vojo al ĝi estas stabila — aŭ dividas en du klasterojn kun apartaj etcd kaj akceptas la operacian koston de tiu divido. Neniu atestanta fuŝsolvo evitas tion: etcd ne havas malpezan arbitran anon, do tria voĉdonanto estas plena ano kun propraj postuloj pri disko, memoro kaj reto. Desegni skatolon etikeditan kiel atestanto sur la diagramo ne kreas unu.

Kvorumo ne estas la sama kiel servo

etcd-kvorumo tenas la API-servilon kapabla akcepti skribojn, kaj tio estas ĉio, kion ĝi tenas. Sanaj kontroloj de ŝarĝbalancilo, enirpermeso, CNI-atingebleco trans la tunelo, volumo-alkroĉaj zonoj kaj aplikaĵa replikado ĉiu bezonas sian propran respondon. Klastero povas teni puran plimulton kaj tamen servi nenion utilan al uzantoj.

Poste konfirmu la membrecon, kiun vi kredas havi, ĉar diagramoj drivas:

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

Komparu la anaron kun la lokiga desegnaĵo. Se du anoj solviĝas al la sama gastiganto aŭ la sama rako, la desegnaĵo estas malĝusta, ne la klastero, kaj regrandigi ĉirkaŭ erara topologio nur aĉetas pli multekostan version de la sama paneo.

Antaŭ ol aprobi iun ajn tri-voĉdonantan dezajnon, respondu kvar demandojn: kiom da voĉdonantoj perdas potencon kune, kies eja perdo ankoraŭ lasas plimulton, kie sidas la estro kiam la tunelo falas, kaj kion la postvivanta ejo ankoraŭ povas fari. "Ne certa" pri iu ajn el ili signifas, ke la klastero ankoraŭ ne estas alte disponebla. Ĝi estas tri maŝinoj, kiuj estis bonŝancaj.