Google передаёт gVisor в CNCF вместе с двумя проектами для запуска и обучения ИИ-агентов — Agent Substrate и OpenRL. Это не косметическая перестановка логотипов: sandbox, которым для изоляции исполнения кода пользуются Anthropic и OpenAI, получает нейтральное управление, а значит — больше шансов стать стандартной частью агентной инфраструктуры и за пределами Google. Для российских команд, строящих внутренние coding-агенты, платформы автоматизации или сервисы с пользовательским кодом, это сигнал: вопрос безопасного выполнения LLM-сгенерированных команд уже переезжает из экспериментального контура в базовый слой платформы.
О передаче трёх open-source-проектов в Cloud Native Computing Foundation сообщает The New Stack. Все они приняты в уровень CNCF Sandbox и проходят онбординг с независимой инфраструктурой сборки и участием внешних мейнтейнеров. Одновременно Google выпустила Agent Substrate 1.0 и объявила о его общей доступности в составе Google Kubernetes Engine. Сам gVisor, открытый Google ещё в 2018 году, движется к следующей стадии — Incubation.
Состав пакета хорошо показывает, на какую проблему рассчитывает Google. gVisor изолирует недоверенный код: между контейнером и ядром Linux работает лёгкое прикладное ядро в пользовательском пространстве, которое перехватывает системные вызовы. Agent Substrate управляет жизненным циклом множества агентов: отделяет их состояние от активных вычислений, чтобы не держать контейнер и выделенные ресурсы занятыми, пока агент ждёт ответ модели, API или человека. OpenRL предназначен для post-training и обучения с подкреплением на Kubernetes. Вместе это слой исполнения, изоляции и обучения — три довольно болезненные части агентного контура.
Потребность в таком наборе возникает не из любви индустрии к ещё одному runtime. Обычный контейнер делит с другими нагрузками ядро хоста. Для типового веб-сервиса это привычный компромисс; для агента, который запускает сгенерированный shell-код, подтягивает пакеты и обращается к инструментам, компромисс выглядит заметно хуже. Микровиртуальные машины дают более жёсткую границу, но могут быть тяжелее в эксплуатации и зависят от возможностей инфраструктуры. gVisor занимает промежуточную позицию: не требует nested virtualization и рассчитан на плотность контейнеров.
Почему Google отдаёт проект фонду
Технически gVisor уже не новичок. Google заявляет, что он ежедневно обслуживает миллионы sandbox-окружений в GKE Sandbox и Cloud Run. Внешние пользователи включают Anthropic, где технология применяется для выполнения кода Claude в веб-продукте, и OpenAI, использующую её для изоляции code execution. Среди других участников экосистемы названы Modal, Snowflake, Ant Group и Tencent. Но массовому внедрению мешал не только инженерный выбор между контейнером и microVM: заказчики и облачные провайдеры обычно осторожны с критическим компонентом, развитие которого фактически контролирует один вендор.
Переход gVisor в CNCF должен снять именно этот барьер. В планах — вынести разработку и тестовую инфраструктуру из Google, дать внешним мейнтейнерам право принимать изменения и закрепить модель управления, при которой одна компания не может единолично определять судьбу проекта. К команде мейнтейнеров намерены присоединиться Ant Group, Modal и Tines; OpenAI, Tencent и NVIDIA продолжают вклад в разработку. Для пользователей это важнее громкого слова «фонд»: появляется более предсказуемая траектория для патчей, интеграций и поддержки.
Есть и менее очевидная причина. Google и другие провайдеры поддерживают собственные патчи ядра Linux, ускоряющие I/O-нагрузки gVisor почти до уровня нативного Linux. Эти оптимизации не вошли в основной Linux kernel, и потому не доступны всем пользователям из коробки. Google связывает отказ upstream-мейнтейнеров с прежним статусом проекта под контролем одного поставщика; в истории обсуждений были и технические вопросы к отдельным предложениям. Нейтральное управление не гарантирует, что патчи завтра попадут в mainline, но убирает один из организационных аргументов против их принятия.
Agent Substrate отвечает на другую экономику. Агент работает рывками: выполняет действие, ждёт модель или внешний сервис, затем продолжает. Держать отдельный Pod живым на каждом таком ожидании — значит тратить память и вычисления на паузу. Google утверждает, что платформа умеет сохранять неактивные сессии и восстанавливать их менее чем за 500 миллисекунд, а также обеспечивает плотность до десяти раз выше стандартных container runtime. Эти показатели стоит воспринимать как заявления поставщика, однако сама постановка задачи точна: оркестрация долгоживущих, но большую часть времени бездействующих агентов плохо ложится на классическую модель «поднял Pod — держи Pod».
Для инженеров это не означает, что нужно немедленно переносить агента на новый стек. gVisor не отменяет сетевые политики, управление секретами, ограничения egress, контроль образов и аудит действий; sandbox — лишь одна граница защиты. Agent Substrate и OpenRL также не заменяют Kubernetes, а добавляют над ним специализированные механизмы. Но командам, которые уже дают модели право выполнять код или планируют такую функцию, есть смысл следить за совместимостью своих образов с gVisor и за тем, как проекты оформят API и governance в CNCF.
Сравнение с Kubernetes пока скорее амбиция Google, чем прогноз. Kubernetes победил не потому, что любой контейнер внезапно стал простым, а потому что отрасль договорилась вокруг общего уровня абстракции. Если gVisor в CNCF, Agent Substrate и OpenRL сумеют собрать вокруг себя облака, производителей железа и независимых разработчиков, агентам может достаться похожий фундамент. Главный открытый вопрос — станет ли этот стек нейтральным стандартом для недоверенного агентного кода или останется удобным дополнением к GKE. Детали передачи и аргументы Google собраны в публикации .
