Агент Google для міграції на GKE: згенерувати зміни — ще не означає впровадити їх

Google представила відкритий інструмент GKE agentic migration для переходу з Amazon Elastic Kubernetes Service (EKS) на Google Kubernetes Engine (GKE). Його задум — замінити разові запити до мовної моделі керованим процесом: модель допомагає розібратися з конфігурацією, а детерміновані інструменти й обмеження перевіряють запропоновані зміни. Саме це розмежування важливе для команд, яким недостатньо отримати правдоподібний YAML-файл: їм потрібно розуміти, що станеться після його застосування. 2

Що саме треба перевіряти під час перенесення

Міграція з EKS на GKE — не механічна заміна назв полів. Конфігурації інфраструктури як коду та маніфести Kubernetes мають зберегти призначення початкових налаштувань. Документація Google радить починати перенесення контейнерних навантажень з інвентаризації та оцінки їхніх залежностей. 19

У описаному сценарії особливої уваги потребують три групи змін:

• Доступ: чи отримають робочі навантаження після переходу з механізмів ідентифікації AWS на Google Workload Identity саме ті права, які їм потрібні, — і не більше?
• Трафік: чи збережуться правила доставки запитів до сервісів під час переходу від налаштувань балансувальника до Gateway API?
• Вузли: чи вистачить ресурсів і чи збережеться потрібне розміщення навантажень після зміни способу підготовки вузлів?

Це питання для інженерної перевірки, а не підтвердження, що агент правильно обробляє кожен такий випадок. Формально коректний файл конфігурації все одно може змінити права доступу, маршрутизацію або припущення щодо доступних ресурсів.

Де проходить межа довіри до агента

Інтерфейс Model Context Protocol (MCP) може надавати агенту доступ до інструментів, але сам по собі не засвідчує правильність результату. Google підтверджує поєднання міркувань мовної моделі з детермінованими інструментами; доступний уривок анонсу не описує всіх операцій плагіна та правил перетворення. 2

Детерміновані офлайнові перевірки дають змогу повторювано оцінювати запропоновані файли за визначеними правилами. Водночас вони перевіряють лише те, що охоплюють ці правила, і не доводять, що застосунок після перемикання працюватиме так само. Google називає детерміновані обмеження частиною захисту інструмента, але доступний уривок анонсу не уточнює повного обсягу офлайнової валідації. 2

У описаному процесі зміни мають потрапляти на розгляд через pull request і стандартні CI/CD-перевірки, а не одразу в робочий кластер. Це дало б інженерам змогу переглянути різницю між версіями файлів, виконати тести й застосувати правила погодження перед розгортанням. Такий підхід узгоджується з настановами Google щодо контролю версій і CI/CD для 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

Висновок: сильна сторона задуму GKE — не обіцянка безпомилкового ШІ, а можливість відокремити його пропозицію від перевірки та рішення про розгортання. Опубліковані джерела не містять виміряного зниження кількості невдалих міграцій або їхньої вартості. 219