Toolkit AI per l'ingegneria cloud: ingegneria della piattaforma su GKE utilizzando Gemini

1. Introduzione

La risoluzione dei problemi relativi ai deployment Kubernetes non funzionanti è una parte comune e spesso frustrante della vita quotidiana di un ingegnere della piattaforma. Di solito, è necessario svolgere molte indagini manuali: esaminare i log, eseguire comandi kubectl describe e fare riferimenti incrociati ai file YAML per trovare una singola mancata corrispondenza o configurazione errata.

Sebbene i chatbot AI generici possano aiutarti a spiegare concetti o scrivere codice di base, operano in un vuoto. Non conoscono il tuo codebase specifico o lo stato live del tuo cluster, il che comporta un sacco di copia e incolla manuali e cambi di contesto.

In questo lab, sperimenterai come colmare questa lacuna utilizzando strumenti di AI con livelli di contesto crescenti. Utilizzerai Gemini CLI e il Model Context Protocol (MCP) per risolvere i problemi di un'applicazione non funzionante su GKE. Al termine di questo lab, avrai capito come utilizzare l'AI che riconosce i tuoi file e la tua infrastruttura per risolvere più rapidamente problemi complessi e come codificare questi workflow in "abilità" riutilizzabili per il tuo team.

Concetti principali

• Platform engineering:il platform engineering è la pratica di creare e mantenere strumenti e workflow interni che consentono agli sviluppatori di software di gestire la propria infrastruttura senza dover essere esperti di ogni servizio cloud sottostante. L'obiettivo è ridurre l'attrito tecnico mantenendo coerenza e sicurezza. Creando un percorso consigliato standardizzato, i team della piattaforma garantiscono che gli sviluppatori di applicazioni possano eseguire il deployment in modo sicuro e rapido, mentre il team della piattaforma mantiene il controllo della governance e dei costi.
• Gemini CLI: Gemini CLI è un'interfaccia a riga di comando che ti consente di interagire con i modelli Gemini direttamente dal terminale. A differenza di un chatbot standard basato sul web, l'interfaccia a riga di comando è progettata per esistere all'interno del tuo ambiente di sviluppo, il che semplifica l'integrazione dell'AI nei flussi di lavoro esistenti basati su shell. Consente di inviare l'output di altri comandi direttamente al modello ed eseguire le istruzioni senza uscire dal terminale.
• Model Context Protocol (MCP): MCP è uno standard aperto che consente a un modello di AI di connettersi a strumenti o origini dati specifici. Senza MCP, un modello di AI conosce solo i dati su cui è stato addestrato e non può vedere le tue risorse specifiche. Con il server GKE MCP, Gemini CLI può eseguire query attive sull'API del tuo progetto Google Cloud, ispezionare lo stato dei tuoi cluster ed eseguire comandi per tuo conto. Funge da ponte tra il motore di ragionamento del modello e l'API GKE effettiva.
• Competenze degli agenti: le competenze sono pacchetti di istruzioni, script e risorse che estendono le funzionalità di un agente AI per attività specializzate. Ti consentono di codificare gli standard organizzativi e automatizzare i workflow complessi.

Obiettivi del lab

In questo lab imparerai a:

1. Progressione del contesto dell'esperienza: scopri come l'aumento del contesto migliora la risoluzione dei problemi dell'AI.
2. Risoluzione dei problemi manuale e con l'AI: confronta la difficoltà del debug manuale con i flussi di lavoro assistiti dall'AI.
3. Debug con contesto completo: utilizza Gemini CLI con il server MCP GKE per eseguire il debug delle applicazioni con piena consapevolezza dell'infrastruttura.
4. Estendi le funzionalità:scopri come scrivere skill personalizzate per automatizzare i workflow.

Nota sugli output LLM

A causa della natura di questo lab e del funzionamento degli LLM, è probabile che gli output ottenuti siano diversi da quelli di esempio mostrati. Questo è il comportamento previsto per l'AI generativa. Concentrati sulla comprensione dei passaggi e del ragionamento fornito dal modello, anziché cercare di replicare il testo o la formattazione esatti degli esempi.

2. Configurazione del progetto

Prima di iniziare il lab, prepara l'ambiente. Apri Cloud Shell, seleziona il tuo progetto ed esegui gli script di configurazione. Iniziamo.

Apri Cloud Shell

Per questo lab, utilizza Cloud Shell, un ambiente terminale basato su browser fornito da Google Cloud. È preconfigurato con tutti gli strumenti necessari, tra cui Google Cloud CLI (gcloud), kubectl e Gemini CLI, il che ti fa risparmiare tempo nell'installazione di questi strumenti sulla tua macchina locale.

1. Vai alla console Google Cloud.
2. Guarda l'intestazione in alto a destra della console e fai clic sul pulsante Attiva Cloud Shell (a forma di prompt del terminale >_).
3. Si apre una sessione del terminale nella parte inferiore della finestra del browser. Se richiesto, fai clic su Continua.

Seleziona un progetto

Nel terminale Cloud Shell, assicurati di lavorare nel progetto corretto.

1. Seleziona un progetto esistente o creane uno nuovo appositamente per questo lab nella console.
2. Prendi nota dell'ID progetto. Imposta il progetto nella shell corrente eseguendo: gcloud config set project [YOUR_PROJECT_ID]

Configurazione del lab

Ora esegui gli script di configurazione per preparare l'ambiente e introdurre i bug per il lab.

1. Clona il repository:
   👉💻 Esegui i seguenti comandi per clonare solo la directory del lab:

   git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos ~/devrel-demos
   cd ~/devrel-demos
   git sparse-checkout set codelabs/ai-toolkit-lab-1
   

2. Vai alla directory del lab:
   👉💻 Esegui:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
   

3. Imposta le variabili di ambiente:
   👉💻 Esegui i seguenti comandi per impostare il progetto e la regione:

   export PROJECT_ID=$(gcloud config get-value project)
   export REGION=us-central1
   

4. Esegui lo script di configurazione:
   questo script abilita le API elencate di seguito, crea un cluster GKE Autopilot e garantisce l'installazione degli strumenti richiesti.
   👉💻 Esegui lo script dalla directory principale:

   ./setup.sh
   

   Nota: la creazione del cluster può richiedere 5-10 minuti.
5. Inizializza lo stato di errore:
   per simulare lo scenario in cui i tuoi colleghi ti hanno lasciato un ambiente danneggiato, esegui lo script break.sh. Copia i manifest danneggiati nella directory del codebase attivo.
   👉💻 Esegui lo script:

   ./break.sh
   

6. Preparati per gli esercizi di laboratorio:
   per impedire all'AI di barare (vedere le soluzioni), passa alla directory cymbal-bank per il resto del laboratorio.
   👉💻 Esegui:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

API abilitate

Lo script di configurazione abilita diverse API Cloud di Google. Ecco cosa fanno:

• container.googleapis.com: l'API Google Kubernetes Engine. È obbligatorio per qualsiasi operazione a livello di cluster.
• generativelanguage.googleapis.com: l'API che consente alla Gemini CLI di comunicare con i modelli Gemini.
• cloudresourcemanager.googleapis.com: richiesto per l'ispezione dei metadati a livello di progetto e la gestione delle autorizzazioni.
• logging.googleapis.com::essenziale per la risoluzione dei problemi, in quanto consente di recuperare e analizzare i log dai container.

3. Fase 0: risoluzione dei problemi manuale (senza AI)

Ora che ti trovi nella directory cymbal-bank, proviamo a trovare gli errori manualmente. Questo è il "metodo difficile". Prova l'esperienza di base prima di lasciare che l'AI si occupi del lavoro pesante. La risoluzione manuale dei problemi prevede l'utilizzo di strumenti standard come kubectl per esaminare lo stato del cluster, recuperare i log e leggere i file YAML per individuare le incoerenze. Spesso è lento, noioso e richiede competenze per collegare i punti. Questo serve come punto di riferimento perfetto per gli strumenti di AI che utilizzerai in seguito.

1. Prova a eseguire il deployment: vediamo cosa pensa Kubernetes di questi manifest.
   👉💻 Esegui questo comando per applicare i manifest:

   kubectl apply -f kubernetes-manifests/
   

   L'avvio dei pod potrebbe richiedere alcuni secondi. Puoi monitorare il loro stato di attività utilizzando "watch kubectl get pods". Una volta attivati, utilizza Ctrl+C per uscire da watch.Nell'elenco noterai due pod non riusciti:
   • Il pod frontend mostra un "CreateContainerConfigError". Questo tipo di errore in genere suggerisce che il contenitore ha difficoltà a caricare la configurazione richiesta. Pensa a quali risorse esterne potrebbe essere necessario avviare un container. Esistono variabili di ambiente, secret o ConfigMap che potrebbero essere configurati in modo errato o mancanti? Dovrai esaminare la configurazione del pod per trovare il problema specifico.
   • Il pod userservice si trova nello stato "ImagePullBackOff". Quando vedi questo messaggio, in genere significa che il cluster non è in grado di recuperare l'immagine container che gli è stato chiesto di utilizzare. Considera i dettagli della richiesta di immagine: il nome e il tag dell'immagine sono esattamente corretti? Esistono potenziali problemi di autorizzazione con il registro? Dai un'occhiata alla posizione da cui viene estratta l'immagine per capire perché la richiesta non va a buon fine.
2. Ispeziona il danno:utilizza i comandi Kubernetes standard per vedere cosa non funziona.
   • 👉💻 Controlla lo stato dei pod e i relativi nomi:

     kubectl get pods
     

     • Osservazione:vedi i pod in ImagePullBackOff, CrashLoopBackOff, Pending o CreateContainerConfigError.
     • Nota:un pod nello stato Running non significa necessariamente che funzioni correttamente. Ad esempio, potrebbero mancare probe di integrità sufficienti (attività/idoneità), il che fa sì che venga contrassegnato come in esecuzione anche se l'applicazione al suo interno non funziona. I log possono mostrare errori, nonostante un pod apparentemente in esecuzione. In totale, ci sono 11 errori diversi da correggere.
   • 👉💻 Descrivi un pod non riuscito per visualizzare gli eventi (sostituisci [POD_NAME] con il nome di un pod effettivo):

     kubectl describe pod [POD_NAME]
     

   • 👉💻 Controlla i log di un pod non riuscito per visualizzare gli errori dell'applicazione:

     kubectl logs [POD_NAME]
     

3. Il lavoro di indagine:apri i manifest in kubernetes-manifests/ utilizzando l'editor di Cloud Shell o cat nel terminale. Prova a correlare gli errori visualizzati nei log e negli eventi con la configurazione nei file YAML.Sfida: prova a correggere UN SOLO errore manualmente. Nota come devi passare da un file all'altro per capire il resto della catena di errori.

4. Fase 1: chiedere al web (UI web di Gemini)

Poiché la risoluzione manuale dei problemi è lenta, proviamo a utilizzare un assistente AI. L'applicazione web Gemini è una potente interfaccia di chat per uso generico. È eccellente nello spiegare concetti e generare snippet di codice. Tuttavia, opera con zero contesto del tuo ambiente specifico. Non può visualizzare i tuoi file, esaminare il tuo cluster o eseguire comandi. Devi copiare e incollare manualmente i messaggi di errore e i contenuti dei file.

1. Vai su Gemini: apri gemini.google.com in una nuova scheda. Dovrai accedere con il tuo Account Google.
2. Chiedi assistenza per un errore specifico: supponiamo che tu veda l'errore ImagePullBackOff nel pod userservice.
   👉💬 Inserisci questo prompt nell'interfaccia utente web di Gemini:
   My Kubernetes deployment for 'userservice' is failing with ImagePullBackOff. Here is the image name: us-central1-docker.pkg.dev/bank-of-anthos-ci/bank-of-anthos/user-service:v0.6.9. What is wrong?
3. Risposta dell'AI: Gemini ti fornisce un elenco di cause comuni:
   • L'immagine non esiste.
   • Non disponi delle autorizzazioni per estrarlo.
   • È presente un errore di battitura.
   Suggerisce di controllare le autorizzazioni del registro o di IAM. Tuttavia, non può sapere che il nome effettivo dell'immagine è userservice (senza il trattino) a meno che non veda il tuo progetto.

Il principale punto di attrito è che Gemini non ha visibilità sul tuo ambiente locale. Per ottenere il contesto necessario, dovresti fornirlo manualmente (inserendo prompt e copiando e incollando il testo), il che richiede tempo e può causare errori.

5. Fase 2: potenza del terminale (Gemini CLI)

Ora passa al terminale utilizzando Gemini CLI. Gemini CLI porta la potenza dei modelli Gemini direttamente nel tuo terminale. La CLI è disponibile ovunque lavori. Legge i file locali, accetta input piped ed esegue persino comandi della shell per tuo conto (con la tua approvazione). Ciò lo rende incredibilmente utile per integrare l'AI nei tuoi workflow senza cambiare contesto. Per informazioni più dettagliate e sull'utilizzo avanzato, consulta la documentazione ufficiale di Gemini CLI.

Nota:al momento, Antigravity CLI è stata rilasciata ufficialmente ed è il successore di Gemini CLI. Questo lab continua a utilizzare Gemini CLI. Per maggiori dettagli su Antigravity CLI, consulta la documentazione ufficiale di Antigravity CLI.

Contesto e visibilità

Prima di passare alle istruzioni, tieni presente che la visibilità di Gemini CLI nel tuo progetto dipende dalla posizione da cui lo avvii. Il modello può visualizzare file e cartelle relativi alla directory di lavoro attuale. Se lo esegui dalla radice del progetto, ha accesso a tutti i file del progetto. Se lo esegui da una sottodirectory, la visualizzazione è limitata a quella sottodirectory e alle relative sottodirectory secondarie. Assicurati sempre di trovarti nella directory corretta prima di chiedere al modello di analizzare o modificare i file.

Avvio di Gemini CLI

Cloud Shell include Gemini CLI per impostazione predefinita. Avvialo per iniziare a utilizzarlo con i tuoi file locali.

1. Vai alla directory Cymbal Bank:
   👉💻 Esegui questo comando per assicurarti di trovarti nella directory corretta:

   cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/cymbal-bank
   

2. Avvia Gemini CLI:
   👉💻 Esegui il seguente comando per avviare Gemini CLI:

   gemini
   

Utilizzo di Gemini CLI

Tutto ciò che sai di questa applicazione è dove trovare il codice e che non funziona. Scopriamo di più e vediamo come Gemini può aiutarti a risolvere il problema. Innanzitutto, prova a testare la sua capacità di esplorare il contesto ponendo una domanda sui file dell'applicazione che dovrebbe essere in grado di vedere.

1. Esplora la base di codice: chiedi a Gemini di spiegare cos'è questa applicazione e cosa fa.
   👉💬 Inserisci questo prompt in Gemini CLI:
   What is this application and what does it do?
   Gemini CLI legge i file nella directory corrente e fornisce una panoramica di alto livello del progetto.
2. Prova a trovare un problema nel codebase: poiché Gemini CLI vede i tuoi file, chiedigli di trovare una mancata corrispondenza.
   👉💬 Inserisci questo prompt in Gemini CLI:
   The contacts service pod is running, but I can't reach the service. Review kubernetes-manifests/contacts.yaml and check for common issues
   Gemini CLI legge i file e rileva la mancata corrispondenza tra app: contacts-backend e app: contacts. Si tratta di un enorme vantaggio rispetto alle fasi precedenti.
3. Chiedi di correggere il problema:
   👉💬 Inserisci questo prompt in Gemini CLI:
   Fix the label mismatch in contacts.yaml so the service matches the deployment.
   Gemini CLI mostra il file YAML corretto o applica la modifica se approvi il comando.
4. La limitazione: anche se vede i file, non sa ancora cosa viene effettivamente eseguito nel cluster. Se un pod non funziona a causa di un errore di runtime non ovvio nello YAML statico, non può essere utile senza log o stato del cluster.

Nota:Gemini CLI ti chiederà il consenso quando esegui comandi o apporti modifiche ai file. In questo modo, mantieni il controllo sul tuo ambiente. Quando vedi un prompt come quello riportato di seguito, puoi premere "Invio" per rispondere "1. Consenti una volta" per ogni richiesta di azione. Puoi anche toccare il tasto Freccia giù e premere Invio per selezionare "2. Consenti per questa sessione", in modo che Gemini CLI esegua sempre questa azione in modo indipendente, senza chiedere la tua autorizzazione, per la durata della conversazione. Tuttavia, se chiudi e riapri Gemini CLI, l'autorizzazione non sarà più valida e ti verrà chiesta di nuovo prima di intraprendere qualsiasi azione.

Nota:se non riesci ad andare avanti o vuoi riprovare da zero, ripristina lo stato iniziale dei manifest Kubernetes in qualsiasi momento eseguendo ../break.sh dalla directory cymbal-bank.

Nota:se raggiungi un limite di utilizzo, seleziona "Interrompi" e poi esegui /model per vedere quali modelli hanno raggiunto i limiti e passare a un modello diverso, ad esempio gemini-2.5-flash-lite. Quindi, chiedi al modello di "continuare" per proseguire con il lab utilizzando il nuovo modello.

6. Fase 3: debug con contesto completo (Gemini CLI + GKE MCP)

La fase 2 ha mostrato la potenza dell'AI quando può vedere i tuoi file, ma era anche rumorosa. Dovevi approvare manualmente ogni singola azione di lettura e strumento, il che crea notevoli difficoltà durante una sessione di debug complessa. La fase 3 introduce il server GKE MCP per risolvere questo problema, fornendo all'AI una "consapevolezza dell'infrastruttura" diretta. In questo modo, Gemini può risolvere i problemi relativi a log, eventi e metadati con meno interruzioni manuali, creando un flusso di risoluzione dei problemi più automatizzato e coeso.

Che cos'è MCP?

Per comprendere MCP, è utile innanzitutto capire il concetto di strumenti nel mondo dell'AI. Uno strumento è essenzialmente una funzione o un'applicazione esterna che un LLM può utilizzare per eseguire azioni o recuperare dati a cui altrimenti non potrebbe accedere, ad esempio controllare il meteo, eseguire uno script specifico o interrogare un database. Sebbene i singoli strumenti siano potenti, condividerli in modo sicuro e coerente tra diversi agenti e ambienti AI è sempre stata una sfida. MCP risolve questo problema fungendo da piattaforma standardizzata in grado di ospitare questi strumenti ed esporli a qualsiasi client AI compatibile.

Il Model Context Protocol (MCP) è un protocollo open source che consente ai modelli di AI di accedere in modo sicuro a strumenti e origini dati esterni. Invece di codificare le integrazioni per ogni strumento o database specifico, MCP fornisce un modo standardizzato per consentire ai modelli di interagire con il loro ambiente.

Puoi visualizzare gli strumenti disponibili in Gemini CLI eseguendo /mcp all'interno di Gemini CLI.

In questo lab, il server GKE MCP consente alla Gemini CLI di interagire direttamente con il tuo cluster GKE, consentendole di ispezionare le risorse, leggere i log e aiutarti a eseguire il debug dei problemi con piena consapevolezza dello stato live del cluster. In questo modo, l'AI si trasforma da analizzatore di codice statico in un assistente attivo per la risoluzione dei problemi che comprende lo stato live della tua infrastruttura.

Configura l'estensione MCP di GKE

Per impostazione predefinita, Gemini CLI è uno strumento per uso generico. Configura il server GKE MCP creando un file di configurazione.

1. 👉💻 Innanzitutto, esci dalla CLI di Gemini digitando /quit.
2. 👉💻 Esegui il comando seguente per creare la directory dell'estensione:

   mkdir -p ~/.gemini/extensions/gke
   

3. 👉💻 Esegui questo comando per creare il file di configurazione. Questo comando inserisce automaticamente il tuo PROJECT_ID nel file:

   cat << EOF > ~/.gemini/extensions/gke/gemini-extension.json
   {
     "name": "gke",
     "version": "1.0.0",
     "mcpServers": {
       "container": {
         "httpUrl": "https://container.googleapis.com/mcp",
         "authProviderType": "google_credentials",
         "oauth": {
           "scopes": ["https://www.googleapis.com/auth/container"]
         },
         "timeout": 30000,
         "headers": {
           "x-goog-user-project": "$PROJECT_ID"
         }
       }
     }
   }
   EOF
   

4. 👉💻 Avvia Gemini CLI:

   gemini
   

5. Verifica che il server MCP sia abilitato digitando /mcp in Gemini CLI.

Chiedi a Gemini di eseguire il debug utilizzando lo stato del cluster

1. Esegui il debug del deployment non riuscito:ora, chiedi a Gemini di ispezionare il cluster e correggere i manifest in base a ciò che trova.
   👉💬 Inserisci questo prompt in Gemini CLI:
   The frontend deployment is failing. Can you use your tools to check the logs and events of the pods, and then fix it?
   Gemini utilizza gli strumenti MCP per chiamare i comandi kubectl in background. Visualizza l'errore ImagePullBackOff, ne spiega la causa e suggerisce la correzione corretta.
2. Risolvi problemi complessi: chiedi di esaminare i log per individuare errori a livello di applicazione.
   👉💬 Inserisci questo prompt in Gemini CLI:
   Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
   Viene visualizzato l'errore di connessione rifiutata e viene rintracciato fino alla mancata corrispondenza della porta o del nome del servizio in config.yaml.
3. Itera:continua a chiedere a Gemini di risolvere gli altri problemi che hai riscontrato nella fase 0.
   👉💬 Inserisci questo prompt in Gemini CLI:
   Check if the service 'contacts' is correctly routing traffic to its pods
   👉💬 Inserisci questo prompt in Gemini CLI:
   Are there any pods failing due to resource limits?

Nota:se non riesci ad andare avanti o vuoi riprovare da zero, ripristina lo stato iniziale dei manifest Kubernetes in qualsiasi momento eseguendo ../break.sh dalla directory cymbal-bank.

7. Fase 4: potenziare il team (competenze dell'agente)

Infine, estendi le funzionalità dell'AI per le tue esigenze specifiche creando competenze dell'agente personalizzate.

Che cosa sono le competenze dell'agente?

Le competenze degli agenti sono pacchetti di istruzioni, script e risorse che estendono un agente AI per attività specializzate. Ti consentono di codificare gli standard organizzativi e automatizzare i workflow complessi. Una skill si trova in una directory specifica e contiene un file SKILL.md che ne definisce il comportamento. Creando le competenze, ti assicuri che l'AI segua un processo coerente e ripetibile anziché improvvisare.

Una tipica directory delle skill ha questo aspetto:

my-skill/
├── SKILL.md          # Main instruction file (Required)
├── scripts/           # Helper scripts (Optional)
└── resources/         # Templates or data files (Optional)

Creazione di una skill per la risoluzione dei problemi di Kubernetes

Anziché creare questi file manualmente, Gemini CLI offre un modo efficace per creare l'impalcatura delle competenze utilizzando il linguaggio naturale.

Immagina di voler creare una skill chiamata k8s-troubleshooter per automatizzare i passaggi che hai appena eseguito.

1. Crea la skill tramite prompt: puoi chiedere a Gemini CLI di creare la skill per te, in base a ciò che hai imparato oggi.
   👉💬 Inserisci questo prompt in Gemini CLI:
   Create a new skill called 'k8s-troubleshooter' that helps diagnose issues with Kubernetes manifests and cluster state. It should be able to analyze pod logs, events, and resource descriptions to identify common deployment problems and configuration errors.
   Come quando chiama uno strumento o esegue un'azione, Gemini CLI dovrebbe comunicarti che il prompt ha attivato la sua skill "creatore di skill". Si tratta di una skill preconfigurata in Gemini CLI che consente a Gemini di creare Agent Skills.
   Gemini dovrebbe chiederti l'autorizzazione per creare la directory delle skill. Approva selezionando "1. Consenti una volta".
   Gemini esegue automaticamente le seguenti operazioni:
   • Crea una directory in ~/.gemini/skills/k8s-troubleshooter/.
   • Genera un file SKILL.md con istruzioni basate sul prompt.
   • Crea directory di risorse standard.
2. Riavvia Gemini CLI:
   👉💻 chiudi Gemini CLI (/quit), poi riavviala:

   gemini
   

3. Verifica che la skill sia caricata:
   👉💻 Verifica che la skill sia attiva digitando /skills in Gemini CLI. Dovresti visualizzare k8s-troubleshooter nell'elenco.
4. Come funziona in pratica: ora invoca la skill:
   👉💬 Inserisci questo prompt in Gemini CLI:
   Use the k8s-troubleshooter skill to find out why the contacts service is failing.
   L'AI segue il piano strutturato in SKILL.md anziché improvvisare, il che porta a risultati più coerenti.

Esercizio: concettualizza le tue competenze

Pensa al tuo flusso di lavoro quotidiano. Quale attività ripetitiva potresti automatizzare con una skill?

• Idea:una skill per controllare i manifest per le best practice di sicurezza prima del deployment.
• Idea: una skill per generare configurazioni di cluster GKE complesse in base al tipo di workload.

8. Conclusione

Questo lab mostra un nuovo modo di interagire con l'infrastruttura cloud procedendo attraverso diversi livelli di contesto AI. Se passi da un contesto zero a un contesto di infrastruttura completo (interfaccia a riga di comando Gemini + GKE MCP), puoi notare quanto diventa più efficace un assistente AI quando vede i tuoi file e lo stato del cluster.

Riepilogo del lab

• Il contesto è importante:vedi come gli strumenti di AI senza contesto non possono aiutare a risolvere problemi specifici del codebase.
• Contesto del terminale: utilizzi Gemini CLI per analizzare i file locali e identificare gli errori di configurazione direttamente dal tuo spazio di lavoro.
• Debug con contesto completo:utilizzi Gemini CLI con MCP per consentire all'AI di diagnosticare e risolvere problemi complessi mettendo in correlazione i file del codebase con lo stato del cluster live.
• Estensibilità:scopri le competenze e come utilizzarle per codificare le conoscenze dell'organizzazione.

Esegui la pulizia

Per evitare addebiti continui, esegui lo script di smantellamento. Tieni presente che questo passaggio non è necessario se esegui il lab su Qwiklabs.

👉💻 Esegui il seguente comando dalla directory del workshop:

cd ~/devrel-demos/codelabs/ai-toolkit-lab-1/
./teardown.sh

Passaggi successivi

Ecco alcuni consigli per ulteriori letture:

• Documentazione di Gemini CLI: la documentazione ufficiale di Gemini CLI.
• Documentazione di GKE: la pagina di destinazione di tutta la documentazione di GKE.
• Platform engineering su Google Cloud: indicazioni su come affrontare il platform engineering su Google Cloud.
• AI e machine learning su GKE: documentazione sull'esecuzione di workload AI/ML su GKE.
• Centro architettura Google Cloud: indicazioni e best practice per la creazione di carichi di lavoro su Google Cloud.

9. Appendice: soluzione ai problemi del file manifest

Se hai difficoltà o vuoi verificare gli errori, ecco l'elenco delle interruzioni introdotte nella directory manifests-broken/ e come correggerle:

1. URL non validi in config.yaml:
   • Errore: TRANSACTIONS_API_ADDR: "ledgerwriter::8080" (due punti).
   • Motivo:l'applicazione non riesce ad analizzare l'indirizzo, causando errori di connessione.
   • Correzione:ripristina il valore "ledgerwriter:8080".
2. Etichette non corrispondenti in contacts.yaml:
   • Errore: il selettore del servizio è impostato su app: contacts-backend anziché su contacts.
   • Motivo:il servizio non riesce a trovare i pod (che hanno ancora app: contacts), quindi il traffico non verrà instradato.
   • Correzione:imposta il selettore su app: contacts.
3. Mancata corrispondenza delle porte in userservice.yaml:
   • Errore: il servizio targetPort è impostato su 8081 anziché su 8080.
   • Motivo:il traffico inviato al servizio verrà inoltrato alla porta del container errata, causando il rifiuto della connessione.
   • Correzione:modifica targetPort riportandolo a 8080.
4. Nomi dei servizi non corrispondenti in config.yaml:
   • Errore: BALANCES_API_ADDR: "balance-reader:8080" (anziché balancereader).
   • Motivo:il nome host non verrà risolto in DNS perché il servizio è denominato balancereader.
   • Correzione:ripristina il valore "balancereader:8080".
5. Policy di pull delle immagini in contacts.yaml:
   • Errore: imagePullPolicy: Never.
   • Motivo:K8s non estrae l'immagine dal registro, supponendo che sia locale. L'operazione non andrà a buon fine e verrà visualizzato il messaggio ErrImagePull.
   • Correzione:rimuovi la linea o impostala su IfNotPresent.
6. Errori della probe di idoneità in userservice.yaml:
   • Errore: il percorso è stato modificato in /healthz anziché /ready.
   • Motivo:il container non gestisce /healthz, quindi il probe non riesce e il pod non viene mai contrassegnato come pronto.
   • Correzione:modifica il percorso e ripristina /ready.
7. Limiti delle risorse in contacts.yaml:
   • Errore: limite di memoria impostato su 10Mi anziché 128Mi.
   • Perché:l'app ha bisogno di più memoria per avviarsi, il che causa l'interruzione per esaurimento della memoria.
   • Correzione:ripristina il limite di memoria.
8. Variabili di ambiente mancanti in frontend.yaml:
   • Errore: rimossa la variabile di ambiente REGISTERED_OAUTH_CLIENT_ID.
   • Motivo:l'app potrebbe non funzionare o disattivare le funzionalità se mancano le variabili di ambiente previste.
   • Correzione:ripristina la definizione della variabile di ambiente.
9. Mancata corrispondenza della chiave ConfigMap in frontend.yaml:
   • Errore: key: DEMO_USER invece di DEMO_LOGIN_USERNAME.
   • Motivo:K8s non riesce a trovare la chiave in ConfigMap, causando l'avvio non riuscito del container.
   • Correzione:imposta nuovamente il tasto su DEMO_LOGIN_USERNAME.
10. Errore di battitura nel nome dell'immagine in userservice.yaml:
    • Errore: user-service invece di userservice.
    • Motivo:l'immagine non esiste nel registro, causando ImagePullBackOff.
    • Correzione:correggi il nome dell'immagine.
11. Problemi con il service account in contacts.yaml:
    • Errore: bank-of-anthos-sa invece di bank-of-anthos.
    • Perché:il service account non esiste o non dispone delle autorizzazioni.
    • Correzione:utilizza il nome ServiceAccount corretto.