За последний год серверное оборудование в России подорожало более чем вдвое, а облачные услуги — на
Сколько мощностей действительно нужно
В России облачные тарифы пока растут медленнее стоимости серверного оборудования. Как отмечал в комментарии для ComNews президент Ассоциации участников отрасли ЦОД Игорь Дорофеев, их рост сдерживают конкуренция, ограниченный платежеспособный спрос и то, что провайдеры продолжают использовать оборудование, закупленное до резкого роста цен на серверы. Генеральный директор Selectel Олег Любимов, выступая в октябре на конференции компании «ТехноДень», говорил, что пока выгоднее брать мощности в аренду у облачных провайдеров, чем закупать и запускать собственное оборудование, но по мере роста цен ситуация изменится. И в облаке, и в своем дата-центре вопрос один: сколько ресурсов действительно нужно.
Этим вопросом в первую очередь заняты специалисты по управлению облачными расходами. Согласно исследованию State of FinOps 2026, оптимизация нагрузок остается для них главной задачей, но крупные и очевидные потери во многих компаниях уже найдены, а оставшиеся искать труднее. Часть из них прячется в настройках Kubernetes-кластеров.
Почему кластер «заканчивается» раньше времени
Kubernetes распределяет приложения по серверам кластера (узлам) с учетом заданных для них запросов на ресурсы (requests). Если приложению заранее задали завышенные запросы на CPU или память, Kubernetes при размещении новых сервисов считает соответствующую часть ресурсов узла уже распределенной, даже если фактическое потребление значительно ниже.
По данным Cast AI, коммерческого разработчика решений для оптимизации Kubernetes, в изученных компанией кластерах на AWS, Azure и Google Cloud средняя загрузка процессоров составляла 8 %, памяти — 20 %, графических ускорителей при выполнении задач ИИ и машинного обучения — около 5 %. Речь идет о зарубежной выборке и кластерах до автоматической оптимизации. Цифры показывают значительный разрыв между доступными и фактически используемыми мощностями, хотя не все свободные ресурсы избыточны.
Как завышенные запросы выглядят на практике, видно по опыту DevOps-инженера Наиля Ярмухаметова. Он около десяти лет работает с ИТ-инфраструктурой и разработал BeaverDeck — веб-панель с открытым исходным кодом для управления Kubernetes-кластерами. На одном из его проектов сервису выделили 500m CPU, то есть половину процессорного ядра, хотя даже на пике он потреблял не больше 100m. Ярмухаметов сравнил запросы с фактическим потреблением, включая пиковые значения из системы мониторинга Prometheus, и скорректировал завышенные значения.
Возможный эффект такой оптимизации инженер иллюстрирует упрощенным расчетом. Допустим, сервис работает в 30 экземплярах, а каждый сервер имеет два процессорных ядра и 8 ГБ оперативной памяти. При запросе 500m CPU на одном сервере можно разместить не более четырех экземпляров. С учетом ресурсов, необходимых для работы самой системы, потребуется десять серверов. Если снизить запрос до 100m, по процессорной мощности хватило бы двух серверов. Однако ограничением становится оперативная память: каждый экземпляр потребляет около 0,5 ГБ. Если учесть системный резерв памяти, для 30 экземпляров потребуются три сервера. Запрос CPU при этом снижается в пять раз, а расчетное число серверов — лишь втрое: стоит убрать одно узкое место, как обнаруживается следующее.
«Работает — не трогай»
Почему такие настройки не всегда своевременно пересматривают, Ярмухаметов объясняет двумя причинами. Первая — давление бизнеса.
«Результат часто нужен „вчера“, и времени на анализ использования ресурсов просто нет. Добавить еще один сервер значительно быстрее, чем разбираться, почему существующих мощностей не хватает. Забавно, но при этом тот же бизнес требует сокращения расходов на инфраструктуру», — говорит он.
Вторая причина — нехватка опыта у инженеров или нежелание брать на себя ответственность за оптимизацию.
«Работает — не трогай. За конкретный сбой отвечает конкретный инженер, а за избыточные расходы на инфраструктуру обычно никто персонально не отвечает», — объясняет Ярмухаметов.
Сам он пересматривает настройки своих кластеров не реже раза в квартал. Ошибиться в расчете нагрузки, по его словам, нормально, ошибка — не перепроверять. Потребление со временем меняется, и вчерашние настройки сегодня могут оказаться избыточными или, наоборот, недостаточными.
Оптимизация не всегда означает экономию
Неэффективное распределение ресурсов не всегда приводит к лишним расходам. Иногда оно создает проблемы с устойчивостью работы приложений. Например, на одном из проектов Ярмухаметова ресурсоемкий медиасервис генерировал и конвертировал изображения, аудио и видео. Для него использовали сервер с 64 ГБ оперативной памяти. Обычно сервис потреблял около 12 ГБ, но в пиковые моменты потребление значительно возрастало. Из-за этого приходилось оставлять значительный запас памяти для других приложений.
По оценке Ярмухаметова, значительную часть используемой памяти занимал файловый кэш, который Linux при необходимости может освобождать, а жесткие ограничения по памяти для контейнера мешали эффективно использовать этот механизм.В результате сервис перенесли на отдельный узел с 32 ГБ оперативной памяти без жесткого лимита на ее потребление, а остальные приложения распределили по менее мощным серверам.Отказ от лимита — решение для конкретного случая, а не универсальный рецепт: на общем узле приложение без ограничения памяти может вытеснить соседей.
Производительность сервиса не пострадала, соседние приложения стали работать стабильнее, потому что больше не конкурировали с ним за ресурсы, а стоимость инфраструктуры почти не изменилась.
Другой случай — приложения, которые нужны редко. На проекте Ярмухаметова они постоянно работали на общих серверах и резервировали ресурсы даже в простое. Инженер вынес их на отдельную группу узлов и связал два инструмента: KEDA уменьшает число экземпляров приложения до нуля, когда нет нагрузки, а Cluster Autoscaler сокращает число узлов в группе, когда они больше не нужны. При появлении нагрузки система автоматически запускает приложения и при необходимости увеличивает число узлов. В итоге в простое не работают ни сами приложения, ни выделенные для них серверы.
Похожий механизм есть и в самом Kubernetes: в версии 1.37 масштабирование до нуля через Horizontal Pod Autoscaler (HPA) перешло в стадию бета и стало доступно по умолчанию. Но для этого HPA должен опираться на внешние показатели, например на длину очереди задач: загрузка CPU и памяти здесь не подходит. Кроме того, запуск после простоя занимает время, особенно если сначала нужно поднять новый узел, поэтому такой подход годится не для всех сервисов.
GPU: дорогие и дефицитные
С графическими ускорителями цена неэффективности особенно высока: как говорил на той же конференции «ТехноДень» Любимов из Selectel, серверы для запуска современных нейросетей в России стоят от $1 млн.
К высокой цене добавляется дефицит: чаще всего, по словам Ярмухаметова, он сталкивается с нехваткой GPU. Даже в облаках получить квоту на популярные карты NVIDIA A100 бывает сложно, а иногда невозможно. Поэтому важно правильно распределять те ускорители, которые уже есть. Однако по умолчанию Kubernetes выделяет приложению ускоритель целиком, даже если для работы хватило бы его части. Ярмухаметов в таких случаях использует технологию NVIDIA MIG: она делит совместимый GPU по заранее заданным профилям на несколько изолированных частей для разных сервисов. Правда, подходит она не для всех задач.
Еще одна проблема — фрагментация. В одном из проектов свободных GPU-ресурсов в кластере в сумме хватало, но они оказались разбросаны так, что Kubernetes не мог разместить приложение. Проблему выявила проверка GPU Fragmentation в панели Ярмухаметова. Он перераспределил имеющиеся ресурсы и, по его словам, избежал дополнительных расходов на $10 тыс. Однако решить проблему таким способом удается не всегда.
Как искать скрытые резервы и риски
Начинать стоит с мониторинга: он позволяет оценить фактическую нагрузку, включая пиковые значения. Но одних графиков недостаточно: нужно проверять и настройки приложений. Среди типичных проблем — отсутствующие или некорректно заданные запросы и лимиты; неиспользуемые тома, за хранение которых продолжают платить; сетевые настройки со ссылками на уже несуществующие объекты; постоянно перезапускающиеся контейнеры; избыточные права доступа.
Часть этой работы можно автоматизировать. Именно для таких ревизий Ярмухаметов и создавал BeaverDeck: в разных проектах он раз за разом сталкивался с одними и теми же проблемами. Панель объединяет повседневные операции с ресурсами кластера и автоматическую диагностику. По состоянию на конец октября 2026 года в опубликованной версии доступны 37 проверок по семи направлениям: серверы кластера, приложения, GPU, сеть, хранилища, безопасность и конфигурация. Количество проверок продолжает расти.
Одни проверки находят неиспользуемые тома и контейнеры, которые многократно перезапускаются, другие — например, GPU Node Workload Mix — выявляют приложения, не использующие GPU, но занимающие ресурсы дорогих GPU-узлов. Проверка лишь указывает на возможную проблему. Дальше инженер изучает настройки, события и логи и решает, что исправлять. Проверки не заменяют полноценный мониторинг. В частности, фактическую загрузку GPU панель пока не измеряет: 11 из 37 проверок относятся к GPU и оценивают выделение и размещение ускорителей, квоты и состояние приложений, которым нужны GPU.
По словам Ярмухаметова, BeaverDeck уже используют в нескольких проектах, в том числе в сферах искусственного интеллекта, электронной коммерции и финансовых технологий, а точное число пользователей назвать сложно: панель распространяется с открытым исходным кодом и пока устанавливается без регистрации у разработчика.
Отдельная задача — права доступа. С трудностями при их выдаче Ярмухаметов сталкивался сам: доступ для разработчика приходится настраивать непосредственно в кластере, а в облаке иногда еще и согласовывать с провайдером. Веб-панели упрощают эту работу, но добавляют второй уровень прав. В BeaverDeck пользователю можно разрешить доступ к определенным пространствам имен, ресурсам и операциям: например, позволить просматривать логи и перезапускать приложения, но запретить удаление и доступ к секретам. По словам разработчика, для некоторых ресурсов предусмотрен отдельный уровень, позволяющий видеть только список объектов без доступа к их содержимому.
При этом сам BeaverDeck работает с широкими полномочиями в кластере, необходимыми для управления разными типами ресурсов. Администратор может ограничить эти полномочия средствами Kubernetes, но тогда часть функций панели станет недоступна. По словам Ярмухаметова, запросы через API панели проходят те же проверки прав, что и действия в веб-интерфейсе.
Когда без новых серверов не обойтись
Оптимизация требует осторожности: если слишком сильно сократить выделенные ресурсы, приложения могут замедлиться или начать сбоить. Кроме того, часть мощностей должна оставаться в резерве на пиковые нагрузки и на случай отказа оборудования. Порядок действий такой: измерить обычную и пиковую нагрузку, проверить запросы и лимиты, найти ненужные ресурсы, устранить ошибки и оценить результат изменений. Если ресурсов с учетом резерва по-прежнему не хватает, кластер действительно пора расширять.
Как именно расширять кластер, зависит от того, где он размещен. В облаке, отмечает Ярмухаметов, обычно не нужно держать большой запас: ресурсы можно добавлять по мере необходимости, часто автоматически. Обратная сторона — зависимость от провайдера: есть ли у него свободное оборудование, какие действуют квоты, сколько займет запуск новых серверов, особенно когда речь идет о GPU. С собственным оборудованием сложнее. Его нужно выбрать, купить, доставить, установить и настроить, а потребности прогнозировать на годы вперед. К тому же сервер, который сегодня считается мощным, через несколько лет может уже не справляться с требованиями новых приложений.
По наблюдению Ярмухаметова, компании все чаще выбирают гибридную схему. Требования безопасности и регулирования иногда обязывают держать часть данных и приложений на своих серверах, а ресурсоемкие вычисления бывает выгоднее запускать на собственных GPU, используя облако для обычных приложений и баз данных. «В такой архитектуре приходится совмещать оба подхода к планированию мощностей», — говорит инженер.
