Potřebuje kluster Kubernetes na dvou lokalitách tři voliče etcd?
Tři uzly řídicí roviny na dvou lokalitách VPN stále ztrácejí kvórum, když větší lokalita zhasne. Spočítejte skutečné voliče etcd a vyberte ztrátu, kterou přežijete.
Tři VM řídicí roviny působí jako tři šance přežít špatnou noc. Nejsou a právě vzdálenost mezi těmito dvěma přesvědčeními mění úhledný návrh se třemi uzly v kluster, který přestane přijímat zápisy, když jedna budova ztratí proud. VPN spojení mezi lokalitami zpřístupní stroje navzájem a problém spíš skrývá, než řeší. Hlasy se počítají za každého člena etcd a dva z těchto členů mohou stále sedět za jedním přepínačem, jedním UPS a jedním uplinkem.
Tři uzly řídicí roviny, jedna doména selhání
Spustíte kubectl get nodes, uvidíte tři záznamy řídicí roviny a kluster zapíšete jako vysoce dostupný. Tento počet popisuje plánovatelnou kapacitu, nikoli přežití. V kubeadm bez externího etcd hostuje každý uzel řídicí roviny také člena, takže tři uzly vám skutečně dají tři voliče. Zda tito voliči selhávají nezávisle, je samostatná otázka, na kterou seznam uzlů nedokáže odpovědět.
Dvě VM na jednom hypervizoru, dva racky na jednom napájení, dva uplinky od jednoho ISP: každá dvojice je jedna doména s dvěma jmény hostitelů. Zapište rozložení a označte, co každý volič sdílí — hypervizor, PDU, přepínač na vrcholu racku, diskové pole, zařízení NAT, koncentrátor VPN. Potom na papíře odstraňte každý sdílený objekt a znovu spočítejte zbývající hlasy. Kluster, který ztratí dva voliče kvůli jednomu selhanému hostiteli, byl celou dobu klusterem s jedním voličem; nikdo mu tu otázku ještě nepoložil.
Co rozdělení na dvě lokality přežije a co ne
Když jsou tři voliči rozloženi dva a jeden na dvou lokalitách, větší strana si při zmizení druhé lokality udrží kvórum a strana s jedním voličem nikdy. Tato asymetrie je aritmetika, ne ladění. Každý etcd kluster založený na většině rozmístěný přesně na dvě nezávislé lokality neprojde testem „ztratit kteroukoli lokalitu a dál commitovat“, protože obě strany by musely současně držet více než polovinu hlasů.
Tabulka níže je nejrychlejší způsob, jak zjistit, které poruchy jste si vlastně koupili. Každý řádek čtěte takto: pokud dnes v noci zmizí celý tento řádek, mohou přeživší stále zapsat?
| 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 |
Proč tunel nikdy nepřidá hlas
VPN je doprava, ne člen. Může zpřístupnit vzdáleného voliče a může z rozdělení udělat něco, co vypadá jako pomalý timeout, a to je celý jeho příspěvek ke kvóru. Co přidává, je cena, protože každý commit musí překročit spojení a etcd platí tuto cestu tam a zpět u zápisů, které se dotýkají raft logu. Cesta, která kmitá, mění replikaci v opakované pokusy a volby.
Rozdělení jsou místem, kde lidé čekají kouzlo, proto o nich buďte přesní. Pokud spojení spadne, zatímco starý leader sedí na straně s jedním voličem, tato strana nemůže commitovat a leader se vzdá, jakmile vyprší časový limit voleb, zatímco strana se dvěma voliči zvolí náhradu. Průvodce etcd režimy selhání popisuje chování jasně: pokračující služba na straně většiny, žádný druhý zapisovatelný kluster na izolované straně.
Rozhodněte, který výpadek kupujete
Dva plus jedna je legitimní návrh, když je lokalita A primární a přijmete, že její ztráta znamená ztrátu zápisů řídicí roviny, dokud někdo nezasáhne. Tím, co z toho dělá vadu, je ponechání tohoto rozhodnutí implicitní. Zapište ho do runbooku: ze které lokality vaše řídicí rovina přežije a co operátor dělá, když druhá lokalita ve 03:00 zhasne.
Pokud je požadavek místo toho „kterákoli lokalita může selhat“, musí rozložení držet většinu v každé lokalitě, a tři voliči na dvou lokalitách to nedokážou. Buď přidáte skutečně nezávislou třetí doménu — malý region u jiného poskytovatele funguje, je-li cesta k němu stabilní — nebo se rozdělíte na dva klustery s odděleným etcd a přijmete provozní cenu tohoto rozdělení. Žádná zkratka se svědkem tomu neunikne: etcd nemá lehkého člena arbitra, takže třetí volič je plný člen s vlastními nároky na disk, paměť a síť. Nakreslení rámečku s popiskem svědek do diagramu žádného nevytvoří.
Kvórum není totéž jako služba
Kvórum etcd udržuje API server schopný přijímat zápisy a to je vše, co udržuje. Kontrola stavu load balanceru, ingress, dostupnost CNI přes tunel, zóny připojení svazků a replikace aplikací každá potřebují vlastní odpověď. Kluster může držet čistou většinu a přesto uživatelům neposkytovat nic užitečného.
Potom potvrďte členství, o kterém si myslíte, že ho máte, protože diagramy se posouvají:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
Porovnejte seznam členů s nákresem rozložení. Pokud se dva členi překládají na stejného hostitele nebo stejný rack, špatný je nákres, ne kluster, a změna velikosti kolem chybné topologie kupuje jen dražší verzi stejného výpadku.
Než schválíte jakýkoli návrh se třemi voliči, odpovězte na čtyři otázky: kolik voličů ztratí proud společně, čí ztráta lokality ještě ponechá většinu, kde sedí leader, když tunel spadne, a co přeživší lokalita ještě dokáže. „Nevím“ u kteréhokoli z nich znamená, že kluster zatím není vysoce dostupný. Jsou to tři stroje, které měly štěstí.