Googles GKE-verktøy lar migreringsforslag gå gjennom kontroll

Å flytte fra Amazon Elastic Kubernetes Service (EKS) til Google Kubernetes Engine (GKE) er mer enn å bytte navn på felt i konfigurasjonsfiler. Tilgangsrettigheter, trafikk og kapasitet må fortsatt fungere som tiltenkt. Googles nye migreringsverktøy med åpen kildekode er ment å gjøre dette arbeidet mer systematisk: Det kombinerer resonnering fra en stor språkmodell med verktøy og faste, deterministiske kontrollregler. 2

Forslag er ikke det samme som ferdig migrering

I den beskrevne arbeidsflyten kan en agent bruke verktøy til å foreslå GKE-konfigurasjon ut fra infrastrukturkode og Kubernetes-manifester for EKS. Model Context Protocol (MCP) er et grensesnitt som kan gi agenten tilgang til slike verktøy; protokollen garanterer ikke at forslagene blir riktige. Googles kunngjøring bekrefter kombinasjonen av språkmodell og deterministiske verktøy, men det tilgjengelige utdraget beskriver ikke alle operasjonene eller oversettelsesreglene. 2

Tre typer endringer krever særlig nøye gjennomgang:

• Identitet og tilgang: Bevarer en overgang fra AWS-identiteter til GKEs Workload Identity de tiltenkte rettighetene, uten å gi arbeidslastene for vid tilgang?
• Trafikkruting: Vil en overgang fra innkommende trafikk via lastbalanserer til Gateway API fortsatt sende forespørsler til riktige tjenester?
• Noder og kapasitet: Vil endret klargjøring av noder gi arbeidslastene ressursene og planleggingen de trenger?

Dette er spørsmål team bør stille ved slike oversettelser, ikke dokumenterte garantier for at verktøyet håndterer alle tilfeller. En konfigurasjonsfil kan være teknisk gyldig og likevel endre hvordan en applikasjon oppfører seg. Googles generelle migreringsveiledning anbefaler også å kartlegge arbeidslaster og avhengigheter før flyttingen. 19

Kontroll før utrulling

Deterministiske kontroller kan prøve de samme foreslåtte filene mot de samme reglene hver gang. Det gir en annen type kontroll enn modellens egen forklaring, men avdekker bare forhold reglene faktisk dekker. Googles kunngjøring omtaler slike kontrollmekanismer uten å angi hele omfanget av den lokale valideringen i det tilgjengelige utdraget. 2

Arbeidsflyten som er beskrevet for verktøyet, legger opp til at genererte endringer sendes som pull requests til gjennomgang, i stedet for å endre en aktiv klynge direkte. Da kan utviklere se forskjellene og bruke eksisterende tester og godkjenninger i CI/CD-løpet. Det samsvarer med Googles veiledning om kildekodekontroll og CI/CD for GKE, selv om det tilgjengelige kunngjøringsutdraget ikke bekrefter hvert trinn i verktøyets pull-request-prosess. 172

Rahul Shrivastava, EVP i Persistent, kaller tilnærmingen en «provable, compiler-grade migration factory» i Googles kunngjøring. Uttrykket beskriver ambisjonen om å produsere og kontrollere migreringsfiler; det er ikke et bevis for at en hel migrering er trygg. Tilgang, ytelse, avhengigheter og selve overgangen må fortsatt testes. 2

En parallell satsing på åpen teknologi

To dager før GKE-kunngjøringen lanserte Intrinsic, som er knyttet til Google, Intrinsic Core under ROSCon 2026 i Toronto. Den åpne, ROS-kompatible robotikkplattformen omfatter blant annet kontroll, planlegging av bevegelser og grep, simulering og posisjonsbestemmelse. Utgivelsen er lisensiert under Apache 2.0, og Intrinsic beskriver også et maskinvareuavhengig rammeverk for sanntidskontroll og digitale tvillinger. 403337

Forbindelsen mellom lanseringene er strategisk, ikke teknisk: GKE-verktøyet kan gjøre det enklere å vurdere en flytting til Google Cloud, mens Intrinsic Core kan gi robotikkutviklere et felles utgangspunkt. Intrinsic-satsingen er blitt sammenlignet med en «Android for roboter»-strategi. Ingen av lanseringene viser i seg selv at AWS-kunder vil bytte sky, eller at utviklere vil kjøpe Googles KI-tjenester. 230

Kort sagt: Verktøyet forsøker å tette tillitsgapet i KI-assistert automatisering ved å skille mellom modellens forslag, kontrollen av dem og beslutningen om utrulling. Det kan gjøre migreringsarbeidet lettere å vurdere innenfor vanlige utviklingsprosesser, men kildene dokumenterer ingen målt reduksjon i feil eller kostnader. 219