Kubernetes создавался для приложений, чьё поведение можно описать заранее: сколько реплик нужно, какие ресурсы выделить, при каких сбоях перезапустить контейнер. Kubernetes для ИИ-агентов — задача другого типа: агент сам выбирает инструменты, меняет последовательность действий и может породить нагрузку, которой не было в исходной спецификации. Для российских команд, разворачивающих LLM-сервисы в собственных кластерах, это означает: привычный Helm chart уже не гарантирует управляемость системы.
Как пишет The New Stack, базовое допущение Kubernetes состоит в том, что программа исполняет заложенную разработчиком логику. Контроллеры Kubernetes отлично умеют сверять фактическое состояние с желаемым: вернуть упавший Pod, добавить реплики, применить декларативную конфигурацию. Но агентная система работает не только по заранее проложенному маршруту. Она получает цель, обращается к моделям и внешним инструментам, оценивает промежуточный результат и решает, что делать дальше.
Разница заметна уже на уровне жизненного цикла. Обычный веб-сервис обычно имеет понятный профиль: запрос пришёл, обработался, ответ ушёл. У агента одна пользовательская задача может превратиться в длинную цепочку вызовов: поиск данных, запрос к внутреннему API, запуск кода, повторная проверка и ещё один вызов модели. Время работы, потребление CPU и памяти, объём сетевого трафика и число обращений к зависимостям заранее оценить сложнее. Если такой процесс упирается в лимит или теряет доступ к инструменту, простой перезапуск контейнера не всегда помогает: нужно понимать, на каком шаге оказался агент и можно ли безопасно продолжить работу.
Отсюда вытекает неприятный для платформенных команд вопрос: что именно считать «желаемым состоянием»? Для сервиса это, например, три здоровые реплики за балансировщиком. Для агента недостаточно зафиксировать число Pod'ов. Нужно учитывать состояние самой задачи, набор разрешённых инструментов, контекст, ограничения на действия и бюджет вычислений. Иначе платформа исправно поддержит работоспособность инфраструктуры, пока агент будет бессмысленно повторять вызовы, расходовать квоту модели или создавать побочные эффекты во внешних системах.
Особенно важна граница между оркестрацией и полномочиями. Kubernetes умеет ограничивать ресурсы контейнера, изолировать пространства имён и управлять доступами через сервисные аккаунты. Но ИИ-агенту часто требуется доступ к данным, репозиториям, тикетам, корпоративным API или средствам автоматизации. Технически выдать доступ несложно; сложнее сделать его узким, временным и проверяемым. Агент, которому разрешили выполнить действие, не обязательно выберет ожидаемую последовательность шагов. Поэтому права на уровне кластера не заменяют политики для самих инструментов: какие операции допустимы, какие требуют подтверждения, где нужен журнал действий и кто отвечает за отмену неудачного процесса.
Проблема касается и наблюдаемости. Метрики Kubernetes покажут, что Pod потребляет память или перезапускается, но не ответят, почему агент сделал десять вызовов вместо одного и какое решение привело к ошибке. Для эксплуатации понадобятся трассировка цепочек действий, связь между запросом пользователя и вызовами инструментов, а также понятные лимиты на длительность и стоимость задачи. Без этого SRE-команда увидит лишь симптомы: рост нагрузки, очередь задач и нестабильные зависимости. Разработчики при этом будут искать причину в промпте, модели или внешнем API — нередко одновременно.
Это не означает, что Kubernetes нужно списывать со счетов. Он остаётся удобным фундаментом для запуска моделей, API, очередей и вспомогательных сервисов. Но Kubernetes для ИИ-агентов стоит рассматривать как слой инфраструктуры, а не как готовую систему управления агентным поведением. Командам полезно отделять выполнение задачи от управления её состоянием, заранее задавать тайм-ауты и бюджеты, ограничивать доступ к инструментам и сохранять аудит критичных действий. Чем автономнее агент, тем меньше надежды на то, что стандартный рестарт контейнера исправит последствия его решения.
Главный вопрос теперь не в том, можно ли запустить агента в кластере: это уже обычная инженерная работа. Вопрос в том, сумеют ли платформы описать и контролировать поведение софта, который получил цель, но не получил готовый сценарий её достижения. Именно здесь Kubernetes придётся дополнять новыми механизмами — для состояния задач, политик действий и наблюдаемости, а не просто ещё одним автоскейлером.