Migrace z EKS do GKE s pomocí AI: Google sází na kontrolu změn

Při přesunu aplikací z Amazon Elastic Kubernetes Service (EKS) do Google Kubernetes Engine (GKE) nestačí přepsat několik názvů v konfiguračních souborech. Důležité je zachovat také oprávnění aplikací, směrování požadavků a kapacitu, kterou mají úlohy k dispozici. Google nyní zveřejnil nástroj GKE agentic migration: agentní plugin, který podle firmy kombinuje uvažování velkého jazykového modelu s deterministickými nástroji a ochrannými pravidly. Cílem je nahradit nahodilé zadávání pokynů modelu řízenějším postupem. 2

Co musí při migraci obstát

U infrastruktury popsané kódem a manifestů Kubernetes je zásadní rozdíl mezi platným souborem a správně fungujícím nasazením. Při posuzování převodu z EKS do GKE by se tým měl ptát zejména:

• Identita a přístup: Zachovají převody oprávnění AWS na identitu úloh v GKE zamýšlený přístup, aniž by aplikaci přidaly zbytečná práva?
• Směrování provozu: Doručí převod pravidel pro vstupní provoz od vyvažovače zátěže na Gateway API požadavky správným službám?
• Výpočetní uzly: Udrží převod zajišťování uzlů potřebnou kapacitu a pravidla pro plánování úloh?

To jsou kontrolní otázky k popsanému migračnímu postupu, nikoli doložené záruky, že nástroj vyřeší každý případ. Také obecná migrační příručka Googlu doporučuje nejprve zmapovat úlohy a jejich závislosti. 19

Kontrola před nasazením, ne důvěra v odpověď modelu

V popisovaném postupu má model navrhovat převod a plugin mu prostřednictvím rozhraní Model Context Protocol (MCP) zpřístupňovat nástroje. Samotné MCP ovšem správnost výsledku nezaručuje. Oznámení Googlu potvrzuje spojení modelu s deterministickými nástroji, dostupný výňatek však nepopisuje všechna pravidla převodu ani úplný rozsah kontrol. 2

Deterministické kontroly lze nad navrženými soubory opakovat podle stejných pravidel. Ověří ale jen vlastnosti, pro které jsou nastavené; samy neprokážou, že se aplikace po přesunu bude chovat stejně. Pokud navržené změny procházejí přes pull request místo přímého zásahu do běžícího clusteru, mohou inženýři prohlédnout rozdíly a nechat je projít obvyklými testy a schvalováním v CI/CD. Dokumentace GKE takové postupy při nasazování popisuje, dostupný výňatek oznámení však nepotvrzuje každý krok konkrétního procesu tohoto nástroje. 217

Rahul Shrivastava ze společnosti Persistent v oznámení označuje přístup za „provable, compiler-grade migration factory“ — přirovnání k továrně, která migrační změny vytváří a kontroluje podobně jako kompilátor. Není to důkaz, že je bezpečnost celé migrace matematicky prokázaná. Chování aplikace za běhu, přístupy, výkon i samotné přepnutí provozu je stále nutné otestovat. 2

Vedlejší souvislost: otevřený základ pro robotiku

Dva dny před oznámením nástroje pro GKE představila společnost Intrinsic na konferenci ROSCon 2026 v Torontu open-source projekt Intrinsic Core. Nabízí komponenty kompatibilní s robotickým ekosystémem ROS pro řízení, plánování pohybu a uchopení, simulaci či odhad polohy; podle dostupných zpráv vychází pod licencí Apache 2.0. Intrinsic popisuje také řízení v reálném čase nezávislé na konkrétním hardwaru a funkce digitálního dvojčete. 403337

Souvislost s migrací do GKE je strategická, nikoli technická: jeden projekt může usnadnit přesun úloh do cloudu Googlu, druhý vývoj robotických aplikací na otevřeném základu. Zpravodajství u Intrinsic používá přirovnání k „Androidu pro roboty“. Ani jedno vydání však samo o sobě nedokládá, že zákazníci AWS přejdou ke Googlu nebo že vývojáři začnou nakupovat jeho placené AI služby. 230

Pro týmy plánující migraci je rozhodující hranice důvěry: AI může připravit návrh a kontroly mohou zachytit vymezené chyby. O tom, zda konfigurace zachovává požadované chování a může do produkce, ale musí rozhodnout ověřování a schvalování. Poskytnuté zdroje neuvádějí naměřené snížení počtu selhání ani nákladů na migraci. 219