Ответ
Для обеспечения отказоустойчивости и высокой доступности control plane в Kubernetes рекомендуется развертывать нечетное количество мастер-узлов, обычно 3 для средних кластеров или 5 для крупных, высоконагруженных сред.
Причины и механизм:
-
Консенсус в etcd: Состояние кластера хранится в распределенном key-value хранилище etcd, которое для согласованности данных использует алгоритм консенсуса Raft. Raft требует, чтобы для любых операций записи был достигнут кворум – большинство членов кластера (
N/2 + 1). -
Анализ вариантов:
- 1 мастер: Single point of failure. При падении узла control plane полностью недоступен.
- 2 мастера: Проблема split-brain. При потере связи между узлами ни один из них не сможет достичь кворума (нужно 2 из 2), что приведет к невозможности записи. Кластер заморозится.
- 3 мастера: Это минимальное рекомендуемое количество. Кворум составляет 2 (
3/2 + 1 = 2). Кластер может пережить отказ одного мастера, сохраняя возможность записи и чтения. - 5 мастеров: Кворум составляет 3. Кластер может пережить отказ двух узлов одновременно, что повышает отказоустойчивость, но увеличивает сложность и стоимость.
Практический пример развертывания: При инициализации кластера с помощью kubeadm сначала настраивается первый control-plane узел, а затем к нему присоединяются остальные, образуя отказоустойчивый кластер.
# Инициализация первого control-plane узла с указанием endpoint для балансировщика нагрузки
kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:6443" --upload-certs
# Присоединение второго и третьего control-plane узлов
kubeadm join LOAD_BALANCER_DNS:6443 --token <token>
--discovery-token-ca-cert-hash <hash>
--control-plane
--certificate-key <key-from-init>Трафик к API-серверу мастер-узлов обычно балансируется через внешний Load Balancer (например, облачный NLB или HAProxy).
