Googles migrationsagent för GKE låter AI föreslå – men inte besluta

Att flytta en Kubernetes-miljö från Amazons Elastic Kubernetes Service (EKS) till Google Kubernetes Engine (GKE) handlar om mer än att skriva om YAML-filer. Behörigheter, trafikvägar och tillgång till beräkningskapacitet måste fortsätta fungera som avsett. Google rekommenderar därför att team först kartlägger arbetslaster och beroenden inför en containermigrering. 19

Mot den bakgrunden presenterade Google den 24 september 2026 ett migrationsverktyg med öppen källkod. Enligt företaget kombinerar agentpluginet en stor språkmodells förmåga att resonera med deterministiska verktyg och skyddsräcken, i stället för att förlita sig på fristående AI-promptar. Tanken är att AI ska kunna föreslå ändringar utan att dess förslag automatiskt betraktas som säkra. 2

Det som behöver granskas i en EKS–GKE-migrering

I det beskrivna arbetsflödet kan agenten använda verktyg via Model Context Protocol (MCP), ett gränssnitt för att göra verktyg tillgängliga för en AI-agent. Gränssnittet säger däremot inget i sig om huruvida en föreslagen konfiguration är korrekt. Googles tillgängliga presentationsutdrag bekräftar kombinationen av språkmodellsresonemang och deterministiska verktyg, men redovisar inte varje operation eller översättningsregel i pluginet. 2

Tre typer av ändringar kräver särskilt noggrann kontroll:

• Identitet och behörighet: Om AWS-identiteter översätts till GKE:s Workload Identity, får varje arbetslast fortfarande den åtkomst den behöver – och inte mer?
• Inkommande trafik: Om trafik via lastbalanserare översätts till Gateway API, når anropen rätt tjänster enligt de avsedda reglerna?
• Nodkapacitet: Om nodprovisioneringen ändras, kan arbetslasterna fortfarande schemaläggas och få den kapacitet de behöver?

Detta är frågor att ställa vid granskning, inte verifierade garantier för att verktyget klarar varje scenario. En genererad konfigurationsfil kan vara syntaktiskt korrekt och ändå ändra åtkomst, trafikflöden eller kapacitetsförutsättningar.

Kontroller före driftsättning – inte ett löfte om riskfri migrering

Deterministiska kontroller kan pröva samma föreslagna filer mot samma regler, oberoende av hur övertygande språkmodellens egen förklaring låter. Men de fångar bara det som reglerna faktiskt kontrollerar. Google beskriver verktyget som skyddat av deterministiska spärrar; det tillgängliga presentationsutdraget specificerar inte hela omfattningen av den offlinevalidering som beskrivs för arbetsflödet. 2

Ett upplägg där ändringarna lämnas som pull requests för granskning i stället för att direkt ändra ett aktivt kluster skulle ge ingenjörer möjlighet att läsa ändringsförslag och låta ordinarie CI/CD-flöden köra tester och kräva godkännanden. Det ligger i linje med Googles dokumenterade råd om versionshantering och CI/CD för GKE. Det tillgängliga utdraget ur verktygets tillkännagivande bekräftar dock inte självständigt varje steg i ett sådant pull-request-flöde. 172

Rahul Shrivastava, EVP på Persistent, beskriver lösningen i Googles tillkännagivande som en ”provable, compiler-grade migration factory”. Det är en liknelse för att skapa och kontrollera migrationsunderlag, inte ett matematiskt bevis för att en hel migrering är säker. Applikationernas beteende, åtkomst, prestanda, beroenden och själva övergången måste fortfarande testas. 2

Ett annat öppet bygge från Google-kretsen

Två dagar före GKE-nyheten presenterade Intrinsic Intrinsic Core på ROSCon 2026 i Toronto. Den öppna, ROS-kompatibla grunden för industrirobotik innehåller bland annat funktioner för styrning, rörelse- och gripplanering, simulering och positionsuppskattning. Rapporteringen anger licensen som Apache 2.0; Intrinsic beskriver även hårdvaruoberoende realtidsstyrning och digitala tvillingar. 403337

Sambandet mellan lanseringarna är strategiskt, inte tekniskt. GKE-verktyget kan sänka tröskeln för att flytta arbetslaster till Google Cloud, medan Intrinsic Core kan göra det enklare att bygga robotapplikationer. Intrinsics satsning har beskrivits som ett slags ”Android för robotar”: att göra en grundplattform brett tillgänglig och bygga ett ekosystem runt den. Ingen av lanseringarna visar i sig att AWS-kunder byter molnleverantör eller att utvecklare köper Googles AI-tjänster. 230

Slutsatsen: Googles migrationsupplägg angriper ett konkret förtroendeproblem i AI-stödd infrastrukturautomation: ett AI-förslag behöver kunna skiljas från kontroll och beslut om driftsättning. Det kan göra en migrering lättare att bedöma inom etablerade arbetssätt, men källorna ger inga uppmätta resultat för lägre kostnader eller färre misslyckade migreringar. 219