Migrare da EKS a GKE: perché l’agente AI di Google non basta da solo

Una configurazione generata dall’AI può essere formalmente valida e, allo stesso tempo, cambiare chi ha accesso a una risorsa o dove arriva il traffico. È questo il problema che Google cerca di affrontare con GKE agentic migration, uno strumento open source pensato per rendere più strutturato il passaggio da Amazon Elastic Kubernetes Service (EKS) a Google Kubernetes Engine (GKE). Secondo Google, il plugin affianca il ragionamento dei modelli linguistici a strumenti e controlli deterministici, anziché affidarsi a prompt occasionali e al solo giudizio del modello. 2

La parte difficile non è riscrivere i file

Nel passaggio tra i due servizi Kubernetes, tradurre il codice che definisce l’infrastruttura e i manifest delle applicazioni significa conservarne gli effetti pratici. Prima di migrare, la stessa guida di Google raccomanda di censire carichi di lavoro, proprietà e dipendenze: senza questa ricognizione è difficile valutare se la configurazione di arrivo faccia davvero ciò che faceva quella di partenza. 19

Tre aspetti meritano una revisione particolarmente attenta:

• Identità e permessi: nel passaggio dall’identità AWS a quella dei carichi di lavoro su GKE, l’applicazione deve mantenere gli accessi necessari senza ottenerne di superflui.
• Ingresso del traffico: una configurazione di bilanciamento tradotta nella Gateway API deve continuare a indirizzare le richieste ai servizi giusti.
• Provisioning dei nodi: la nuova configurazione deve offrire capacità e condizioni di esecuzione adeguate ai carichi di lavoro.

Sono domande da porre alle conversioni, non garanzie che lo strumento risolva automaticamente ogni caso. Un’interfaccia basata su Model Context Protocol (MCP) può mettere strumenti a disposizione di un agente, ma non certifica da sola la correttezza dei risultati. L’annuncio di Google conferma l’unione fra ragionamento del modello e strumenti deterministici; l’estratto disponibile non dettaglia però tutte le operazioni del plugin o le regole di conversione. 2

Controlli ripetibili, senza confonderli con una prova di sicurezza

La verifica deterministica offline permette di sottoporre i file proposti alle stesse regole prima della distribuzione. Offre quindi un controllo diverso dalla spiegazione fornita dal modello stesso, ma può accertare soltanto le proprietà previste da quelle regole. Google parla di guardrail deterministici, senza specificare nell’estratto disponibile l’intera copertura della validazione offline. 2

Nel flusso di lavoro descritto, le modifiche generate passano inoltre attraverso pull request: gli ingegneri possono esaminare le differenze e applicare test, criteri e approvazioni delle normali pipeline CI/CD, invece di modificare direttamente un cluster in esercizio. È un’impostazione coerente con le indicazioni di Google sull’uso del controllo di versione e della CI/CD per GKE, anche se l’estratto dell’annuncio non conferma autonomamente ogni passaggio specifico del flusso di pull request dello strumento. 172

Rahul Shrivastava, dirigente di Persistent, definisce l’approccio una «provable, compiler-grade migration factory» nell’annuncio di Google. La metafora rende l’idea di una produzione di configurazioni sottoposte a controlli; non equivale a una dimostrazione matematica che l’intera migrazione sia sicura. Permessi effettivi, prestazioni, dipendenze e comportamento dopo il passaggio restano da testare. 2

Il parallelo con Intrinsic Core

Due giorni prima dell’annuncio su GKE, Intrinsic ha presentato a ROSCon 2026, a Toronto, Intrinsic Core: una base open source compatibile con ROS per applicazioni di robotica industriale. Comprende funzionalità riutilizzabili per controllo, pianificazione dei movimenti e delle prese, simulazione e stima della posa; le cronache indicano una licenza Apache 2.0. Intrinsic descrive anche un framework di controllo in tempo reale indipendente dall’hardware e funzionalità di gemello digitale. 403337

Il legame con GKE è strategico, non tecnico: uno strumento può ridurre il lavoro necessario per valutare una migrazione verso Google Cloud, l’altro quello richiesto per costruire applicazioni robotiche. La stampa ha accostato Intrinsic Core a un approccio «Android dei robot», basato sulla diffusione di una piattaforma di partenza e sulla crescita di un ecosistema. Nessuna delle due uscite dimostra, però, che i clienti AWS cambieranno cloud o che gli sviluppatori acquisteranno servizi AI di Google. 230

In sintesi: separare le proposte dell’AI dai controlli e dall’autorità di distribuire le modifiche può rendere una migrazione più esaminabile. Non elimina la verifica di ogni applicazione; le fonti disponibili non quantificano riduzioni dei costi o degli errori di migrazione. 219