Переход к ИИ-нагрузкам в Kubernetes уже начался, но платформенные команды сталкиваются с серьезными вызовами. По данным CNCF 2025 Annual Cloud Native Survey, 66% организаций, размещающих генеративные ИИ-модели, используют Kubernetes для части или всех инференс-нагрузок. При этом только 7% респондентов развёртывают ИИ-модели ежедневно. Этот разрыв показывает, что запустить ИИ в кластере — лишь половина дела; гораздо сложнее обеспечить непрерывную эксплуатацию в production. Kubernetes изначально дал платформенным командам единообразный способ развёртывать, масштабировать и эксплуатировать контейнеризированные приложения, и теперь им приходится поддерживать ещё и ИИ-нагрузки. Именно поэтому вопрос о готовности платформы к непрерывной эксплуатации ИИ становится центральным.

Исследование 2025 State of AI in Platform Engineering подтверждает: 35% платформенных команд до сих пор не оркестрируют ИИ-нагрузки. Такая статистика говорит о незрелости операционных процессов, необходимых для масштабной поддержки ИИ. Многие организации еще не интегрировали управление моделями и ускорителями в свои стандартные рабочие процессы, что тормозит переход от экспериментов к промышленному использованию. Разрыв между внедрением ИИ и зрелостью операционных платформ проявляется в том, что команды могут запускать отдельные пилоты, но не имеют воспроизводимых и управляемых конвейеров для постоянной работы с моделями. Это отставание операционных практик от скорости экспериментов становится ключевым барьером для масштабирования.

ИИ не требует отказа от Cloud Native-практик, но предъявляет дополнительные требования к вычислительным ресурсам, планированию и доставке моделей. Kubernetes, GitOps, observability, автоматизация и самообслуживание по-прежнему составляют ценный фундамент, однако ИИ добавляет новые артефакты и условия. Платформам необходимо расширить модель ресурсов за пределы CPU и памяти, учитывая гетерогенные вычисления. Например, Dynamic Resource Allocation (DRA) в Kubernetes позволяет гибче и декларативнее запрашивать специализированное оборудование, такое как GPU. Также важно адаптировать CI/CD-конвейеры для управления жизненным циклом моделей, включая их версионирование, оценку и развёртывание. Вместо привычной цепочки «код — сборка — тестирование — развёртывание» командам может потребоваться управлять более сложной последовательностью: код, модель и конфигурация проходят оценку, развёртывание, наблюдение и обновление. Модели могут занимать много места, зависеть от конкретной runtime-среды или оборудования и требовать оценки перед развёртыванием, поэтому платформенная команда должна понимать, какие приложение, модель и конфигурация запущены в данный момент и можно ли воспроизвести это развёртывание. Наблюдаемость должна выйти за рамки инфраструктурных метрик, отслеживая использование ускорителей и их памяти, время планирования и ожидания в очереди, задержку инференса, время загрузки модели, пропускную способность и состояние endpoint. При этом не нужно создавать отдельный стек мониторинга — достаточно расширить существующую Cloud Native observability, чтобы в контексте одной нагрузки сопоставить инфраструктурную, прикладную и специфичную для ИИ телеметрию. Так проще ответить на вопрос, на который не отвечает одна лишь метрика использования GPU: где именно нагрузка проводит время в ожидании.

Контекст проблемы уходит корнями в эволюцию Cloud Native-технологий. Kubernetes изначально создавался для оркестрации контейнеризированных приложений, и его архитектура хорошо подходит для масштабирования и управления микросервисами. Однако ИИ-нагрузки добавляют новые артефакты, такие как модели, и требуют учета аппаратных ускорителей. Конкуренты в лице проприетарных платформ для машинного обучения предлагают готовые решения, но они часто ограничены в гибкости и не интегрируются с существующими DevOps-практиками. Kubernetes же предлагает единую среду, но требует доработки инструментов и процессов. Сравнение с альтернативами показывает, что Kubernetes не единственный путь. Специализированные платформы, такие как Kubeflow или MLflow, предлагают более узкий функционал для ML-воркфлоу, но они часто требуют интеграции с Kubernetes для оркестрации. Проприетарные облачные сервисы, например AWS SageMaker или Google Vertex AI, предоставляют готовые среды, но привязывают пользователей к конкретному вендору. Kubernetes же остается открытым и расширяемым, что делает его привлекательным для организаций, стремящихся избежать вендор-лока. Однако для полноценной поддержки ИИ платформам необходимо развивать самообслуживание и эталонные пути для разработчиков, чтобы те не становились экспертами по инфраструктуре Kubernetes ради развёртывания модели.

Для российского рынка эта тенденция особенно актуальна, поскольку многие компании активно внедряют ИИ в свои продукты. Платформенные команды вынуждены искать баланс между использованием привычных Cloud Native-инструментов и адаптацией к новым требованиям. Реакция отрасли неоднозначна: одни видят в этом возможность для создания более унифицированных платформ, другие указывают на сложность и необходимость дополнительного обучения специалистов. В условиях импортозамещения и ограниченного доступа к зарубежным облачным сервисам, локальные решения на базе Kubernetes могут стать ключевыми для поддержки ИИ-проектов. Платформенная команда может предоставить стандартизированный путь самообслуживания, в котором уже учтены типовые инфраструктурные и операционные решения: модель, ресурсы, развёртывание, endpoint, observability и политика. Разработчик указывает требования нагрузки, а платформа обеспечивает повторяемую реализацию. Это тот же принцип платформенной инженерии, который упростил доставку Cloud Native-приложений, с той разницей, что эталонный путь теперь должен учитывать модели и ускорители наряду с контейнерами, CPU и памятью.

Перспективы дальнейшего развития связаны с улучшением интеграции ИИ-нагрузок в Kubernetes. Ожидается, что сообщество продолжит работу над DRA, операторами для моделей и стандартами наблюдаемости. Открытыми вопросами остаются безопасность моделей, управление затратами на GPU и обеспечение воспроизводимости экспериментов. Ключевая задача — сделать эксплуатацию ИИ в Kubernetes такой же рутинной, как и работу с обычными контейнеризированными приложениями. Если это удастся, Kubernetes укрепит свои позиции как универсальная платформа для всех типов production-нагрузок. Пока же разрыв между 66% организаций, использующих кластеры для инференса, и 7%, развёртывающих модели ежедневно, остаётся главным индикатором незрелости операционных практик. Преодоление этого разрыва потребует не только технологических доработок, но и изменения подходов к обучению специалистов и организации платформенных команд.