Czy klaster Kubernetes w dwóch lokalizacjach potrzebuje trzech wyborców etcd?

Trzy maszyny wirtualne płaszczyzny sterowania wydają się trzema szansami na przetrwanie złej nocy. Nie są, a odległość między tymi dwoma przekonaniami zmienia schludny projekt trzech węzłów w klaster, który przestaje przyjmować zapisy, gdy jeden budynek traci zasilanie. Łącze VPN między lokalizacjami czyni maszyny osiągalnymi nawzajem i ukrywa problem, zamiast go naprawiać. Głosy liczy się na członka etcd, a dwa z tych członków nadal mogą siedzieć za jednym przełącznikiem, jednym UPS-em i jednym łączem.

Trzy węzły płaszczyzny sterowania, jedna domena awarii

Uruchamiasz kubectl get nodes, widzisz trzy wpisy płaszczyzny sterowania i zapisujesz klaster jako wysoce dostępny. Ta liczba opisuje zdolność planistyczną, a nie przetrwanie. W kubeadm bez zewnętrznego etcd każdy węzeł płaszczyzny sterowania hostuje też członka, więc trzy węzły naprawdę dają trzech wyborców. Czy ci wyborcy zawodzą niezależnie, to osobne pytanie, na które lista węzłów nie potrafi odpowiedzieć.

Dwie maszyny wirtualne na jednym hiperwizorze, dwie szafy na jednym zasilaniu, dwa łącza od jednego ISP: każda para to jedna domena nosząca dwie nazwy hosta. Zapisz rozmieszczenie i zaznacz, co dzieli każdy wyborca — hiperwizor, PDU, przełącznik szczytu szafy, macierz dyskowa, urządzenie NAT, koncentrator VPN. Następnie usuń na papierze każdy współdzielony obiekt i przelicz pozostałe głosy. Klaster, który traci dwóch wyborców z powodu jednego zawiedzionego hosta, przez cały czas był klastrem jednego wyborcy; nikt jeszcze nie zadał mu tego pytania.

Co podział na dwie lokalizacje może, a czego nie może przetrwać

Gdy trzech wyborców rozłoży się po dwóch i jednym w dwóch lokalizacjach, większa strona utrzymuje kworum, gdy druga lokalizacja znika, a strona z jednym wyborcą nigdy. Ta asymetria to arytmetyka, nie strojenie. Każdy klaster etcd oparty na większości rozłożony dokładnie na dwie niezależne lokalizacje nie przechodzi testu „strać dowolną lokalizację i dalej zatwierdzaj”, bo obie strony musiałyby jednocześnie mieć więcej niż połowę głosów.

Tabela poniżej to najszybszy sposób, by zobaczyć, jakie awarie naprawdę kupiłeś. Każdy wiersz czytaj tak: jeśli tej nocy zniknie cały ten wiersz, czy ocalali nadal mogą zatwierdzić zapis?

Dlaczego tunel nigdy nie dodaje głosu

VPN to transport, nie członek. Może uczynić zdalnego wyborcę osiągalnym i może zamienić partycję w coś, co wygląda jak wolny limit czasu, i to jest cały jego wkład w kworum. To, co dodaje, to koszt, bo każde zatwierdzenie musi przejść przez łącze, a etcd płaci tę podróż w obie strony przy zapisach dotykających dziennika raft. Ścieżka, która migocze, zamienia replikację w ponowienia i wybory.

Partycje to miejsce, w którym ludzie oczekują magii, więc bądź precyzyjny. Jeśli łącze padnie, gdy stary lider siedzi po stronie z jednym wyborcą, ta strona nie może zatwierdzić i lider ustępuje, gdy wygaśnie limit czasu wyborów, podczas gdy strona z dwoma wyborcami wybiera następcę. Przewodnik etcd po trybach awarii opisuje zachowanie wprost: dalsza usługa po stronie większości, żaden drugi zapisywalny klaster po stronie odizolowanej.

Zdecyduj, którą przerwę kupujesz

Dwa plus jeden to uzasadniony projekt, gdy lokalizacja A jest główna i akceptujesz, że jej utrata oznacza utratę zapisów płaszczyzny sterowania, dopóki ktoś nie zadziała. Wadą czyni go pozostawienie tej decyzji domyślną. Zapisz ją w runbooku: z której lokalizacji przetrwa twoja płaszczyzna sterowania i co operator robi, gdy druga lokalizacja gaśnie o 03:00.

Jeśli wymaganiem jest raczej „dowolna lokalizacja może zawieść”, rozmieszczenie musi mieć większość w każdej lokalizacji, a trzech wyborców w dwóch lokalizacjach nie potrafi tego. Albo dodajesz naprawdę niezależną trzecią domenę — mały region u innego dostawcy działa, jeśli droga do niego jest stabilna — albo dzielisz się na dwa klastry z osobnym etcd i akceptujesz koszt operacyjny tego podziału. Żadna skrócona droga ze świadkiem tego nie unika: etcd nie ma lekkiego członka arbitra, więc trzeci wyborca to pełny członek z własnymi wymaganiami dotyczącymi dysku, pamięci i sieci. Narysowanie na diagramie ramki z etykietą świadek nie tworzy świadka.

Kworum to nie to samo co usługa

Kworum etcd utrzymuje serwer API zdolny przyjmować zapisy i to jest wszystko, co utrzymuje. Kontrole stanu load balancera, ingress, osiągalność CNI przez tunel, strefy podłączania wolumenów i replikacja aplikacji każda potrzebuje własnej odpowiedzi. Klaster może mieć czystą większość i nadal nie oferować użytkownikom niczego użytecznego.

Następnie potwierdź członkostwo, które, jak sądzisz, masz, bo diagramy dryfują:

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

Porównaj listę członków z rysunkiem rozmieszczenia. Jeśli dwóch członków rozwiązuje się do tego samego hosta lub tej samej szafy, to rysunek jest błędny, a nie klaster, i zmiana rozmiaru wokół błędnej topologii kupuje tylko droższą wersję tej samej przerwy.

Przed zatwierdzeniem dowolnego projektu z trzema wyborcami odpowiedz na cztery pytania: ilu wyborców traci zasilanie razem, której lokalizacji utrata nadal pozostawia większość, gdzie siedzi lider, gdy tunel pada, i co jeszcze może zrobić ocalała lokalizacja. „Nie jestem pewien” przy którymkolwiek z nich oznacza, że klaster nie jest jeszcze wysoce dostępny. To trzy maszyny, które miały szczęście.