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