Pods как Workers, а не агенты: переосмысление единицы развёртывания для ИИ-агентов в Kubernetes

Значимый прорыв формирует отрасль ИИ: levashove 28 минут назад Pods как Workers, а не агенты: переосмысление единицы развёртывания для ИИ-агентов в Kubernetes 3 мин 941 Блог компании VK Tech Kubernetes * Искусственный интеллект DevOps * Облачные вычисления * Перевод Автор оригинала: Mark Silvester Команда 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.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.