Kell-e három etcd-szavazónak egy kéthelyszínes Kubernetes-fürtnek?

Három vezérlősík-VM úgy tűnik, mint három esély egy rossz éjszaka túlélésére. Pedig nem azok, és éppen e két hit közötti távolság az, ami egy rendes háromcsomópontos tervet olyan fürtté alakít, amely leállítja az írások elfogadását, amikor egy épület áramot veszít. A helyszínek közötti VPN-kapcsolat elérhetővé teszi a gépeket egymás számára, és inkább elrejti, mint megoldja a problémát. A szavazatokat etcd-tagként számolják, és e tagok közül kettő még mindig ülhet egy kapcsoló, egy UPS és egy vonal mögött.

Három vezérlősík-csomópont, egy hiba tartomány

Futtatja a kubectl get nodes parancsot, három vezérlősík-bejegyzést lát, és a fürtöt magasan elérhetőként rögzíti. Ez a szám a tervezhető kapacitást írja le, nem a túlélést. A külső etcd nélkül tartott kubeadm-ben minden vezérlősík-csomópont vendégül lát egy tagot is, így három csomópont valóban három szavazót ad. Az, hogy ezek a szavazók függetlenül hibáznak-e, külön kérdés, amelyre a csomópontlista nem tud válaszolni.

Két VM egy hipervizoron, két rack egy áramellátáson, két vonal egy ISP-től: minden pár egyetlen tartomány két gépnévvel. Írja le az elhelyezést, és jelölje meg, min osztozik minden szavazó — hipervizor, PDU, rack teteji kapcsoló, tárolótömb, NAT-eszköz, VPN-koncentrátor. Ezután papíron távolítsa el az összes megosztott objektumot, és számolja újra a maradék szavazatokat. Az a fürt, amely egyetlen meghibásodott gazdagép miatt két szavazót veszít, végig egyszavazós fürt volt; még senki nem tette fel neki a kérdést.

Mit tud és mit nem tud túlélni egy kéthelyszínes felosztás

Ha három szavazót kettő és egy arányban helyeznek el két helyszínen, a nagyobb oldal megtartja a kvórumot, amikor a másik helyszín eltűnik, az egyszavazós oldal pedig soha. Ez az aszimmetria aritmetika, nem hangolás. Bármely többségi alapon működő etcd-fürt, amely pontosan két független helyszínre oszlik, megbukik a „veszítsd el bármelyik helyszínt, és folytasd a véglegesítést” próbán, mert mindkét oldalnak egyszerre kellene a szavazatok több mint felét birtokolnia.

Az alábbi táblázat a leggyorsabb módja annak, hogy lássa, milyen hibákat vásárolt valójában. Minden sort így olvasson: ha ma éjjel ez az egész sor eltűnik, a túlélők még mindig véglegesíthetnek egy írást?

Miért nem ad soha szavazatot az alagút

A VPN szállítás, nem tag. Elérhetővé tehet egy távoli szavazót, és a felosztást valami lassú időtúllépésnek látszó dologgá alakíthatja, és ennyi a teljes hozzájárulása a kvórumhoz. Amit hozzáad, az a költség, mert minden véglegesítésnek át kell kelnie a kapcsolaton, és az etcd megfizeti ezt az oda-vissza utat azoknál az írásoknál, amelyek a raft-naplót érintik. A lengő útvonal a replikációt újrapróbálkozásokká és választásokká változtatja.

A felosztások az a hely, ahol az emberek mágiát várnak, ezért legyen pontos velük kapcsolatban. Ha a kapcsolat kiesik, miközben a régi vezető az egyszavazós oldalon ül, az az oldal nem tud véglegesíteni, és a vezető lemond, amikor a választási időtúllépés lejár, miközben a kétszavazós oldal helyettest választ. Az etcd útmutatója a hibamódokról egyszerűen leírja a viselkedést: folytatódó szolgáltatás a többségi oldalon, semmilyen második írható fürt az elszigetelt oldalon.

Döntse el, melyik kiesést vásárolja meg

A kettő plusz egy jogos terv, amikor az A helyszín az elsődleges, és elfogadja, hogy elvesztése a vezérlősík-írások elvesztését jelenti, amíg valaki cselekszik. Az teszi hibává, hogy ezt a döntést hallgatólagosan hagyja. Írja be a runbookba: melyik helyszínről éli túl a vezérlősíkja, és mit tesz az üzemeltető, amikor a másik helyszín 03:00-kor kiesik.

Ha a követelmény inkább „bármelyik helyszín meghibásodhat”, az elhelyezésnek minden helyszínen többséget kell tartania, és három szavazó két helyszínen ezt nem tudja. Vagy hozzáad egy valóban független harmadik tartományt — egy kis régió egy másik szolgáltatónál működik, ha az odavezető útvonal stabil —, vagy két fürtre oszlik külön etcd-vel, és elfogadja ennek a felosztásnak az üzemeltetési költségét. Semmilyen tanús rövidítés nem kerüli el ezt: az etcd-nek nincs könnyű döntőbíró tagja, így a harmadik szavazó teljes jogú tag saját lemez-, memória- és hálózati igényekkel. Egy „tanú” feliratú doboz rajzolása a diagramra nem hoz létre tanút.

A kvórum nem ugyanaz, mint a szolgáltatás

Az etcd kvóruma abban tartja az API-kiszolgálót, hogy elfogadjon írásokat, és ennyi az egész, amit tart. A terheléselosztó állapotellenőrzései, az ingress, a CNI elérhetősége az alagúton át, a kötetcsatolási zónák és az alkalmazásreplikáció mindegyikének megvan a maga válasza. Egy fürt tarthat tiszta többséget, és mégis semmi hasznosat nem nyújthat a felhasználóknak.

Ezután erősítse meg a tagságot, amelyről azt hiszi, hogy van, mert a diagramok elsodródnak:

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

Hasonlítsa össze a taglistát az elhelyezési rajzzal. Ha két tag ugyanarra a gazdagépre vagy ugyanarra a rackre oldódik fel, a rajz a hibás, nem a fürt, és egy hibás topológia körüli átméretezés csak ugyanannak a kiesésnek a drágább változatát vásárolja meg.

Mielőtt jóváhagy bármilyen háromszavazós tervet, válaszoljon négy kérdésre: hány szavazó veszít áramot egyszerre, melyik helyszín elvesztése hagy még többséget, hol ül a vezető, amikor az alagút kiesik, és mit tehet még a túlélő helyszín. Ha bármelyikre „nem biztos” a válasz, a fürt még nem magasan elérhető. Ez három gép, amelyeknek szerencséjük volt.