Сколько должно быть мастеров в Kubernetes?

Как выбрать количество мастер-нод в Kubernetes кластере

Это фундаментальный вопрос архитектуры, и ответ на него зависит от требований к отказоустойчивости, производительности и бюджету. Единственно правильного числа не существует, но есть общепринятые рекомендации и компромиссы, которые я выстраивал на основе опыта развертывания десятков кластеров в продакшене.

Рекомендуемые конфигурации и их обоснование

Кластеры Kubernetes принято разворачивать в одной из трех основных конфигураций по количеству мастер-нод:

• Один мастер (Single Master)

    *   **Архитектура:** Одна нода, на которой работают все компоненты control plane: API Server, Scheduler, Controller Manager, а также обычно etcd.
    *   **Когда использовать:**
        *   **Локальные среды** (Minikube, Kind, K3s).
        *   **Непродукционные среды** (dev, staging) для тестирования функционала.
        *   **Пилотные проекты** или небольшие рабочие нагрузки, где допустим простой.
    *   **Недостатки:** Единственная точка отказа (SPOF). При падении этой ноды управление кластером (деплой, масштабирование, self-healing) становится невозможным. Это абсолютно неприемлемо для любого серьезного production-окружения.

• Три мастера (High Availability / HA)

    *   **Архитектура:** Три ноды, образующие кворум для **etcd** (распределенного хранилища состояния кластера). Компоненты control plane реплицируются на все три ноды. Используется балансировщик нагрузки (обычно внешний, например, облачный Network Load Balancer или аппаратный) перед API Server.
    *   **Когда использовать:** **Стандарт для production-сред.** Конфигурация выдерживает отказ одной мастер-ноды (`N/2 + 1 = 2` — кворум сохраняется). Это оптимальный баланс между отказоустойчивостью, сложностью и стоимостью.
    *   **Как это работает на практике:**

    ```yaml
    # Пример манифеста для инициализации HA-кластера с kubeadm
    apiVersion: kubeadm.k8s.io/v1beta3
    kind: InitConfiguration
    localAPIEndpoint:
      advertiseAddress: "10.0.0.1"
      bindPort: 6443
    ---
    apiVersion: kubeadm.k8s.io/v1beta3
    kind: ClusterConfiguration
    controlPlaneEndpoint: "k8s-api-lb.example.com:6443" # VIP или DNS балансировщика
    etcd:
      external:
        endpoints:
          - https://etcd-1:2379
          - https://etcd-2:2379
          - https://etcd-3:2379
    ```

        После инициализации первой ноды, остальные мастера присоединяются к кластеру:

    ```bash
    kubeadm join k8s-api-lb.example.com:6443 --token <token> \
      --discovery-token-ca-cert-hash sha256:<hash> \
      --control-plane
    ```

• Пять и более мастеров (Large Scale / Maximum Resilience)

    *   **Архитектура:** Пять или более нод. Редкая, но необходимая конфигурация для экстремальных сценариев.
    *   **Когда использовать:**
        *   **Очень крупные кластеры** (тысячи нод, десятки тысяч подов), где нагрузка на API Server критически высока, и ее нужно распределить.
        *   **Повышенные требования к доступности,** когда необходимо пережить одновременный отказ двух зон доступности (Availability Zones) в облаке. Кворум из 5 нод (`N=5, кворум = 3`) сохраняется при потере двух.
        *   **Строгие регуляторные требования,** предписывающие распределение на большее число физических стоек.
    *   **Недостатки:** Значительное усложнение операций (обновление, troubleshooting), повышенная стоимость инфраструктуры и сетевого взаимодействия, а также **снижение производительности записи в etcd**, так как для подтверждения каждой операции требуется больше подтверждений от участников кворума.

Ключевые факторы для принятия решения

При выборе конфигурации в продакшене я всегда анализирую следующие аспекты:

1. Требования к SLA (Service Level Agreement): Какой допустимый простой? Для 99.9% доступности (~8.7 часа простоя в год) часто достаточно трех мастеров. Для 99.99% (~52 минуты) нужно безупречное проектирование, и 5 мастеров могут быть частью стратегии.
2. Масштаб кластера: Количество worker-нод и объектов Kubernetes (поды, сервисы). Больше объектов → выше нагрузка на API Server и etcd. В очень больших кластерах может потребоваться горизонтальное масштабирование control plane (5+ нод) или тонкая настройка etcd (отдельные кластеры для событий, большие размеры кэша и квоты).
3. Бюджет: Каждая мастер-нода — это дополнительные вычислительные ресурсы (CPU, RAM, диск), лицензии (если используются коммерческие ОС) и стоимость балансировщика нагрузки.
4. Инфраструктура: Распределение по зонам доступности (AZ). Идеальная практика — размещать мастер-ноды в разных AZ для защиты от падения дата-центра. Три мастера распределяют по трем AZ. Пять мастеров можно распределить как 2-2-1 или 2-1-2-1-1 по AZ.
5. Режим работы etcd: Stacked etcd (работает на тех же нодах, что и control plane) проще в развертывании, но связывает судьбу etcd и мастера. External etcd (отдельный кластер) сложнее, но дает больше гибкости для масштабирования и резервного копирования. Для 3 мастеров stacked etcd — стандарт. Для 5+ часто рассматривают external etcd.

Итоговое правило и практический совет

Золотым стандартом и отправной точкой для любого production-кластера являются три мастер-ноды. Эта конфигурация обеспечивает необходимую отказоустойчивость, хорошо документирована, поддерживается всеми инструментами (kubeadm, Terraform-провайдерами, облачными managed-сервисами) и является наиболее сбалансированной.

Начинайте с трех мастеров. Масштабируйтесь до пяти только при наличии доказанных метрик, указывающих на то, что три ноды стали узким местом в производительности (постоянная высокая загрузка CPU/памяти на API Server, высокая задержка операций etcd) или если бизнес-требования к доступности становятся экстремально строгими. В 90% случаев трех мастер-нод более чем достаточно для успешной и устойчивой работы Kubernetes-кластера.