Нужни ли са на клъстер Kubernetes в два обекта три избирателя etcd?
Три възела на контролната равнина в два обекта VPN все още губят кворум, когато по-големият обект угасне. Пребройте истинските избиратели на etcd и изберете загубата, която оцелявате.
Три виртуални машини на контролната равнина изглеждат като три шанса да преживеете лоша нощ. Не са, и разстоянието между тези две вярвания е това, което превръща подредения дизайн от три възела в клъстер, който спира да приема записи, когато една сграда загуби захранване. VPN връзка между обектите прави машините достъпни една за друга и скрива проблема, вместо да го решава. Гласовете се броят по член на etcd и два от тези членове все още могат да стоят зад един комутатор, един UPS и един канал.
Три възела на контролната равнина, един домейн на отказ
Изпълнявате kubectl get nodes, виждате три записа на контролната равнина и отбелязвате клъстера като високодостъпен. Този брой описва планируем капацитет, а не оцеляване. В kubeadm, задържан без външен etcd, всеки възел на контролната равнина също хоства член, така че три възела наистина ви дават три избирателя. Дали тези избиратели отказват независимо, е отделен въпрос, на който списъкът с възли не може да отговори.
Две ВМ на един хипервизор, два стелажа на едно захранване, два канала от един доставчик: всяка двойка е един домейн с две имена на хостове. Запишете разположението и отбележете какво споделя всеки избирател — хипервизор, PDU, комутатор в горната част на стелажа, дисков масив, устройство NAT, концентратор VPN. След това премахнете всеки споделен обект на хартия и преброете останалите гласове. Клъстер, който губи двама избиратели заради един отказал хост, през цялото време е бил клъстер с един избирател; никой просто не му е задал този въпрос.
Какво може и какво не може да преживее разделяне на два обекта
Когато три избирателя са разположени две и едно в два обекта, по-голямата страна запазва кворум, когато другият обект изчезне, а страната с един избирател — никога. Тази асиметрия е аритметика, не настройка. Всеки etcd клъстер, основан на мнозинство, разпределен точно в два независими обекта, се проваля на теста „загуби който и да е обект и продължи да записваш“, защото двете страни би трябвало едновременно да държат повече от половината гласове.
Таблицата по-долу е най-бързият начин да видите какви откази всъщност сте купили. Четете всеки ред така: ако целият този ред изчезне тази вечер, могат ли оцелелите все още да запишат?
| 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 |
Защо тунелът никога не добавя глас
VPN е транспорт, а не член. Той може да направи отдалечен избирател достъпен и може да превърне разделяне в нещо, което изглежда като бавен таймаут, и това е целият му принос към кворума. Това, което добавя, е цена, защото всеки запис трябва да пресече връзката и etcd плаща този двупосочен път при записи, които докосват журнала raft. Път, който трепти, превръща репликацията в повторни опити и избори.
Разделянията са мястото, където хората очакват магия, затова бъдете точни за тях. Ако връзката падне, докато старият лидер седи от страната с един избирател, тази страна не може да записва и лидерът се оттегля, след като изтече таймаутът за избори, докато страната с двама избиратели избира заместник. Ръководството на etcd за режимите на отказ описва поведението просто: продължаващо обслужване от страната на мнозинството, без втори клъстер, достъпен за запис, от изолираната страна.
Решете кой престой купувате
Две плюс едно е законен дизайн, когато обект A е основният и приемате, че загубата му означава загуба на записи на контролната равнина, докато някой не предприеме действие. Това, което го превръща в дефект, е да оставите това решение неявно. Запишете го в runbook: от кой обект оцелява контролната ви равнина и какво прави операторът, когато другият обект угасне в 03:00.
Ако изискването е вместо това „който и да е обект може да се провали“, разположението трябва да държи мнозинство във всеки обект, а три избирателя в два обекта не могат да го направят. Или добавяте наистина независим трети домейн — малък регион при друг доставчик работи, ако пътят до него е стабилен — или се разделяте на два клъстера с отделни etcd и приемате оперативната цена на това разделяне. Никоя прищявка със свидетел не избягва това: etcd няма лек член-арбитър, така че третият избирател е пълен член със собствени изисквания за диск, памет и мрежа. Начертаването на кутия с надпис „свидетел“ на диаграмата не създава такава.
Кворумът не е същото като обслужване
Кворумът на etcd поддържа API сървъра способен да приема записи и това е всичко, което поддържа. Проверките за състояние на балансьора на натоварването, ingress, достъпността на CNI през тунела, зоните за прикачване на томове и репликацията на приложенията всяко се нуждае от собствен отговор. Клъстер може да държи чисто мнозинство и пак да не предлага нищо полезно на потребителите.
След това потвърдете членството, което смятате, че имате, защото диаграмите се разминават:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
Сравнете списъка на членовете с чертежа на разположението. Ако два члена се решават до един и същ хост или един и същ стелаж, чертежът е грешен, а не клъстерът, и преоразмеряването около грешна топология купува само по-скъпа версия на същия престой.
Преди да одобрите какъвто и да е дизайн с три избирателя, отговорете на четири въпроса: колко избирателя губят захранване заедно, чия загуба на обект все още оставя мнозинство, къде седи лидерът, когато тунелът падне, и какво все още може да направи оцелелият обект. „Не съм сигурен“ за който и да е от тях означава, че клъстерът все още не е високодостъпен. Това са три машини, които са имали късмет.