Google предложила ИИ-инструмент для миграции с EKS на GKE — но не для автоматического допуска изменений

Переезд с Amazon EKS на Google Kubernetes Engine (GKE) — это не замена названий полей в файлах Kubernetes. Новая конфигурация должна сохранять поведение прежней: приложениям нужны правильные права доступа, запросы должны попадать в нужные сервисы, а вычислительных ресурсов должно хватать для запуска. В собственном руководстве по миграции контейнеров Google советует сначала составить перечень нагрузок и разобраться в их зависимостях. 19

24 сентября Google представила инструмент GKE agentic migration с открытым исходным кодом. По описанию компании, он заменяет разрозненные запросы к языковой модели процессом, в котором рассуждения модели сочетаются с детерминированными инструментами и ограничениями. Идея в том, чтобы не принимать предложенную ИИ конфигурацию на веру. 2

Что придётся проверять инженерам

В описанном сценарии миграции модель помогает переводить инфраструктурный код и манифесты из среды EKS в конфигурации для GKE. Интерфейс Model Context Protocol (MCP) может предоставлять агенту доступ к инструментам, но сам по себе не подтверждает правильность результата. Доступный фрагмент анонса Google подтверждает сочетание модели и детерминированных инструментов, не раскрывая все операции плагина и правила преобразования. 2

Особого внимания заслуживают три группы изменений:

• Права доступа. При переходе от механизмов идентификации AWS к Workload Identity в GKE нагрузка должна получить необходимый доступ — и не получить лишнего.
• Входящий трафик. При переводе правил балансировщика на Gateway API важно проверить, что запросы по-прежнему идут в нужные сервисы.
• Выделение узлов. Новые настройки должны обеспечивать требуемые условия размещения нагрузок и достаточную ёмкость.

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

Проверка — не то же самое, что разрешение на развёртывание

Детерминированная проверка позволяет применять к предложенным файлам одни и те же правила до развёртывания. Но она устанавливает лишь то, что охватывают эти правила; анонс Google в доступном фрагменте не уточняет полный объём проверок. Совпадение поведения приложения после переключения всё равно нужно испытывать отдельно. 2

Описанный для инструмента подход с запросами на включение изменений в репозиторий (pull requests) оставляет инженерам возможность изучить различия и пропустить файлы через привычные тесты, политики и согласования CI/CD, прежде чем применять их к кластеру. Такой порядок согласуется с рекомендациями Google по управлению исходным кодом и развёртыванию в GKE. Однако доступный фрагмент анонса не подтверждает каждый шаг именно этого процесса у нового инструмента. 172

В анонсе исполнительный вице-президент Persistent Рахул Шривастава называет подход «доказуемой фабрикой миграций уровня компилятора». Это удачная метафора для генерации и проверки конфигурационных файлов, но не математическая гарантия безопасности всего переезда: зависимости, производительность и поведение системы после переключения остаются задачами тестирования. 2

Связь с открытым проектом Intrinsic Core

За два дня до анонса GKE компания Intrinsic представила на ROSCon 2026 в Торонто Intrinsic Core — открытый, совместимый с ROS набор компонентов для промышленной робототехники. Он включает возможности управления, планирования движений и захвата, симуляции и определения положения объектов; публикации указывают на лицензию Apache 2.0. Intrinsic также описывает независимую от конкретного оборудования систему управления в реальном времени и возможности цифрового двойника. 403337

Связь между выпусками скорее стратегическая, чем техническая: инструмент GKE призван упростить перенос нагрузок в Google Cloud, а Intrinsic Core — разработку робототехнических приложений. Пресса сравнивает второй подход со стратегией Android: открыть базовые технологии, чтобы вокруг них выросла экосистема. Но ни один из анонсов сам по себе не доказывает, что клиенты AWS перейдут к Google или что разработчики начнут покупать её ИИ-сервисы. 230

Вывод: разделение между предложением ИИ, проверкой и решением о развёртывании делает результат миграции удобнее для инженерного контроля. Оно не отменяет испытаний каждой нагрузки, а приведённые источники не содержат измеренной оценки экономии или снижения числа сбоев. 219