В конце января 2025 года в блоге CNCF появился пост Lin Sun, в котором автор, опираясь на опыт разработки проекта kagent, предложил пересмотреть роль Pod в контексте развёртывания ИИ-агентов в Kubernetes. Основной тезис заключается в том, что Pod остаётся подходящей единицей исполнения для агента, но перестаёт быть адекватной единицей развёртывания, идентичности или жизненного цикла. Этот материал, переведённый командой VK Cloud, адресован платформенным инженерам, DevOps- и SRE-специалистам, а также всем, кто сталкивается с задачей развёртывания ИИ-агентов в кластере. Вопрос, поднятый автором, становится всё более актуальным по мере роста числа агентов и усложнения их взаимодействия с инфраструктурой.

Ключевая проблема, которую выделяет Lin Sun, заключается в том, что стандартные абстракции Kubernetes, такие как Pod и Service, изначально проектировались для микросервисов, которые должны быть постоянно доступны. Агенты же ведут себя иначе: они могут активироваться только при появлении задачи, работать от нескольких секунд до нескольких минут, а затем простаивать, что делает выделение отдельного Pod для каждого агента расточительным. Кроме того, агенты способны порождать субагентов для параллельного выполнения подзадач, действовать от имени пользователя и приостанавливаться на неопределённое время в ожидании одобрения человека. В результате Pod остаётся отличной средой исполнения, но не подходит в качестве абстракции жизненного цикла для короткоживущих рабочих нагрузок. Автор также поднимает вопросы изоляции агентов, предоставления им собственной идентичности, применения политик доступа и сети, а также определения принадлежности агентов при мультитенантности.

Один из подходов, который рассматривает Sun, — сделать каждого агента полноценной рабочей нагрузкой Kubernetes с собственными Pod, Service и ServiceAccount. Именно этот путь изначально выбрал kagent, который запускал множество агентов внутри единого runtime. Такой подход обеспечивает изоляцию процессов и контейнеров, даёт агенту идентичность ServiceAccount, встроенную в существующую аутентификацию и авторизацию, и открывает доступ к сетевым политикам и admission policy Kubernetes. Логи, метрики и трейсы привязываются к конкретному агенту, а планирование и управление ресурсами остаются нативными для Kubernetes. Позже kagent добавил поддержку более строгой изоляции через проект Kubernetes Agent Sandbox. Однако этот подход сталкивается с проблемой неэффективного использования ресурсов, поскольку каждый агент требует постоянного Pod, даже когда он простаивает.

Альтернативный подход, который предлагает Google в рамках анонса Agent Sandbox и Agent Substrate, заключается во введении control plane поверх Kubernetes. Agent Substrate управляет тем, как логические агенты размещаются на Workers и перемещаются между ними, тогда как Kubernetes продолжает управлять Pods, Services, сетью, хранилищем и вычислениями. В этой модели абстракции повторяют знакомые платформенным инженерам концепции: WorkerPool аналогичен NodePool, Workers аналогичны Nodes, а ActorTemplate соответствует декларативной спецификации Pod. Kubernetes знает только о WorkerPools и ActorTemplates, а Workers и Actors существуют в собственных CLI и API Agent Substrate, при этом каждый Worker сопоставлен с одним Pod. Actor представляет собой логическую единицу, которая «действует как» ИИ-агент: он планируется на Worker при поступлении работы и приостанавливается, возобновляется или удаляется в соответствии со своим жизненным циклом.

Благодаря такому подходу фиксированный пул долгоживущих Pods может обслуживать значительно больше логических агентов, чем было бы практично при выделенном непрерывно работающем Pod для каждого из них. Pods становятся исполняющими Workers, а не моделью развёртывания для агентов. Это меняет подход к идентичности и управлению доступом: если Actor может выполняться на любом Worker, идентичность может принадлежать ActorTemplate, пространству имён, тенанту и версии, а не Pod или Service. Контроль доступа, сетевые политики и runtime-разрешения также могут задаваться на уровне шаблона с переопределениями для каждого Actor. Однако возникают новые сложности: за владением, квотами и биллингом становится сложнее уследить, когда исполнение перестаёт быть строго один-к-одному с Pods. Observability должна следовать за логическим агентом, связывая логи, трейсы и записи аудита с Actor независимо от того, где он был запланирован.

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

Перспективы развития этого направления выглядят многообещающими, но остаются открытые вопросы. Например, как обеспечить безопасность при использовании control plane поверх Kubernetes, учитывая, что агенты могут действовать от имени пользователей и иметь доступ к чувствительным данным. Также неясно, как стандартизировать observability для логических агентов, которые могут мигрировать между Workers. В ближайшее время стоит ожидать дальнейших публикаций и обсуждений в сообществе CNCF, а также развития проектов kagent и Agent Substrate. Подкаст Kubernetes от Google уже включил пост Sun в свой еженедельный обзор новостей, что свидетельствует о растущем интересе к этой теме. Российским инженерам стоит внимательно следить за этими разработками, поскольку они могут предложить практические решения для эффективного управления ИИ-агентами в Kubernetes, что особенно важно в условиях импортозамещения и необходимости оптимизации ресурсов.