Migracja z EKS do GKE z pomocą AI: propozycja to jeszcze nie wdrożenie

Google chce zastąpić doraźne proszenie modelu językowego o „przepisanie” konfiguracji bardziej uporządkowanym procesem migracji z Amazon Elastic Kubernetes Service (EKS) do Google Kubernetes Engine (GKE). Udostępnione jako open source narzędzie ma łączyć rozumowanie modelu z deterministycznymi narzędziami i mechanizmami kontroli. To istotne rozróżnienie: AI może zaproponować zmianę, ale nie powinno samo rozstrzygać, czy jest ona bezpieczna do wdrożenia. 2

Poprawny plik nie wystarczy

Migracja nie polega wyłącznie na zamianie nazw pól w manifestach Kubernetes czy plikach opisujących infrastrukturę jako kod. Trzeba zachować działanie aplikacji: właściwe uprawnienia, trasy ruchu oraz sposób zapewniania zasobów obliczeniowych. Także ogólne wytyczne Google zalecają rozpoczęcie migracji od rozpoznania aplikacji i ich zależności. 19

W opisanym podejściu model ma pomagać w interpretacji istniejącej konfiguracji, a wtyczka agenta — udostępniać mu narzędzia. Interfejs Model Context Protocol (MCP) może ułatwiać taki dostęp, lecz sam w sobie nie potwierdza poprawności wyniku. Ogłoszenie Google potwierdza połączenie rozumowania modelu z deterministycznymi narzędziami; dostępny fragment nie opisuje jednak wszystkich operacji wtyczki ani reguł konwersji. 2

Dlatego szczególnej uwagi wymagają trzy obszary wskazane w opisie migracji:

• Tożsamość i uprawnienia: czy przeniesienie mechanizmów dostępu z AWS do rozwiązania tożsamości dla aplikacji w GKE zachowa potrzebne uprawnienia, nie nadając zbyt szerokich?
• Ruch sieciowy: czy zastąpienie konfiguracji wejścia przez load balancer rozwiązaniem opartym na Gateway API skieruje żądania do właściwych usług?
• Węzły klastra: czy nowy sposób zapewniania węzłów utrzyma wymagane możliwości uruchamiania aplikacji i odpowiednią pojemność?

To pytania do sprawdzenia, a nie potwierdzenie, że narzędzie poprawnie obsługuje każdy przypadek. Manifest może przejść kontrolę składni, a mimo to zmienić zachowanie systemu.

Kontrola przed wdrożeniem, nie zamiast testów

Deterministyczne sprawdzanie proponowanych plików pozwala stosować powtarzalne reguły, zamiast polegać na wyjaśnieniu wygenerowanym przez ten sam model. Daje jednak pewność tylko w zakresie tego, co reguły rzeczywiście badają. Google mówi o deterministycznych mechanizmach kontroli, lecz dostępny fragment ogłoszenia nie określa pełnego zakresu walidacji poza działającym klastrem. 2

Podejście oparte na pull requestach — propozycjach zmian w repozytorium — pozwoliłoby inżynierom przejrzeć różnice i przepuścić je przez zwykłe testy, polityki oraz zatwierdzenia CI/CD, zamiast od razu modyfikować działający klaster. Jest to zgodne z dokumentacją Google dotyczącą kontroli wersji i wdrażania do GKE. Sam dostępny fragment ogłoszenia nie potwierdza jednak niezależnie każdego kroku procesu pull requestów w tym konkretnym narzędziu. 172

Rahul Shrivastava z firmy Persistent nazywa to podejście w ogłoszeniu Google „fabryką migracji, którą można weryfikować na poziomie kompilatora”. To obrazowe porównanie procesu generowania i sprawdzania zmian, nie dowód matematyczny bezpieczeństwa całej migracji. Uprawnienia, działanie aplikacji, wydajność i moment przełączenia nadal trzeba przetestować. 2

A co z otwartą robotyką Intrinsic?

Dwa dni wcześniej, 22 września 2026 r., Intrinsic przedstawił na konferencji ROSCon w Toronto otwarty projekt Intrinsic Core. Obejmuje on zgodne z ROS elementy oprogramowania do sterowania robotami, planowania ruchu i chwytania, symulacji oraz określania położenia obiektów. Według doniesień kod udostępniono na licencji Apache 2.0; Intrinsic opisuje również niezależną od sprzętu platformę sterowania w czasie rzeczywistym i możliwości cyfrowego bliźniaka. 403337

Związek między premierami jest strategiczny, nie techniczny: pierwsza może ułatwiać przechodzenie na chmurę Google, druga — tworzenie aplikacji robotycznych na otwartej podstawie. Media porównują tę drugą strategię do budowania ekosystemu wokół Androida. Żadna z premier nie dowodzi jednak, że klienci AWS zmienią dostawcę chmury albo że twórcy robotów zaczną kupować usługi AI Google. 230

Wniosek: najważniejszą obietnicą narzędzia GKE jest oddzielenie propozycji wygenerowanej przez AI od jej oceny i decyzji o wdrożeniu. Może to ułatwić prowadzenie migracji w ramach znanych zespołom procedur, ale nie zwalnia z testowania każdej aplikacji. Dostępne źródła nie podają zmierzonego spadku liczby błędów ani kosztów migracji. 219