В выборке из 23 тысяч Kubernetes-кластеров средняя загрузка CPU составила всего 8%, а GPU — 5%. На этом фоне особенно заметно, как устроена автоматизация Kubernetes в реальной жизни: выкатывать код команды давно доверили пайплайнам, а вот отдавать алгоритмам право трогать процессоры, память и дорогие GPU многие до сих пор не готовы.
Как пишет The New Stack, этот разрыв стал одним из главных выводов материала о том, как Kubernetes-команды относятся к автоматизации. С деплоем все давно понятно: CI/CD срабатывает десятки раз в день, автоскейлинг поднимает и убирает реплики за секунды, и никто не требует ручного одобрения на каждое движение. Но когда речь заходит о правах на CPU, memory requests, bin packing или пересборке нод под реальные нагрузки, уверенность куда-то исчезает. В итоге бизнес уже живет в режиме автоматизированной доставки, а инфраструктура часто все еще управляется логикой «лучше переложить с запасом, чем потом ловить инцидент».
Цена этой осторожности перестала быть абстрактной. По данным, на которые ссылается издание, компании в среднем резервируют куда больше ресурсов, чем реально используют: CPU уходит в простой, память бронируется с большим запасом, а GPU, которые теперь покупают почти как стратегический актив, могут часами простаивать без полезной нагрузки. Для обычных процессоров это неприятный, но терпимый перерасход. Для AI-инфраструктуры такая привычка уже бьет по бюджету всерьез: один лишний GPU стоит не как еще одна виртуалка, а как маленький повод пересмотреть квартальный FinOps-отчет.
Ситуацию обострил именно AI-бум. Если раньше переоценка потребностей в кластере была типичной болезнью DevOps-команд, то теперь она накладывается на гонку за ускорителями и на страх дефицита. Отсюда и парадокс, который хорошо ложится в повестку автоматизация Kubernetes: компании готовы автоматизировать путь к продакшену, но не готовы в таком же режиме оптимизировать базовый слой вычислений. Код можно откатить, если что-то пошло не так. С вычислительными ресурсами психология другая: инженеры опасаются, что слишком агрессивная оптимизация упрется в деградацию производительности, внезапные очереди, рост latency и жалобы бизнеса на «нестабильную платформу».
В логике команд это объяснимо. Ошибка в деплой-пайплайне обычно заметна, воспроизводима и встроена в отлаженный процесс отката. Ошибка в настройке ресурсов куда менее зрелищна, но не менее болезненна: приложение может не упасть, а просто начать работать хуже, нестабильно и в самые неприятные часы пик. Поэтому во многих компаниях автоматизация воспринимается как безопасная там, где есть четкие guardrails, история изменений и понятная метрика успеха. Релиз прошел или не прошел. А вот с CPU все сложнее: сколько именно забрать, где ужать requests, как не задушить сервис на пике, насколько можно доверять рекомендациям платформы, если вчерашняя нагрузка не похожа на завтрашнюю. И пока команда не верит в ответы на эти вопросы, она предпочтет переплатить.
Но экономика уже начинает спорить с этой привычкой. The New Stack обращает внимание на цифры: если средняя загрузка GPU держится около 5%, а CPU — около 8%, речь идет не о мелкой погрешности в capacity planning, а о системном промахе. Тем более что многие организации не просто держат резерв, а фактически оплачивают инфраструктуру, которая большую часть времени не приносит пользы. На языке бизнеса это означает не только высокий cloud bill, но и замороженную возможность для других проектов. На языке CTO — слабое место в масштабировании AI-направления. Пока компания докупает ускорители, не разобравшись, как используются уже купленные, она решает не дефицит, а собственную непрозрачность.
Для разработчиков и платформенных команд из этого следует довольно практичный вывод. Автоматизация Kubernetes больше не заканчивается на GitOps, пайплайнах и HPA. Следующий рубеж — доверие к системам, которые умеют непрерывно переразмечать ресурсы, подбирать размеры инстансов, уплотнять нагрузки и держать баланс между производительностью и стоимостью. Не в формате разовой оптимизации после неприятного счета от облака, а как постоянный контур управления. Иначе получается странная картина: инженерная культура уже считает нормой полностью автоматический путь от коммита до продакшена, но все еще воспринимает инфраструктурную эффективность как ручное ремесло с калькулятором и тревогой.
Для русскоязычного рынка здесь тоже нет экзотики. У команд, которые строят внутренние платформы, SaaS, рекомендательные системы или AI-сервисы поверх Kubernetes, та же развилка: либо продолжать покупать запас спокойствия, либо переводить управление ресурсами из режима интуиции в режим наблюдаемой автоматизации. Вопрос уже не в том, можно ли доверить кластеру больше решений. Вопрос в другом: кто быстрее научится доверять автоматике не только релизы, но и деньги. Подробности разбора приводит .