Серверы для Kubernetes on-prem: память, NVMe, сеть, ядра

Какие узкие места чаще всего всплывают после запуска

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

Пилот обычно короткий и аккуратный: меньше данных и интеграций, редкие деплои, нет пиковых периодов (отчетность, закрытие месяца, массовые рассылки). В продакшене микросервисы легко создают непредсказуемые всплески. Один сервис замедлился, очередь выросла, ретраи умножили нагрузку, и дальше цепочка разъезжается по всему кластеру.

Чаще всего очереди и задержки упираются в четыре зоны:

• CPU: лимиты выставлены «на глаз», планировщик упирается в нехватку ядер, а соседние поды начинают мешать друг другу на пиках.
• Память: OOM-kill, частые рестарты, выселение подов и потеря кэшей. Проблема часто не в среднем потреблении, а в коротких всплесках.
• Диски: тормозят операции с контейнерными слоями, логами, базами и очередями. IOPS заканчиваются раньше, чем место.
• Сеть: узкие места на east-west трафике между сервисами, нехватка пропускной способности для storage и бэкапов, рост задержки из-за перегруженных коммутаторов.

Простой пример: вы подключили трассировку и увеличили retention метрик. Запись на диск резко выросла, а параллельно в часы пик усилился межсервисный трафик. В итоге «проседает» не один компонент, а сразу несколько. Поэтому серверы для Kubernetes on-prem стоит выбирать с запасом по самым чувствительным ресурсам и с пониманием, что нагрузка в кластере почти никогда не бывает ровной.

Опишите нагрузку перед выбором железа

Железо под кластер часто выбирают «на глаз», а потом удивляются: то не хватает памяти, то диски «упираются», то сеть забита служебным трафиком. Чтобы серверы для Kubernetes on-prem не стали проблемой через месяц после запуска, начните с описания нагрузки простыми словами, как для человека, который будет это поддерживать.

Сначала перечислите, что именно вы запускаете и где. Количество микросервисов само по себе мало что говорит: важнее число окружений (prod, stage, dev) и их похожесть. Частая ситуация: staging «почти как prod», но живет на тех же узлах, и во время нагрузочного теста начинает вытеснять рабочие поды.

Дальше отметьте stateful части. Базы данных, очереди, хранилища логов, мониторинг и трассировка обычно создают постоянный I/O и чувствительны к задержкам. Если они будут внутри кластера, требования к дискам и сети резко растут. Если снаружи, вы переносите риски в сеть и внешнее хранилище.

Полезно зафиксировать это как короткое «почти ТЗ»:

• сколько сервисов и окружений вы поддерживаете сейчас и что планируется через год;
• что у вас stateful, а что stateless;
• какой профиль нагрузки преобладает (CPU, память, диски);
• какие SLO важнее всего (задержка запросов, время деплоя, скорость восстановления);
• ожидаемый рост на 12-24 месяца (пользователи, трафик, данные).

Пример: 40 сервисов в prod и 40 в stage, внутри кластера Prometheus и Loki, база вынесена наружу. Тогда узкие места чаще всего будут в памяти (метрики и кэши), в I/O для логов и в сети между нодами во время раскатки.

Память на узел: как не попасть в OOM и выселение подов

В Kubernetes память обычно заканчивается раньше CPU. Процессор можно «поджать» лимитами, и планировщик распределит нагрузку. А вот память при реальном перерасходе приводит к OOMKilled или к eviction (выселению) подов. Дальше они переезжают на другие узлы и запускают лавину проблем.

Частая ловушка: считать RAM по сумме requests, хотя фактическое потребление ближе к limits (или вообще безлимитное, если limits не заданы). Плюс есть память, которую кластер забирает себе. Node Allocatable всегда меньше «RAM в сервере». Поэтому один и тот же узел на 256 ГБ может оказаться «полезным» только на 200-220 ГБ, в зависимости от настроек и нагрузки.

Думайте о памяти как о трех слоях: приложения, системные компоненты (kubelet, контейнерный runtime, CNI) и сервисы вокруг (логирование, мониторинг, агенты безопасности). Даже если они по отдельности «маленькие», в сумме это заметно. И растет вместе с кластером.

На двухсокетных серверах появляется нюанс NUMA: память физически привязана к сокету. Если podу нужно много RAM и CPU, но NUMA-политику не учли, можно получить задержки и нестабильную производительность, хотя «по цифрам» памяти вроде хватает.

Практические правила перед закупкой:

• держите постоянный запас 15-30% RAM под систему и пики;
• задайте requests и разумные limits для всех важных сервисов;
• отдельно учитывайте кэши, очереди и JVM/Go heap (они часто растут неожиданно);
• для крупных stateful компонентов планируйте узлы с большим RAM, а для множества мелких сервисов часто выгоднее больше узлов поменьше.

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

CPU и запас по ядрам: планировщик любит предсказуемость

CPU в Kubernetes - это не только «сколько ядер». Важно, насколько предсказуемо они доступны подам. При выборе серверов для Kubernetes on-prem закладывайте запас не «на сейчас», а на пики, фоновые задачи и рост.

Самая частая ошибка - агрессивный oversubscription, когда лимиты CPU сильно выше реальных ресурсов узла. На графиках средняя загрузка может выглядеть красиво, но в момент пика начинается борьба за процессорное время. Итог - рост задержек, скачки latency у API, таймауты и цепная реакция повторов запросов, которая добивает кластер.

Когда важнее частота, а когда количество ядер? Для сервисов с короткими запросами и строгими SLO (gateway, авторизация, онлайн-платежи) часто выигрывает более высокая частота и стабильная производительность на ядро. Для параллельных задач (очереди, фоновые воркеры, batch, CI) важнее больше ядер и понятная политика лимитов.

Хорошая практика - выделить отдельные узлы под инфраструктуру кластера. Тогда CPU не «съедают» те, кого вы не видите в бизнес-метриках: DNS, ingress-контроллеры, логирование, мониторинг, service mesh, контроллеры хранения.

Что стоит проверить заранее: какой запас по CPU нужен, какой oversubscription допустим без лотереи с задержками, как влияет SMT/Hyper-Threading на ваш профиль нагрузки, и нужен ли пул инфраструктурных узлов хотя бы минимального размера.

Простой ориентир: если после запуска сервисы «вроде живы», но хвосты по задержкам растут в часы нагрузки, чаще всего это не «баги», а нехватка предсказуемого CPU и слишком смелые лимиты.

NVMe и диски: где реально нужна высокая скорость

Для микросервисов важны не только «цифры IOPS», но и задержка. IOPS показывает, сколько операций в секунду выдержит диск, а задержка - как быстро каждая операция завершается. Для Kubernetes обычно критичнее низкая задержка: много мелких запросов (метаданные, журналы, небольшие записи) чувствительны к «подвисаниям», даже если средние IOPS выглядят неплохо.

NVMe имеет смысл там, где узкое место - случайный доступ и быстрое подтверждение записи. Чаще всего это etcd (если control plane не вынесен и вы уверены в схеме отказоустойчивости), горячие части баз данных и очередей, поисковые индексы, буферы логов и метрик, а также кэши CI (артефакты, слои контейнеров, зависимости).

Компромисс между локальным NVMe и внешним хранилищем простой. Локальный NVMe быстрее по задержке и обычно дешевле «в ощущениях», но сложнее с сохранностью данных на уровне узла: диск умер - данные на узле пропали. Внешнее хранилище проще защищать и масштабировать, но оно добавляет сеть и задержку и может стать новым узким местом.

RAID тоже не «бесплатный». Контроллер и его кэш могут ограничить скорость, особенно на NVMe, где сам диск быстрее контроллера. Поэтому схемы для локальных NVMe лучше выбирать осознанно и проверять под реальной нагрузкой.

Не забывайте про ресурс дисков (TBW) и план замены без простоя: мониторинг износа, запасные диски и понятный сценарий пересоздания подов и переноса данных.

Сеть: пропускная способность, задержка и резервирование

В Kubernetes сеть редко бывает «просто сетью». После запуска быстро растет east-west трафик: сервисы общаются друг с другом, sidecar-прокси в сервис-меше добавляют обмен, а наблюдаемость (логи, метрики, трассировки) постоянно отправляет данные. Внешняя нагрузка может выглядеть умеренной, а внутренняя сеть уже на пределе.

Выбор 10/25/100GbE лучше привязывать не к «сколько сейчас», а к тому, как кластер будет жить через год. 10GbE часто хватает для небольших кластеров без тяжелого сервис-меша и с умеренной репликацией данных. 25GbE обычно дает хороший баланс для микросервисных платформ. 100GbE имеет смысл, когда много узлов, интенсивные CI/CD, большие объемы данных, распределенные хранилища или сеть уже становится главным ограничением.

Важно сразу посчитать порты. Частая ошибка: взять «быструю» сетевую карту, но с одним портом и без разделения потоков. Практичный минимум для узла - два порта для отказоустойчивости, плюс отдельные сегменты (через VLAN или физически), если вы разводите storage/репликацию и управление.

MTU и jumbo frames помогают только когда сеть и оборудование настроены одинаково на всем пути. Если хотя бы один сегмент не поддерживает выбранный MTU, получите «плавающие» проблемы, которые сложно ловить. Меняйте MTU осознанно и проверяйте end-to-end.

Для отказоустойчивости на узлах обычно используют bonding с LACP, а на уровне коммутаторов - разнесение по двум устройствам. Это особенно важно в on-prem, где один сетевой элемент легко превращается в узкое горлышко.

Надежность кластера: контрольная плоскость и запас емкости

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

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

Где хранить etcd и почему важна задержка

etcd чувствителен не к объему диска, а к задержке и стабильности I/O. Даже при умеренной нагрузке медленные или «плавающие» диски дают задержки на записи, а это отражается на всей контрольной плоскости. Обычно лучший вариант - локальные быстрые диски с низкой задержкой на узлах control-plane. Важно не гнаться за скоростью на бумаге, а добиваться предсказуемости.

Запас емкости: что останется после отказа

Планируйте кластер так, будто одна нода уже потеряна. Для критичных платформ часто закладывают сценарий «минус 1-2 узла» (перезагрузка, обновление, авария).

Проверьте несколько вещей: хватит ли CPU и памяти, если один worker недоступен; останется ли место под переселение подов без OOM и сильного throttling; выдержат ли хранилище и сеть всплеск трафика при миграции; сможете ли обновлять ноды по очереди без простоя.

Есть и «железные» риски, которые легко пропустить. Плохое охлаждение вызывает троттлинг CPU: формально ядра есть, но они не дают ожидаемую производительность. Питание тоже важно: резервирование блоков питания в серверах и коммутаторах плюс раздельные линии питания заметно снижают вероятность внезапного простоя.

Пример: в микросервисной платформе для банка вы обновляете worker-узлы ночью по одному. Если запас рассчитан «впритык», то уже на втором узле начнутся очереди, рост задержек и падение SLO. С запасом кластер переживет обновление так же спокойно, как и реальный отказ.

План обновлений и роста: чтобы железо не устарело раньше времени

On-prem Kubernetes редко живет «как поставили». Через 6-12 месяцев появляются новые версии кластера, меняются требования безопасности, растет число сервисов. И внезапно выясняется, что уперлись не в CPU, а в сеть, порты или адреса.

Зафиксируйте календарь обновлений Kubernetes и совместимость зависимостей. Обновляется не только Kubernetes, но и container runtime, CNI (сеть), CSI (хранилище), драйверы, прошивки и ОС. Если один компонент «отстает», обновление кластера превращается в риск.

Практика, которая обычно работает: rolling update узлов через cordon/drain и короткие окна изменений. Узел выводят из планирования, переселяют поды, обновляют ОС и компоненты, возвращают в пул. Так проблемы проявляются по одному узлу, а не разом.

Чтобы заранее понять, не упрется ли новый релиз в ресурсы, держите простой порядок проверки: прогон в тестовом кластере или на отдельном пуле, сравнение фактических пиков CPU и RAM с requests/limits, проверка диска (IOPS и p99 задержка) и сетевого запаса (east-west трафик, p95 задержки, ошибки), плюс оценка того, выдержат ли мониторинг и логи рост ретеншна.

План расширения лучше записать в виде правил. Например: добавляем узлы при 60-70% устойчивой загрузки пула, а замену поколения планируем раз в 3-5 лет с «перекрытием», чтобы старые и новые серверы некоторое время работали вместе.

Не забывайте про физику и адресацию: место в стойках, питание, свободные порты на коммутаторах, запас по 25/100GbE, IP и адресные пространства Pod/Service. На практике именно они чаще тормозят рост быстрее, чем выбор между NVMe и SATA.

Как подобрать конфигурацию: простой пошаговый подход

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

Соберите исходные данные по каждому окружению (dev, stage, prod) и по ключевым сервисам: сколько реплик, есть ли очереди и кэш, какое логирование и мониторинг. Прикиньте requests и limits, но опирайтесь на измерения, а не на ожидания.

Дальше помогает короткий чеклист:

• сведите общий бюджет ресурсов (CPU, RAM, диск по задержке и IOPS, сеть внутри кластера и к хранилищу) по окружениям;
• разделите ноды на 2-3 типа (универсальные, CPU-ориентированные, RAM-ориентированные), а storage-ноды выделяйте только если действительно нужны NVMe и высокие IOPS;
• продумайте сеть и резервирование (два порта на ноду, два коммутатора, понятная схема отказа, сегментация для storage при необходимости);
• заложите запас и правило N-1: кластер должен продолжать работать при потере одного узла;
• определите план расширения: как быстро вы сможете добавить ноды и как будете переходить на более быструю сеть, если трафик вырастет.

Так вы избегаете ситуации, когда серверы для Kubernetes on-prem куплены «впритык», а через 2-3 месяца вы упираетесь в OOM, очереди на диске или перегруз сети.

Что протестировать до закупки

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

Пример сценария: on-prem платформа микросервисов для компании

Представим компанию, у которой 50-80 микросервисов, ежедневные релизы через CI/CD, плюс обязательные мониторинг, логирование и трассировка. Все это живет on-prem, потому что важны контроль данных и предсказуемая стоимость.

Такой кластер удобно разделить на пулы по роли: инфраструктура (ingress, DNS, метрики, логирование, CI runners), stateless (основная масса сервисов и воркеры) и stateful (базы, очереди, кэш, хранилища).

Где реально нужен NVMe: на stateful-узлах и на узлах под тяжелое логирование, индексацию и хранение метрик. Там важны не только мегабайты в секунду, но и низкая задержка при большом количестве мелких операций. Для stateless-пула часто хватает качественных SSD: сервисы в основном упираются в CPU и память, а диск нужен для образов и временных файлов.

Если межсервисный трафик активный (много запросов между микросервисами, сервис-меш, частые деплои), сеть быстро становится ограничением. На практике минимумом часто оказывается 25GbE на узел, а для плотных кластеров имеет смысл закладывать более быстрые аплинки и резервирование по двум сетевым путям.

Запас емкости считайте так, чтобы пережить выход одного узла без паники: держите N+1 по мощности в каждом пуле и не забивайте узлы «впритык». Например, если на stateless-пуле нужно 120 vCPU по запросам, планируйте так, чтобы при потере одного сервера оставалось хотя бы 120 vCPU, а не 90.

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

Главная проблема с железом под Kubernetes в том, что ошибки проявляются не на этапе закупки, а через пару месяцев, когда добавляются новые сервисы и растет трафик. И тогда «падает» не один компонент, а предсказуемость кластера: планировщик начинает переселять поды, растут задержки, а обновления превращаются в ночной марафон.

Одна из частых ловушек - купить много CPU и сэкономить на памяти. В итоге requests выставлены «на глаз», контейнеры ловят OOM, а узлы перегреваются по RAM задолго до загрузки по ядрам. Для серверов под Kubernetes on-prem почти всегда важнее сбалансировать CPU и память, чем гнаться за частотой.

Еще несколько ошибок, которые встречаются регулярно: ставят NVMe «везде», хотя быстрый диск нужен точечно; оставляют 10GbE и удивляются росту east-west трафика; смешивают control-plane и тяжелые ворклоады на одних узлах; не закладывают запас под drain и ремонт, из-за чего обновления требуют простоя; игнорируют питание, охлаждение и лимиты стойки, и реальная конфигурация «не помещается» в дата-центр.

Простой пример: компания запускает on-prem платформу с CI, мониторингом и несколькими API. Через 3 месяца добавляет аналитический сервис и больше логов. Если сеть осталась 10GbE и нет запаса по памяти, начнутся таймауты и выселение подов, хотя «по CPU все еще свободно».

Короткий чеклист и следующие шаги

Перед закупкой железа полезно на одной странице зафиксировать, что для кластера важнее всего: запас по CPU под пики и обновления, запас по RAM под рабочие наборы данных и всплески, понятная схема дисков (где нужны NVMe, а где достаточно SSD), сеть с резервированием и план роста с учетом N-1.

Чтобы серверы не «разошлись» с реальной нагрузкой, заранее уточните у команды разработки: какие сервисы stateful, какие критичны к задержке, какой ожидается RPS и рост, какой размер образов и частота деплоев, какие SLO по времени ответа.

Дальше проверьте гипотезы на пилотном узле или небольшом стенде. Достаточно нескольких тестов: где начинается троттлинг CPU и OOM, как выглядит p99 задержка диска под профиль БД или очереди, что происходит с сетью east-west (задержка, потери, поведение при отказе одного линка), и сколько времени занимает drain узла и восстановление.

План обновлений на год вперед лучше оформить как календарь: квартальные обновления Kubernetes и базовых аддонов, окна для прошивок/BIOS и точка пересмотра емкости (например, раз в полгода).

Если вы хотите упростить этап подбора и дальнейшего сопровождения, имеет смысл обсуждать конфигурации и план расширения с интегратором, который закрывает и поставку, и поддержку. Например, GSE.kz (gse.kz) в Казахстане производит серверы S200 и предоставляет 24/7 техническую поддержку, что удобно, когда важны быстрые замены компонентов и единый контур ответственности.