Серверы для Kubernetes on-premise: какие узлы нужны для control plane, worker и storage

Для Kubernetes on-premise нужны как минимум три логические группы серверов: управляющие узлы для control plane, рабочие узлы для приложений и продуманная подсистема хранения для данных. В тестовой среде эти роли можно совмещать, но для рабочего кластера управляющую часть лучше резервировать, worker-узлы рассчитывать по реальной нагрузке приложений, а storage проектировать отдельно по объему, задержкам, операциям ввода-вывода, репликации и восстановлению. Если сразу не учесть сеть, мониторинг, резервные копии и обновления, кластер сможет запускать контейнеры, но не станет надежной платформой для бизнес-сервисов.

Kubernetes on-premise отличается от облачного Kubernetes тем, что ответственность за инфраструктуру остается внутри компании. В облаке провайдер часто берет на себя часть задач: управляемый control plane, сетевые балансировщики, блочные диски, обновления, отказоустойчивость отдельных компонентов. В собственной инфраструктуре все это нужно спроектировать самостоятельно: серверы, диски, сеть, питание, стойки, коммутаторы, резервное копирование, мониторинг и регламент обслуживания.

Поэтому выбор серверов для Kubernetes нельзя сводить к вопросу «сколько ядер и памяти купить». Важно понимать роли узлов, профиль приложений, требования к данным, характер сетевого трафика и сценарии отказа. Ошибка в архитектуре может проявиться не сразу: кластер установится, первые pod-ы запустятся, но проблемы появятся при обновлении, отказе узла, росте количества сервисов или переносе базы данных.

Что такое Kubernetes on-premise и почему железо здесь важно

Kubernetes — это платформа для запуска контейнеризированных приложений. Она распределяет приложения по узлам, следит за их состоянием, перезапускает упавшие контейнеры, управляет доступом к сервисам, конфигурациями, секретами и томами данных. Внутри Kubernetes приложение обычно работает не «просто на сервере», а в pod — минимальной единице запуска, где может быть один или несколько контейнеров.

On-premise означает, что кластер работает на серверах компании, в собственной серверной, в корпоративном дата-центре или на арендованном выделенном железе. Такой подход дает контроль над оборудованием, сетью, размещением данных и политиками безопасности. Но вместе с контролем появляется и ответственность. Kubernetes не исправит слабую сеть, медленное хранилище, отсутствие резервирования или хаотичную схему обновлений.

Если кластер нужен только для обучения, можно использовать упрощенную схему. Если он нужен для внутренних сервисов, производственных приложений, баз данных, очередей, аналитики или CI/CD, подход должен быть другим. Нужно проектировать не отдельные серверы, а платформу: управляющую часть, рабочую часть, хранилище, сеть, наблюдаемость, резервные копии и планы обслуживания.

Основные роли узлов в Kubernetes-кластере

В Kubernetes есть управляющая часть и рабочие узлы. Управляющая часть принимает решения и хранит состояние кластера. Worker-узлы отвечают за запуск непосредственно приложения. Storage-система хранит постоянные данные, если приложения не являются полностью stateless (временными и без сохранения состояния).

Kubernetes официально описывает кластер как набор worker-узлов и control plane, который управляет этими узлами и pod-ами. Для производственных сред документация указывает, что control plane обычно работает на нескольких компьютерах, а кластер использует несколько узлов для отказоустойчивости и высокой доступности.

Control plane

Control plane — управляющая часть кластера. Она принимает команды от администраторов и систем автоматизации, хранит состояние кластера, планирует размещение pod-ов и следит, чтобы фактическое состояние совпадало с заданным.

Внутри control plane есть несколько ключевых компонентов:

• API-сервер принимает запросы и является основной точкой управления;
• etcd хранит состояние кластера;
• Планировщик выбирает, на каком узле запускать pod;
• Контроллеры следят за объектами Kubernetes и пытаются привести систему к нужному состоянию: например, перезапустить приложение, если оно исчезло.

Control plane не обязательно должен быть самым мощным по процессорам. Ему важнее стабильность, предсказуемые диски, низкие задержки сети между управляющими узлами и защита доступа. Если управляющая часть работает нестабильно, страдает весь кластер: новые приложения не размещаются, изменения не применяются, операции обслуживания становятся рискованными.

Worker-узлы

Worker-узлы — это серверы, на которых реально работают приложения. На них запускаются pod-ы с контейнерами, сетевые компоненты, агенты мониторинга, логирование, ingress-контроллеры, сервисные операторы и иногда агенты storage-системы.

Worker-узлы считают по нагрузке: сколько CPU и RAM требуется приложениям, какой сетевой трафик идет между сервисами, есть ли локальные диски, нужны ли GPU, сколько ресурсов забирают системные компоненты. Ошибка при расчете worker-узлов приводит к вытеснению pod-ов, задержкам, нехватке памяти, перегрузке сети и невозможности безопасно пережить отказ сервера.

Storage-узлы и storage-подсистема

Storage — это не просто «диски в сервере». Для Kubernetes это отдельная часть архитектуры, которая должна давать приложениям постоянные тома данных. Это может быть внешняя СХД, распределенное хранилище на серверах, локальные диски worker-узлов, сетевое файловое хранилище или сочетание нескольких вариантов.

Kubernetes сам по себе не делает данные отказоустойчивыми. Он умеет подключать тома, управлять заявками на хранилище и работать с разными системами через драйверы. Но надежность, репликация, задержки, восстановление после отказа и защита данных зависят от выбранной storage-системы и ее настройки.

Когда роли можно совмещать

В лаборатории или тестовом стенде можно запустить control plane и worker-нагрузки на одних и тех же серверах. Это удобно для обучения, проверки CI/CD, демонстраций, разработки и небольших экспериментов. Такая схема экономит оборудование и упрощает старт.

Но переносить лабораторную схему в рабочую среду без изменений опасно. Если один и тот же узел одновременно управляет кластером, выполняет приложения и хранит данные, любое обслуживание затрагивает сразу несколько уровней. Нужно обновить сервер — страдает control plane, приложения и storage. Узел вышел из строя — теряется не только вычислительная мощность, но и часть управляющей или дисковой подсистемы.

Для небольшого production-кластера иногда начинают с трех серверов, где роли частично совмещены. Это допустимо, если нагрузка небольшая, риски понятны, есть резервные копии и план роста. Но при появлении критичных приложений лучше разделять роли хотя бы логически: управляющие компоненты не должны конкурировать с тяжелыми пользовательскими нагрузками, а хранилище не должно зависеть от случайного размещения pod-ов.

В среднем и крупном кластере control plane лучше отделять от worker-узлов. Storage тоже нужно считать отдельно, особенно если в кластере работают базы данных, очереди, файловые сервисы, аналитика или приложения с постоянными данными.

Требования к control plane

Для production-среды один управляющий узел — слабое решение. Он может быть достаточен для тестового стенда, но в рабочем кластере становится точкой отказа. Если такой узел недоступен, уже запущенные приложения могут продолжить работать, но управление кластером, изменения, новые развертывания и часть автоматического восстановления будут нарушены.

Обычно для отказоустойчивости используют три управляющих узла. Это связано с кворумом: управляющей части нужно большинство участников, чтобы продолжать согласованную работу. Два узла выглядят лучше, чем один, но не дают нормального запаса при потере одного участника, также возможна ситуация split-brain - если нарушена связность между узлами, но при этом они оба продолжают работать. Три узла позволяют пережить отказ одного управляющего сервера без приключений и split-brain.

Минимальные требования из документации kubeadm стоит воспринимать как нижнюю границу для установки, а не как рекомендацию для серьезной эксплуатации. Документация Kubernetes для kubeadm указывает минимум 2 ГБ RAM на машину и минимум 2 CPU для control plane-узлов, но такие значения оставляют мало места для приложений и подходят скорее для небольших или учебных сценариев.

В рабочем кластере control plane-узлам нужны быстрые и надежные системные диски, желательно SSD или NVMe. Особенно важно не размещать etcd на медленных HDD или перегруженном общем хранилище. Память и процессоры должны иметь запас под активность API, операторов, CI/CD, мониторинг, частые изменения объектов и рост числа pod-ов.

На управляющих узлах не стоит запускать тяжелые пользовательские приложения без необходимости. Даже если Kubernetes позволяет снять ограничения и разместить workload на control plane, в production это нужно делать осознанно. Управляющая часть должна оставаться стабильной во время пиков приложений.

Почему etcd требует особого внимания

etcd — один из самых чувствительных компонентов Kubernetes. В нем хранится состояние кластера: сведения о deployments, services, secrets, configmaps, namespaces, pod-ах и других объектах. Если потерять etcd без рабочей резервной копии, можно потерять описание всего кластера.

etcd чувствителен к задержкам диска и сети. Ему нужны быстрые и предсказуемые накопители. Нежелательно размещать его на медленном хранилище, которое одновременно обслуживает тяжелые пользовательские приложения. Также важна низкая задержка между участниками etcd, если их несколько.

Резервные копии etcd должны быть регулярными. Но одного факта создания snapshot недостаточно. Нужно проверять восстановление: в аварийной ситуации важно не только иметь файл, но и понимать, как из него поднять работоспособный control plane. Kubernetes прямо указывает, что все объекты Kubernetes хранятся в etcd, а регулярное резервное копирование etcd нужно для восстановления кластера при авариях, включая потерю всех управляющих узлов.

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

Как считать worker-узлы

Worker-узлы нужно рассчитывать по реальным приложениям, а не по количеству контейнеров. Один контейнер может быть маленьким сервисом, а другой — тяжелой Java-системой, базой данных, аналитической задачей или обработчиком видео. Количество pod-ов само по себе не говорит о нагрузке.

Каждый worker-узел расходует часть ресурсов на системные компоненты: kubelet, среду запуска контейнеров, сетевой плагин, kube-proxy или его альтернативу, агенты мониторинга, логирования, безопасности и иногда storage-агенты. Поэтому нельзя отдавать 100% CPU и RAM приложениям. Нужен резерв на системные службы и пики.

Для приложений желательно задавать requests и limits — запросы и ограничения ресурсов. Без них планировщик хуже понимает, сколько ресурсов реально нужно pod-ам. В результате на один узел могут попасть приложения, которые суммарно требуют больше памяти или процессорного времени, чем сервер способен стабильно дать.

Worker-узлы можно делить по профилям.

Универсальные worker-узлы подходят для веб-сервисов, API, фоновых задач, очередей, легких микросервисов и большинства stateless-приложений. Для них важен баланс CPU и RAM, быстрый системный диск и надежная сеть.

Узлы с большим объемом памяти нужны для приложений, которые потребляют много RAM: Java-сервисы, кеши, аналитика, backend-системы с агрессивным in-memory кэшем. Здесь нельзя считать только ядра. Если памяти не хватает, pod-ы будут вытесняться, перезапускаться или работать нестабильно.

Узлы с быстрым CPU нужны для вычислений, сборок, обработки данных, кодирования, интенсивных API и сервисов, чувствительных к задержке ответа. Для таких нагрузок важны не только количество ядер, но и частота, тепловой режим, запас питания и охлаждение.

GPU-узлы нужны для машинного обучения, инференса, видеообработки или графических задач. Их считают отдельно: по питанию, охлаждению, слотам PCIe, драйверам, совместимости и правилам распределения GPU-ресурсов.

Stateful-узлы используют для приложений с постоянными данными: баз, брокеров сообщений, очередей и хранилищ. Здесь особенно важны диски, задержки, резервное копирование, правила размещения pod-ов и понимание, что произойдет при отказе сервера.

Storage в Kubernetes: что решить до покупки серверов

В Kubernetes постоянные данные обычно работают через PersistentVolume и PersistentVolumeClaim. PersistentVolume — это доступный кластеру том хранения, а PersistentVolumeClaim — заявка приложения на такой том. StorageClass описывает класс хранения: например, быстрый NVMe, обычный SSD, файловое хранилище, реплицированное хранилище или тома с определенной политикой резервного копирования. Kubernetes описывает Persistent Volumes как механизм постоянного хранения, а StorageClass — как способ администратора описывать доступные классы хранения.

До покупки серверов нужно решить, где будут жить данные. Внешняя СХД дает зрелое централизованное управление, понятные уровни отказоустойчивости и привычные процедуры обслуживания. Но она стоит дороже, требует правильной сети и становится отдельной частью архитектуры.

Распределенное хранилище на серверах позволяет использовать локальные диски узлов и масштабироваться горизонтально. Но оно требует быстрой сети, грамотного размещения реплик, мониторинга, запаса по дискам и понимания, как будет проходить восстановление после отказа.

Локальные диски worker-узлов дают хорошую скорость и низкие задержки. Но при отказе узла данные могут стать недоступны, если репликация не настроена на уровне приложения или storage-системы. Этот вариант подходит не всем приложениям.

Файловое хранилище удобно для общих файлов, но не всегда подходит для баз данных и высоких операций ввода-вывода. Нужно проверять задержки, блокировки, права доступа и поведение под нагрузкой.

Какие storage-узлы нужны

Storage-узлы желательно не превращать в обычные worker-серверы, куда попадают любые приложения. Если storage конкурирует с пользовательскими pod-ами за CPU, RAM, диски и сеть, предсказуемость падает. Для production лучше выделить storage-роль явно: отдельными серверами, отдельными дисками, отдельными правилами размещения или внешней системой хранения.

Диски должны быть серверного класса. Для активных баз, очередей, журналов и сервисов с низкой задержкой лучше использовать NVMe. Для менее критичных данных могут подойти SSD. HDD допустимы для холодных данных, архивов и резервных копий, но не как основа активного production-storage с низкой задержкой.

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

Storage потребляет не только диски, но и CPU, RAM и сеть. Распределенная система хранения может активно использовать процессоры для репликации, сжатия, контрольных сумм, восстановления и балансировки данных. При отказе диска или узла начинается rebuild — восстановление реплик. В этот момент растет нагрузка на диски и сеть, поэтому storage-сегмент должен иметь запас.

Роли узлов и требования к серверам

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

Сеть Kubernetes on-premise

Сеть в Kubernetes — одна из самых недооцененных частей on-premise-кластера. Она состоит из нескольких уровней: связь между узлами, сеть pod-ов, сервисная сеть, внешний доступ через ingress или балансировщик, сеть до хранилища, сеть управления, мониторинг и логирование.

Kubernetes использует сетевую модель, в которой каждый pod получает собственный IP-адрес внутри кластера, а pod-сеть обеспечивает связь между pod-ами. Реализация этой модели зависит от сетевого плагина и выбранной схемы адресации.

Для production-кластера 1GbE обычно быстро становится слабым местом. 10GbE можно рассматривать как базовый уровень для рабочих кластеров. Если есть активный storage, интенсивный обмен между сервисами или большие объемы логов и метрик, стоит смотреть в сторону 25GbE и выше. Особенно это важно для распределенного хранилища, где репликация и восстановление данных идут по сети.

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

До покупки серверов и коммутаторов нужно продумать структуру VLAN, MTU, маршрутизацию, DNS, балансировщики, адресные диапазоны pod-ов и сервисов. Сетевой плагин лучше выбирать до проектирования, а не после закупки железа. Если нужны сетевые политики и сегментация приложений, нужно убедиться, что выбранный сетевой слой это поддерживает.

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

Инфраструктурные сервисы внутри кластера

В Kubernetes работают не только бизнес-приложения. Кластеру нужны ingress-контроллеры, внутренний registry для образов, мониторинг, логирование, сбор событий, сервисные операторы, управление сертификатами, секретами и политиками.

Эти компоненты тоже потребляют ресурсы. Мониторинг хранит метрики. Логирование может быстро накапливать большой объем данных. Registry требует дискового пространства и стабильного доступа. Ingress принимает внешний трафик и должен выдерживать пики. Операторы следят за приложениями и создают нагрузку на API-сервер.

Инфраструктурные компоненты лучше не размещать хаотично вместе с пользовательскими приложениями. Для них можно выделить отдельные узлы или хотя бы использовать правила размещения, чтобы мониторинг, ingress и логирование не оказались все на одном сервере. Иначе отказ одного worker-узла может одновременно затронуть внешний доступ, наблюдаемость и часть бизнес-сервисов.

Мониторинг и алерты

Для Kubernetes on-premise недостаточно смотреть, что серверы включены и отвечают по сети. Нужно видеть состояние кластера: API-сервер, etcd, управляющие компоненты, worker-узлы, pod-ы, storage, ingress, сеть, сертификаты, резервные копии и обновления.

По control plane важно отслеживать доступность API-сервера, состояние etcd, задержки etcd, ошибки управляющих компонентов и частоту запросов. По worker-узлам — CPU, RAM, диски, сеть, давление по памяти и диску, частые перезапуски контейнеров, вытеснение pod-ов. По storage — заполнение томов, задержки дисков, ошибки репликации, состояние реплик, скорость восстановления и приближение к лимитам.

Отдельно нужно мониторить PersistentVolume и заявки на хранилище. Если том заполнился, приложение может прекратить работу или повредить данные, что может быть даже худшим вариантом. Если задержки storage растут, проблема может выглядеть как «медленное приложение», хотя причина находится уровнем ниже.

Мониторинг должен жить так, чтобы не исчезать первым при аварии. Если вся наблюдаемость зависит от того же storage или тех же worker-узлов, которые упали, диагностика станет сложнее. Для критичных кластеров стоит продумать внешний сбор метрик, отдельное хранение логов или хотя бы устойчивое размещение компонентов мониторинга.

Резервирование и отказоустойчивость

Kubernetes-кластер нужно считать не только для нормального режима, но и для отказа или обслуживания. Минимальное рабочее правило: кластер должен выдерживать режим N-1, когда один сервер недоступен. Это может быть авария, плановое обновление, замена диска, проблема с питанием или обслуживание стойки.

Control plane должен переживать отказ одного управляющего узла. Worker-узлы должны иметь достаточно свободных ресурсов, чтобы приложения переехали после сбоя. Storage должен иметь репликацию или внешнюю отказоустойчивость. Ingress и балансировщики не должны существовать в одном экземпляре. Сетевые коммутаторы, uplink-каналы и питание тоже являются частью отказоустойчивости, а не «внешними деталями».

Если кластер из трёх узлов в обычном режиме загружен на 90%, он не сможет безопасно пережить отказ узла. При первой аварии pod-ам некуда будет переехать, обновления станут рискованными, а storage-система может начать восстановление на перегруженных дисках и сети. Поэтому запас ресурсов — это не роскошь, а часть архитектуры.

Резервные копии etcd и резервные копии данных приложений — разные задачи. Backup etcd помогает восстановить состояние кластера. Backup базы данных или файлового хранилища помогает восстановить данные приложения. Одно не заменяет другое.

Обновления кластера

Kubernetes нужно регулярно обновлять. Но обновляется не только сам Kubernetes. В on-premise-кластере есть операционная система, среда запуска контейнеров, сетевой плагин, storage-драйверы, ingress, мониторинг, логирование, firmware серверов, драйверы сетевых карт и иногда драйверы GPU.

Если кластер рассчитан без запаса, каждое обновление превращается в риск. Чтобы обновить worker-узел, его нужно вывести из работы, перенести pod-ы на другие узлы и вернуть сервер обратно. Если свободной емкости нет, обновление либо остановит часть приложений, либо будет откладываться до аварийного момента.

Control plane обновляют поэтапно. Worker-узлы тоже лучше обновлять партиями, а не все сразу. Storage-компоненты требуют отдельного окна и проверки репликации. Перед обновлением нужны резервные копии и план отката. После обновления — проверка состояния pod-ов, ingress, persistent volumes, сетевых политик и мониторинга.

Хорошая архитектура позволяет обслуживать кластер без полного простоя. Плохая архитектура работает только до первого обновления.

Пример малого кластера

Для лаборатории или небольшого production-кластера можно начать с трех серверов. В такой схеме роли иногда совмещают: каждый узел может быть и частью control plane, и worker-узлом. Это экономит оборудование, но требует понимания ограничений.

На каждом сервере желательно иметь быстрые SSD или NVMe, достаточный объем RAM, два сетевых порта или больше, 10GbE для production-сценария и отдельное резервное копирование вне кластера. Если используются локальные диски для storage, нужно понимать, как данные переживут отказ узла.

Такая схема подходит для небольших сервисов, разработки, внутренних инструментов, CI/CD и умеренных нагрузок. Но она плохо подходит для тяжелых баз данных, строгих требований к доступности, активной аналитики или быстрого роста. Главное — не считать три сервера универсальным ответом на все задачи.

Пример среднего production-кластера

Для среднего production-кластера лучше разделить роли. Типовая схема может включать три выделенных control plane-узла, несколько worker-узлов для приложений и отдельную storage-систему или выделенные storage-узлы. Worker-узлов может быть три, шесть или больше — в зависимости от нагрузки и требований к запасу.

Ingress можно разместить на отдельных инфраструктурных узлах или на worker-узлах с правилами антиаффинности, чтобы несколько экземпляров не оказались на одном сервере. Мониторинг и логирование тоже нужно разместить устойчиво. Сеть — минимум 10GbE, а при активном storage или большом внутреннем трафике лучше 25GbE.

Такой кластер уже нельзя строить как «три одинаковых сервера и потом настроим». Нужно заранее понимать, где будет control plane, где будут приложения, где будут данные, как выполняются обновления и что произойдет при потере одного узла.

Пример кластера с высокой нагрузкой

Кластер с высокой нагрузкой проектируют под конкретные приложения. В нем обычно есть выделенный control plane, несколько групп worker-узлов под разные типы нагрузки, отдельные storage-узлы или внешняя СХД, резервированные балансировщики, отдельные сети управления, приложений и хранения.

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

Для таких кластеров не существует универсальной спецификации. Два проекта с одинаковым числом pod-ов могут требовать совершенно разного железа: один будет упираться в RAM, другой — в диски, третий — в сеть, четвертый — в GPU.

Типовые конфигурации Kubernetes on-premise

Частые ошибки при выборе серверов

1. Ставить все роли на один сервер и считать это Kubernetes-кластером. Для обучения такая схема допустима, но для production она не дает отказоустойчивости.
2. Делать два control plane-узла и считать управляющую часть надежной. Для нормального кворума обычно нужна нечетная схема, чаще три узла.
3. Использовать медленные диски под etcd. Управляющая часть может начать тормозить не из-за CPU, а из-за задержек хранения.
4. Забывать про storage при расчете. Приложения запускаются быстро, а проблемы начинаются, когда появляются базы данных, очереди, persistent volumes и восстановление после отказа.
5. Считать только CPU и RAM, игнорируя сеть. В Kubernetes много внутреннего трафика: сервисы общаются друг с другом, storage реплицируется, логи и метрики постоянно передаются.
6. Использовать 1GbE для активного storage. Для небольшого теста это может работать, но в production быстро становится ограничением.
7. Не оставлять запас на отказ узла. Если все ресурсы заняты в обычном режиме, при аварии приложениям некуда переехать.
8. Не учитывать ingress, мониторинг, логирование и registry. Эти компоненты не являются бизнес-приложениями, но без них кластер не будет полноценной платформой.
9. Не задавать requests и limits. Без них планировщик не понимает реальную потребность приложений в ресурсах.
10. Не делать backup etcd и не проверять восстановление. Резервная копия, которую ни разу не восстанавливали, не считается работоспособной.
11. Покупать серверы без учета роста. Kubernetes часто начинается с нескольких сервисов, а затем становится основной платформой. Если не заложить расширение, через год придется перестраивать архитектуру.

Как выбрать серверы перед покупкой

Сначала нужно описать приложения. Какие сервисы будут работать в кластере, сколько им нужно CPU и RAM, есть ли базы данных, очереди, файлы, аналитика, ML, GPU, большие объемы логов. Затем нагрузки нужно разделить на stateless и stateful. Первые проще переносить между узлами. Вторые требуют внимательного storage и резервного копирования.

После этого выбирают схему control plane. Для production лучше планировать три управляющих узла. Затем считают worker-узлы с учетом системных компонентов, requests/limits, пиков и режима N-1. Потом отдельно проектируют storage: внешний, распределенный, локальный или смешанный.

Сеть нужно выбирать до покупки серверов и коммутаторов. Для production 10GbE — разумная база, для активного storage и высокого внутреннего трафика лучше закладывать 25GbE. Нужно проверить количество портов, резервирование, поддержку нужных модулей, VLAN, MTU и схему подключения.

Отдельно закладываются ingress, балансировщики, мониторинг, логирование, registry, backup и обновления. Также нужно проверить стойку, питание, охлаждение и свободные порты коммутаторов. Серверы могут быть подходящими по характеристикам, но неподходящими для площадки, если не хватает питания, места или сетевой емкости.

Покупать железо до архитектурного расчета рискованно. В итоге может оказаться, что CPU достаточно, но storage слабый; памяти много, но сеть узкая; серверы мощные, но обновлять их без простоя невозможно.

Что в итоге нужно заложить

Для Kubernetes on-premise нужны не просто серверы под контейнеры, а продуманная платформа. Control plane отвечает за управление и должен быть стабильным, резервированным и защищенным. Worker-узлы должны соответствовать профилю приложений: универсальные сервисы, память, CPU, GPU и stateful-нагрузки требуют разных конфигураций. Storage нужно проектировать отдельно, потому что от него зависят данные, восстановление и производительность.

Сеть, мониторинг, резервные копии и обновления — такие же обязательные части архитектуры, как процессоры и память. Хороший кластер должен не только запускаться в первый день, но и переживать отказ узла, обновление, рост нагрузки и восстановление после аварии. Чем раньше эти вопросы учтены, тем меньше риск получить систему, которая формально работает, но плохо выдерживает реальные нагрузки и обслуживание.