Kubernetes в своей инфраструктуре: минимальные требования к серверам

ИТ-команда полгода назад была довольна вендорским облаком: managed-кластер, кнопка «добавить ноду». Потом счёт за квартал вырос почти вдвое за compute и egress, а служба безопасности принесла требование держать персональные данные внутри периметра. Финдиректор хочет прогнозируемый бюджет, ИТ-директор - контроль над данными. На пересечении этих требований появляется Kubernetes у себя, и вопрос сразу переходит в плоскость железа: что должно стоять в стойке.

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

Первая - control plane, мозг кластера: etcd хранит состояние всех объектов, API server принимает команды, scheduler решает, на какой ноде запустить под, controller manager поддерживает желаемое состояние.

Вторая плоскость - worker-ноды, на которых исполняются контейнеры приложений. Любой кластер построен на этом разделении ролей, и каждая плоскость живёт по своим требованиям к железу, сети и регламентам обслуживания.

В managed-сервисах вроде Amazon EKS, Google GKE или Yandex Managed Kubernetes control plane полностью на стороне провайдера. Команда платит за управляющую плоскость как за подписку, получает SLA и не думает про обновление etcd, ротацию сертификатов и резервное копирование состояния кластера. Управляешь только воркерами и приложениями. Стоимость пересчитывается ежемесячно и зависит от трафика и количества vCPU.

В on-premise Kubernetes кластер обе плоскости разворачивает и обслуживает сама команда. Нужно не только железо под control plane и воркеры, но и инженер, который умеет обновлять etcd без потери кворума, разносить primary и standby API-серверы по разным стойкам и чинить CNI, если после апгрейда сломалась маршрутизация. «У себя» - это эксплуатационная функция в штатном расписании, без которой кластер живёт до первого инцидента.

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

Минимальные требования к Kubernetes для управляющих узлов диктует не API server, а etcd. Это распределённое key-value-хранилище, чувствительное к латентности диска: при задержках записи выше 10–20 мс кластер начинает терять кворум и переизбирать лидера. Поэтому под etcd обязательно ставят SSD или NVMe от 100 ГБ - не RAID 5, не общий сетевой том. Сам узел control plane - минимум 4 vCPU, 8 ГБ ОЗУ и сеть 1–10 Гбит/с с низкими джиттерами между нодами.

Для боевой эксплуатации одна нода неприемлема: при её падении кластер становится read-only, новые поды не планируются. Минимум для HA - три ноды control plane: кворум etcd собирается из N/2+1 участников, три ноды переживают потерю одной, пять - двух. Практический вывод: control plane выносится на отдельные физические серверы и не совмещается с воркерами. На том же железе допустимы только сервисные демоны кластера, никаких прикладных подов.

Спецификация воркера зависит от профиля нагрузки, выделяем два рабочих сценария:

Минимальные требования к Kubernetes для воркеров включают запас 20–30% по CPU и памяти. Это нужно, чтобы при отказе одной ноды поды переехали на оставшиеся, а не висели в Pending. Если кластер постоянно работает на 90% загрузки, любой инцидент превращается в каскадный отказ, и приложения начинают терять SLA быстрее, чем дежурный успевает отреагировать.

3+3 ноды (три control plane и три воркера) - рабочий минимум на старте для боевого кластера. Но если в плане запуска уже 50+ подов или появляются stateful-сервисы с persistent volumes для баз и очередей, закладывайте 5+ воркеров сразу. Добавлять ноды в работающий кластер можно, но перераспределять поды между нодами под нагрузкой всегда дороже, чем стартовать с запасом по ресурсам.

От железа переходим к связям между нодами - сети, хранилищу и балансировке трафика. Сетевую связность между подами обеспечивает CNI-плагин. Kubernetes состоит из двух логических плоскостей. Подсети подов и сервисов не должны пересекаться с корпоративной сетью и VPN-пулами, иначе маршрутизация ломается на стыке. Решение принимается до закупки железа, потому что некоторые CNI требовательны к версии ядра Linux и MTU.

Под хранилище в Kubernetes используются CSI-драйверы. Они подключают внешние тома по NFS, iSCSI или протоколам коммерческих СХД. Локальные NVMe воркеров быстры, но привязаны к ноде: при её отказе под не переедет с данными. Локальные диски разумно отдавать только под кэш и stateless. Всё, что должно пережить падение ноды на внешний массив с репликацией. Хорошие серверы для виртуализации подходят и как платформа под worker-ноды: те же требования к БП, дискам и IPMI.

Балансировка трафика делится на два уровня. Внешний L4-балансировщик принимает запросы из интернета и распределяет их между нодами. MetalLB - программный вариант на bare metal, подходит для собственных контуров без жёстких требований к пропускной способности и SLA на сам балансировщик. F5 и A10 - аппаратные решения корпоративного класса с другим уровнем стоимости и поддержки, их берут под высокую пропускную способность, аппаратное ускорение TLS и интеграцию с корпоративным WAF.

Дальше ingress-контроллер L7 (NGINX или Traefik) маршрутизирует HTTP/HTTPS по хостам и путям, терминирует TLS и применяет правила переписи URL. Совмещать роли в одном компоненте можно только на тестовых стендах. На бою L4 и L7 разносятся, иначе отказ одного слоя обрывает весь входящий трафик кластера.

Когда инфраструктурный контур собран, считаем, при каком объёме он окупается.

Облако дешёвое на старте: первые 2–3 ноды по подписке стоят меньше, чем закупка серверов и стойко-места. Дальше счёт растёт линейно с количеством vCPU и трафиком наружу. On-premise устроен иначе - расходы ступенчатые: инвестиция в железо, плато на годы, следующая закупка под рост. До определённого объёма облако выигрывает, после - проигрывает, и разрыв увеличивается с каждым новым воркером.

Эмпирический порог переключения на собственное железо - кластер из 6–8 worker-нод с устойчивой утилизацией 60–70% при круглосуточной работе. С этого размера выкупленный on-premise Kubernetes кластер начинает экономить относительно эквивалентной подписки, и разрыв нарастает на каждом следующем годе эксплуатации.

Перед закупкой считаем TCO на горизонте 3 лет: серверы и СХД, сетевое оборудование, лицензии на гипервизор и мониторинг, электроэнергия и стойко-место, зарплата инженера эксплуатации. Сравниваем с реальным облачным счётом за 36 месяцев, а не с витринным прайсом «от». Только в этой логике видно, окупается ли железо или подписка остаётся выгоднее.

Экономика - половина решения, вторая половина - реалистичная оценка команды и нагрузки. Есть три сценария, в которых on-premise противопоказан:

On-premise Kubernetes окупается, когда у вас стабильная нагрузка от 6–8 воркеров с утилизацией 60–70%, в штате есть инженер с опытом эксплуатации etcd и CNI, а контроль над данными или сетью - реальное требование бизнеса. Базовая конфигурация - 3 control plane на NVMe и 3 воркера с резервом 20–30%, плюс отдельный L4-балансировщик и внешнее сетевое хранилище под persistent volumes. Если хотя бы один пункт под вопросом - managed-сервис на старте экономит и деньги, и нервы.