Нужны ли кластеру 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
Сравните список членов с чертежом размещения. Если два члена разрешаются в один и тот же хост или одну и ту же стойку, неверен чертёж, а не кластер, и изменение размеров вокруг ошибочной топологии покупает лишь более дорогую версию того же простоя.
Прежде чем одобрять любой проект с тремя голосующими, ответьте на четыре вопроса: сколько голосующих теряют питание вместе, чья потеря площадки всё ещё оставляет большинство, где сидит лидер, когда туннель падает, и что ещё может сделать выжившая площадка. «Не уверен» по любому из них означает, что кластер ещё не высокодоступен. Это три машины, которым повезло.