Команда VK Cloud перевела материал о посте Lin Sun в блоге CNCF: остаётся ли Pod правильной единицей развёртывания, идентичности и жизненного цикла для ИИ-агентов на Kubernetes. Материал будет полезен платформенным инженерам, DevOps- и SRE-инженерам и всем, кто разворачивает ИИ-агентов в кластере.
Зачем пересматривать роль Pod
В посте блога CNCF Lin Sun опирается на работу над проектом kagent и утверждает: Pod, возможно, остаётся правильной единицей исполнения для агента, но уже не единицей развёртывания, идентичности или жизненного цикла.
Вопросы, которые встают по мере роста числа агентов, знакомы платформенным командам. Как изолировать одного агента от другого? Как каждый получает собственную идентичность? Как применять политики доступа и сети, видеть, что делает конкретный агент, и определять, кому он принадлежит при мультитенантности? Это вопросы платформы для агентов, а не вопросы Kubernetes, хотя ответы на них приходится выражать именно средствами Kubernetes.
Агент как рабочая нагрузка Kubernetes
Один из прямолинейных подходов: сделать каждого агента полноценной рабочей нагрузкой Kubernetes с собственными Pod, Service и ServiceAccount. Именно этот путь выбрал kagent, который сначала запускал множество агентов внутри единого runtime. Такой подход изолирует процессы и контейнеры, даёт агенту идентичность ServiceAccount, встроенную в существующую аутентификацию и авторизацию, и открывает доступ к сетевым политикам и admission policy Kubernetes. Логи, метрики и трейсы привязаны к конкретному агенту, а планирование и управление ресурсами остаются нативными для Kubernetes. Позже kagent добавил поддержку более строгой изоляции через проект Kubernetes Agent Sandbox.
Сложность в том, что агенты ведут себя не так, как микросервисы, под которые изначально проектировались эти абстракции. Сервис должен быть доступен постоянно, а агент может просыпаться только при назначении задачи, работать секунды или минуты, а затем простаивать. Из-за этого выделенный Pod на каждого потенциального агента становится расточительным. Агенты также могут порождать субагентов для параллельного выполнения подзадач, действовать от имени пользователя и приостанавливаться на неопределённое время в ожидании одобрения от человека. Pod остаётся отличной средой исполнения, но подходящей абстракцией жизненного цикла для такой короткоживущей работы не становится.
Control plane над Kubernetes: Agent Substrate
Есть и другой путь: перестать относиться к каждому агенту как к рабочей нагрузке Kubernetes и вместо этого ввести control plane над Kubernetes. Именно так поступает Agent Substrate, который Google представил вместе с Agent Sandbox в анонсе Agent Sandbox и Agent Substrate. Эту возможность поддерживает kagent, как описано в руководстве kagent по интеграции с Agent Substrate.
Agent Sandbox предоставляет изолированную среду исполнения, а Agent Substrate управляет тем, как логические агенты размещаются на Workers и перемещаются между ними. Kubernetes по-прежнему управляет Pods, Services, сетью, хранилищем и вычислениями, а слой выше управляет жизненным циклом и размещением Actors на исполняющих Workers. Его абстракции повторяют концепции, уже знакомые платформенным инженерам: WorkerPool аналогичен NodePool, Workers аналогичны Nodes, а ActorTemplate соответствует декларативной спецификации Pod.
Kubernetes знает только о WorkerPools и ActorTemplates. Workers и Actors существуют в собственных CLI и API Agent Substrate, при этом каждый Worker сопоставлен с одним Pod. Actor представляет собой логическую единицу, которая «действует как» ИИ-агент: он планируется на Worker при поступлении работы и приостанавливается, возобновляется или удаляется в соответствии со своим жизненным циклом. Благодаря этому фиксированный пул долгоживущих Pods обслуживает намного больше логических агентов, чем было бы практично при выделенном, непрерывно работающем Pod для каждого из них. Pods становятся исполняющими Workers, а не моделью развёртывания для агентов.
Что это меняет для платформенных инженеров
Последствия выходят за рамки эффективности планирования. Sun утверждает: если Actor может выполняться на любом Worker, идентичность может принадлежать ActorTemplate, пространству имён, тенанту и версии, а не Pod или Service. Контроль доступа, сетевые политики и runtime-разрешения точно так же может понадобиться задавать на уровне шаблона, с переопределениями для каждого Actor. За владением, квотами и биллингом становится сложнее уследить, когда исполнение перестаёт быть строго один-к-одному с Pods. Observability должна следовать за логическим агентом, связывая логи, трейсы и записи аудита с Actor независимо от того, где он был запланирован.
Ничто из этого не вытесняет Kubernetes, который остаётся отраслевым стандартом платформы для микросервисов и инференс-нагрузок в промышленном масштабе. Вопрос стоит более узко: должен ли Pod, доказав свою состоятельность как среда исполнения, также оставаться единицей развёртывания, идентичности и жизненного цикла для ИИ-агентов. Именно это Agent Substrate исследует через kagent. Позже подкаст Kubernetes от Google включил пост Sun в свой еженедельный обзор новостей.
