Чи потрібні кластеру Kubernetes на двох майданчиках три голосувальники etcd?
Три вузли площини керування на двох майданчиках VPN досі втрачають кворум, коли більший майданчик зникає. Порахуйте справжніх голосувальників etcd і виберіть втрату, яку переживете.
Три віртуальні машини площини керування виглядають як три шанси пережити погану ніч. Але ні, і саме відстань між цими двома переконаннями перетворює охайний проєкт із трьох вузлів на кластер, який перестає приймати записи, коли одна будівля втрачає живлення. VPN-зв'язок між майданчиками робить машини доступними одна для одної й приховує проблему, а не вирішує її. Голоси рахуються за кожним членом etcd, і два з цих членів досі можуть сидіти за одним комутатором, одним ДБЖ і однією лінією.
Три вузли площини керування, один домен відмови
Ви запускаєте 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
Порівняйте список членів із кресленням розміщення. Якщо два члени розв'язуються в той самий хост або той самий стелаж, помилкове креслення, а не кластер, і зміна розмірів навколо хибної топології купує лише дорожчу версію того самого простою.
Перш ніж схвалити будь-який проєкт із трьома голосувальниками, дайте відповіді на чотири питання: скільки голосувальників втрачають живлення разом, чия втрата майданчика ще залишає більшість, де сидить лідер, коли тунель падає, і що ще може зробити майданчик, який вижив. «Не певен» щодо будь-якого з них означає, що кластер ще не високодоступний. Це три машини, яким пощастило.