Boîte à outils d'IA pour l'ingénierie du cloud : ingénierie de plate-forme sur GKE avec Gemini

1. Introduction

Le dépannage des déploiements Kubernetes défectueux est une tâche courante, souvent frustrante, dans la vie quotidienne d'un ingénieur de plate-forme. Cela implique généralement de nombreuses investigations manuelles : parcourir les journaux, exécuter des commandes kubectl describe et comparer les fichiers YAML pour trouver une seule incohérence ou erreur de configuration.

Les chatbots d'IA à usage général peuvent vous aider à expliquer des concepts ou à écrire du code de base, mais ils fonctionnent de manière isolée. Ils ne connaissent rien de votre code source spécifique ni de l'état réel de votre cluster, ce qui entraîne de nombreux copier-coller manuels et changements de contexte.

Dans cet atelier, vous allez découvrir comment combler ce manque en utilisant des outils d'IA avec des niveaux de contexte croissants. Vous utiliserez Gemini CLI et le protocole de contexte de modèle (MCP) pour résoudre les problèmes d'une application défaillante sur GKE. À la fin de cet atelier, vous comprendrez comment utiliser l'IA qui connaît vos fichiers et votre infrastructure pour résoudre des problèmes complexes plus rapidement, et comment codifier ces workflows en "compétences" réutilisables pour votre équipe.

Concepts fondamentaux

• Ingénierie des plates-formes : l'ingénierie des plates-formes consiste à créer et à gérer des outils et des workflows internes qui permettent aux développeurs de logiciels de gérer leur propre infrastructure sans avoir à maîtriser tous les services cloud sous-jacents. L'objectif est de réduire les frictions techniques tout en maintenant la cohérence et la sécurité. En créant un chemin d'or standardisé, les équipes de plate-forme s'assurent que les développeurs d'applications peuvent déployer des applications de manière sécurisée et rapide, tandis que l'équipe de plate-forme conserve le contrôle sur la gouvernance et les coûts.
• Gemini CLI : Gemini CLI est une interface de ligne de commande qui vous permet d'interagir avec les modèles Gemini directement depuis votre terminal. Contrairement à un chatbot Web standard, la CLI est conçue pour exister dans votre environnement de développement, ce qui facilite l'intégration de l'IA dans les workflows existants basés sur le shell. Il vous permet de rediriger la sortie d'autres commandes directement vers le modèle et d'exécuter des instructions sans quitter votre terminal.
• Model Context Protocol (MCP) : MCP est une norme ouverte qui permet à un modèle d'IA de se connecter à des outils ou des sources de données spécifiques. Sans MCP, un modèle d'IA ne connaît que les données sur lesquelles il a été entraîné et ne peut pas voir vos ressources spécifiques. Avec le serveur GKE MCP, Gemini CLI peut interroger activement l'API de votre projet Google Cloud, inspecter l'état de vos clusters et exécuter des commandes en votre nom. Il sert de passerelle entre le moteur de raisonnement du modèle et l'API GKE.
• Compétences de l'agent : les compétences sont des ensembles d'instructions, de scripts et de ressources qui étendent les capacités d'un agent d'IA pour des tâches spécialisées. Ils vous permettent de codifier les normes organisationnelles et d'automatiser les workflows complexes.

Objectifs de l'atelier

Au cours de cet atelier, vous allez :

1. Progression du contexte de l'expérience : découvrez comment l'augmentation du contexte améliore la résolution des problèmes par l'IA.
2. Dépannage manuel ou assisté par IA : comparez la difficulté du débogage manuel avec les workflows assistés par IA.
3. Débogage avec contexte complet : utilisez la Gemini CLI avec le serveur MCP GKE pour déboguer des applications avec une connaissance complète de l'infrastructure.
4. Étendre les fonctionnalités : apprenez à écrire des compétences personnalisées pour automatiser les workflows.

Remarque sur les sorties LLM

En raison de la nature de cet atelier et du fonctionnement des LLM, les résultats que vous obtiendrez seront probablement différents des exemples de résultats présentés. Il s'agit d'un comportement normal pour l'IA générative. Concentrez-vous sur la compréhension des étapes et du raisonnement fourni par le modèle, plutôt que d'essayer de reproduire exactement le texte ou la mise en forme des exemples.

2. Configuration du projet

Avant de commencer l'atelier, préparez votre environnement. Ouvrez Cloud Shell, sélectionnez votre projet et exécutez les scripts de configuration. C'est parti !

Ouvrir Cloud Shell

Pour cet atelier, utilisez Cloud Shell, un environnement de terminal basé sur un navigateur fourni par Google Cloud. Il est préconfiguré avec tous les outils dont vous avez besoin, y compris Google Cloud CLI (gcloud), kubectl et Gemini CLI, ce qui vous évite de les installer sur votre machine locale.

1. Accédez à la console Google Cloud.
2. En haut à droite de la console, cliquez sur le bouton Activer Cloud Shell (il ressemble à une invite de terminal >_).
3. Une session de terminal s'ouvre en bas de la fenêtre de votre navigateur. Cliquez sur Continuer si vous y êtes invité.

Sélectionner un projet

Dans le terminal Cloud Shell, assurez-vous de travailler dans le bon projet.

1. Sélectionnez un projet existant ou créez-en un spécialement pour cet atelier dans la console.
2. Notez votre ID de projet. Définissez le projet dans votre shell actuel en exécutant : gcloud config set project [YOUR_PROJECT_ID]

Mettre en place l'atelier

Exécutez maintenant les scripts de configuration pour préparer l'environnement et introduire les bugs pour l'atelier.

1. Clonez le dépôt :
    👉💻 Exécutez les commandes suivantes pour cloner uniquement le répertoire de l'atelier :

   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. Accédez au répertoire de l'atelier :
    👉💻 Exécutez :

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

3. Définissez les variables d'environnement
    👉💻 Exécutez les commandes suivantes pour définir votre projet et votre région :

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

4. Exécutez le script de configuration :
    ce script active les API listées ci-dessous, crée un cluster GKE Autopilot et s'assure que les outils requis sont installés.
    👉💻 Exécutez le script à partir du répertoire racine :

   ./setup.sh
   

   Remarque : La création du cluster peut prendre entre 5 et 10 minutes.
5. Initialisez l'état défectueux :
    Pour simuler le scénario dans lequel vos collègues vous ont laissé un environnement défectueux, exécutez le script break.sh. Il copie les fichiers manifestes endommagés dans le répertoire du code de base actif.
    👉💻 Exécutez le script :

   ./break.sh
   

6. Préparez-vous aux exercices pratiques
    : pour empêcher l'IA de tricher (en voyant les solutions), passez au répertoire cymbal-bank pour le reste de l'atelier.
    👉💻 Exécutez :

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

API activées

Le script de configuration active plusieurs API Google Cloud. Voici ce qu'ils font :

• container.googleapis.com: : l'API Google Kubernetes Engine. Elle est requise pour toutes les opérations au niveau du cluster.
• generativelanguage.googleapis.com: : API qui permet à Gemini CLI de communiquer avec les modèles Gemini.
• cloudresourcemanager.googleapis.com: : requis pour inspecter les métadonnées au niveau du projet et gérer les autorisations.
• logging.googleapis.com: : essentiel pour le dépannage, car il permet d'extraire et d'analyser les journaux de vos conteneurs.

3. Phase 0 : Dépannage manuel (sans IA)

Maintenant que vous êtes dans le répertoire cymbal-bank, essayons de trouver les erreurs manuellement. C'est la méthode "difficile". Découvrez les performances de référence avant de laisser l'IA faire le gros du travail. Le dépannage manuel consiste à utiliser des outils standards tels que kubectl pour inspecter l'état du cluster, récupérer les journaux et lire les fichiers YAML afin de détecter les incohérences. C'est souvent lent, fastidieux et nécessite de l'expertise pour faire le lien entre les différents éléments. Cela vous servira de point de référence idéal pour les outils d'IA que vous utiliserez plus tard.

1. Essayez de déployer : voyons ce que Kubernetes pense de ces fichiers manifestes.
    👉💻 Exécutez la commande suivante pour appliquer les fichiers manifestes :

   kubectl apply -f kubernetes-manifests/
   

   Le lancement des pods peut prendre quelques secondes. Vous pouvez vérifier qu'ils sont opérationnels à l'aide de la commande "watch kubectl get pods". Une fois qu'ils sont opérationnels, utilisez ctrl+c pour quitter la surveillance.Vous remarquerez deux pods en échec dans la liste :
   • Le pod frontend affiche une "CreateContainerConfigError". Ce type d'erreur suggère généralement que le conteneur a du mal à charger la configuration requise. Réfléchissez aux ressources externes dont un conteneur peut avoir besoin pour démarrer. Y a-t-il des variables d'environnement, des secrets ou des ConfigMaps qui pourraient être mal configurés ou manquants ? Vous devrez examiner la configuration du pod pour identifier le problème spécifique.
   • Le pod userservice est à l'état "ImagePullBackOff". Lorsque ce message s'affiche, cela signifie généralement que le cluster ne parvient pas à récupérer l'image de conteneur qu'il est censé utiliser. Examinez les détails de la demande d'image : le nom et le tag de l'image sont-ils exactement corrects ? Le registre présente-t-il des problèmes d'autorisation potentiels ? Regardez d'où provient l'image pour voir si vous pouvez identifier la raison de l'échec de la demande.
2. Inspectez les dégâts : utilisez les commandes Kubernetes standards pour identifier les éléments qui ne fonctionnent pas.
   • 👉💻 Vérifiez l'état et le nom des pods :

     kubectl get pods
     

     • Observation : Vous voyez des pods dans ImagePullBackOff, CrashLoopBackOff, Pending ou CreateContainerConfigError.
     • Remarque : Un pod à l'état Running ne signifie pas nécessairement qu'il fonctionne correctement. Par exemple, il peut manquer des vérifications d'état suffisantes (activité/aptitude), ce qui peut entraîner le marquage de l'application comme en cours d'exécution, même si l'application à l'intérieur échoue. Les journaux peuvent nous indiquer des erreurs, même si un pod semble en cours d'exécution. Au total, vous devez corriger 11 erreurs différentes.
   • 👉💻 Décrivez un pod en échec pour afficher les événements (remplacez [POD_NAME] par le nom d'un pod réel) :

     kubectl describe pod [POD_NAME]
     

   • 👉💻 Consultez les journaux d'un pod défaillant pour identifier les erreurs d'application :

     kubectl logs [POD_NAME]
     

3. Le travail de détective : ouvrez les fichiers manifestes dans kubernetes-manifests/ à l'aide de l'éditeur Cloud Shell ou cat dans le terminal. Essayez de corréler les erreurs que vous voyez dans les journaux et les événements avec la configuration des fichiers YAML.Défi : Essayez de corriger manuellement UNE SEULE erreur. Vous devez passer d'un fichier à l'autre pour comprendre le reste de la chaîne de défaillances.

4. Phase 1 : Poser des questions sur le Web (UI Web de Gemini)

Le dépannage manuel étant lent, essayons d'utiliser un assistant IA. L'application Web Gemini est une interface de chat polyvalente et performante. Il excelle dans l'explication de concepts et la génération d'extraits de code. Toutefois, il fonctionne sans aucun contexte concernant votre environnement spécifique. Il ne peut pas voir vos fichiers, inspecter votre cluster ni exécuter de commandes. Vous devez copier et coller manuellement les messages d'erreur et le contenu des fichiers.

1. Accéder à Gemini : ouvrez gemini.google.com dans un nouvel onglet. Vous devrez vous connecter avec votre propre compte Google.
2. Demander de l'aide pour une erreur spécifique : supposons que l'erreur ImagePullBackOff s'affiche sur le pod userservice.
    👉💬 Saisissez cette requête dans l'interface utilisateur Web de 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. Réponse de l'IA : Gemini vous fournit une liste des causes courantes :
   • L'image n'existe pas.
   • Vous ne disposez pas des autorisations nécessaires pour l'extraire.
   • Il y a une faute de frappe.
   Il suggère de vérifier vos autorisations IAM ou votre registre. Toutefois, il ne peut pas savoir que le nom de l'image est userservice (sans le tiret) à moins de voir votre projet.

Le principal point de friction ici est que Gemini n'a aucune visibilité sur votre environnement local. Pour obtenir le contexte dont il a besoin, vous devez le fournir manuellement (en saisissant et en copiant-collant du texte), ce qui prend du temps et peut être source d'erreurs.

5. Phase 2 : Puissance du terminal (Gemini CLI)

Passez maintenant au terminal à l'aide de Gemini CLI. Gemini CLI vous permet d'exploiter la puissance des modèles Gemini directement dans votre terminal. La CLI s'adapte à votre manière de travailler. Il lit les fichiers locaux, accepte les entrées canalisées et exécute même les commandes shell en votre nom (avec votre approbation). Cela le rend incroyablement utile pour intégrer l'IA à vos workflows sans changer de contexte. Pour obtenir des informations plus détaillées et sur l'utilisation avancée, consultez la documentation officielle de Gemini CLI.

Remarque : La CLI Antigravity est désormais officiellement disponible et remplace Gemini CLI. Cet atelier continue d'utiliser Gemini CLI. Pour en savoir plus sur l'interface de ligne de commande Antigravity, consultez la documentation officielle de l'interface de ligne de commande Antigravity.

Contexte et visibilité

Avant de passer aux instructions, notez que la visibilité de l'interface de ligne de commande Gemini dans votre projet dépend de l'endroit où vous la lancez. Le modèle peut voir les fichiers et les dossiers par rapport à votre répertoire de travail actuel. Si vous l'exécutez à partir de la racine de votre projet, il a accès à tous les fichiers de ce projet. Si vous l'exécutez à partir d'un sous-répertoire, sa vue est limitée à ce sous-répertoire et à ses enfants. Assurez-vous toujours d'être dans le bon répertoire avant de demander au modèle d'analyser ou de modifier des fichiers.

Démarrer Gemini CLI

Cloud Shell inclut Gemini CLI par défaut. Il vous suffit de le démarrer pour l'utiliser avec vos fichiers locaux.

1. Accédez au répertoire Cymbal Bank :
    👉💻 Exécutez la commande suivante pour vous assurer d'être dans le bon répertoire :

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

2. Démarrer Gemini CLI
    👉💻 Exécutez la commande suivante pour démarrer Gemini CLI :

   gemini
   

Utiliser Gemini CLI

Tout ce que vous savez de cette application, c'est où trouver le code et qu'il échoue. Découvrons-en plus et voyons comment Gemini peut vous aider à corriger l'application. Commencez par tester sa capacité à explorer le contexte en lui posant une question sur les fichiers d'application qu'il devrait pouvoir voir.

1. Explorer le codebase : demandez à Gemini d'expliquer ce qu'est cette application et ce qu'elle fait.
    👉💬 Saisissez ce prompt dans Gemini CLI
   What is this application and what does it do?
   Gemini CLI lit les fichiers du répertoire actuel et fournit un aperçu général du projet.
2. Essayez de trouver un problème dans le codebase : comme Gemini CLI voit vos fichiers, demandez-lui de trouver une incohérence.
    👉💬 Saisissez ce prompt dans 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 lit les fichiers et repère l'incohérence entre app: contacts-backend et app: contacts. C'est un grand pas en avant par rapport aux phases précédentes.
3. Demandez-lui de corriger le problème :
    👉💬 Saisissez ce prompt dans Gemini CLI :
   Fix the label mismatch in contacts.yaml so the service matches the deployment.
   Gemini CLI vous montre le fichier YAML corrigé ou applique même la modification si vous approuvez la commande.
4. La limite : bien qu'il puisse voir les fichiers, il ne sait toujours pas ce qui s'exécute réellement dans votre cluster. Si un pod échoue en raison d'une erreur d'exécution qui n'est pas évidente dans le fichier YAML statique, il ne peut pas vous aider sans journaux ni état du cluster.

Remarque : Gemini CLI vous demandera votre autorisation lorsque vous exécuterez des commandes ou apporterez des modifications à des fichiers. Vous conservez ainsi le contrôle de votre environnement. Lorsque vous voyez une invite comme celle ci-dessous, vous pouvez appuyer sur "Entrée" pour répondre "1. Autoriser une fois" pour chaque demande d'action. Vous pouvez également appuyer sur la flèche vers le bas, puis sur Entrée pour sélectionner "2. Autoriser pour cette session", ce qui permettra à Gemini CLI d'effectuer cette action de manière autonome, sans vous demander votre autorisation, pendant toute la durée de cette conversation. Toutefois, si vous fermez Gemini CLI et que vous le rouvrez, cette autorisation ne sera plus valable et il vous demandera à nouveau votre autorisation avant d'effectuer une action.

Remarque : Si vous êtes bloqué ou si vous souhaitez recommencer à zéro, vous pouvez réinitialiser les manifestes Kubernetes à leur état initial défectueux à tout moment en exécutant ../break.sh depuis le répertoire cymbal-bank.

Remarque : Si vous atteignez une limite d'utilisation, sélectionnez "Arrêter", puis exécutez /model pour voir quels modèles ont atteint leurs limites et passer à un autre modèle, comme gemini-2.5-flash-lite. Ensuite, demandez au modèle de "continuer" pour poursuivre l'atelier avec le nouveau modèle.

6. Phase 3 : Débogage du contexte complet (CLI Gemini + GKE MCP)

La phase 2 a montré la puissance de l'IA lorsqu'elle peut voir vos fichiers, mais elle était également bruyante. Vous deviez approuver manuellement chaque lecture de fichier et chaque action d'outil, ce qui créait des frictions importantes lors d'une session de débogage complexe. La phase 3 introduit le serveur GKE MCP pour résoudre ce problème, en fournissant à l'IA une "connaissance de l'infrastructure" directe. Cela permet à Gemini de résoudre les problèmes liés aux journaux, aux événements et aux métadonnées avec moins d'interruptions manuelles, ce qui crée un flux de dépannage plus automatisé et cohérent.

Qu'est-ce que MCP ?

Pour comprendre le protocole MCP, il est utile de commencer par comprendre le concept d'outils dans le monde de l'IA. Un outil est essentiellement une fonction ou une application externe qu'un LLM peut utiliser pour effectuer des actions ou récupérer des données auxquelles il n'aurait pas accès autrement, comme consulter la météo, exécuter un script spécifique ou interroger une base de données. Bien que les outils individuels soient puissants, le partage sécurisé et cohérent entre différents agents et environnements d'IA a toujours été un défi. Le protocole MCP résout ce problème en agissant comme une plate-forme standardisée qui peut héberger ces outils et les exposer à n'importe quel client d'IA compatible.

Le Model Context Protocol (MCP) est un protocole Open Source qui permet aux modèles d'IA d'accéder de manière sécurisée à des sources de données et des outils externes. Au lieu d'intégrer en dur chaque outil ou base de données spécifique, MCP fournit une méthode standardisée permettant aux modèles d'interagir avec leur environnement.

Pour afficher les outils disponibles dans Gemini CLI, exécutez /mcp dans Gemini CLI.

Dans cet atelier, le serveur MCP GKE permet à la Gemini CLI d'interagir directement avec votre cluster GKE. Elle peut ainsi inspecter les ressources, lire les journaux et vous aider à résoudre les problèmes en tenant pleinement compte de l'état actuel du cluster. L'IA n'est plus un simple outil d'analyse de code statique, mais un assistant de dépannage actif qui comprend l'état réel de votre infrastructure.

Configurer l'extension GKE MCP

Par défaut, Gemini CLI est un outil à usage général. Configurez le serveur MCP GKE en créant un fichier de configuration.

1. 👉💻 Tout d'abord, quittez Gemini CLI si vous y êtes toujours en saisissant /quit.
2. 👉💻 Exécutez la commande suivante pour créer le répertoire d'extension :

   mkdir -p ~/.gemini/extensions/gke
   

3. 👉💻 Exécutez la commande suivante pour créer le fichier de configuration. Cette commande insère automatiquement votre PROJECT_ID dans le fichier :

   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. 👉💻 Lancez Gemini CLI :

   gemini
   

5. Vérifiez que le serveur MCP est activé en saisissant /mcp dans Gemini CLI.

Demander à Gemini de déboguer à l'aide de l'état du cluster

1. Déboguer le déploiement qui échoue : demandez maintenant à Gemini d'inspecter le cluster et de corriger les fichiers manifestes en fonction de ce qu'il trouve.
    👉💬 Saisissez ce prompt dans 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 utilise les outils MCP pour appeler les commandes kubectl en arrière-plan. Il détecte l'erreur ImagePullBackOff, en explique la cause et suggère la correction appropriée.
2. Résoudre des problèmes complexes : demandez-lui de consulter les journaux pour détecter les erreurs au niveau de l'application.
    👉💬 Saisissez cette requête dans Gemini CLI :
   Check the logs for the 'contacts' pod. Why is it failing to connect to the database?
   Il détecte l'erreur de connexion refusée et la retrace jusqu'à la non-concordance des ports ou des noms de service dans config.yaml !
3. Itérer : continuez à demander à Gemini de corriger les autres problèmes que vous avez identifiés lors de la phase 0.
    👉💬 Saisissez cette requête dans Gemini CLI :
   Check if the service 'contacts' is correctly routing traffic to its pods
    👉💬 Saisissez cette requête dans Gemini CLI :
   Are there any pods failing due to resource limits?

Remarque : Si vous êtes bloqué ou si vous souhaitez recommencer à zéro, vous pouvez réinitialiser les manifestes Kubernetes à leur état initial défectueux à tout moment en exécutant ../break.sh depuis le répertoire cymbal-bank.

7. Phase 4 : Donner les moyens à l'équipe (Agent Skills)

Enfin, étendez les capacités de l'IA pour répondre à vos besoins spécifiques en créant des compétences d'agent personnalisées.

Que sont les compétences d'agent ?

Les compétences d'agent sont des ensembles d'instructions, de scripts et de ressources qui étendent un agent d'IA pour des tâches spécialisées. Elles vous permettent de codifier les normes organisationnelles et d'automatiser les workflows complexes. Une compétence réside dans un répertoire spécifique et contient un fichier SKILL.md qui définit son comportement. En créant des compétences, vous vous assurez que l'IA suit un processus cohérent et reproductible au lieu d'improviser.

Voici à quoi ressemble un répertoire de skills type :

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

Créer une compétence de dépannage Kubernetes

Au lieu de créer ces fichiers manuellement, Gemini CLI offre un moyen puissant de créer des compétences à l'aide du langage naturel.

Imaginez que vous souhaitez créer une compétence appelée k8s-troubleshooter pour automatiser les étapes que vous venez d'effectuer.

1. Créez la compétence à l'aide d'un prompt : vous pouvez demander à Gemini CLI de créer la compétence pour vous, en fonction de ce que vous avez appris aujourd'hui.
    👉💬 Saisissez ce prompt dans 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.
   Comme lorsqu'il appelle un outil ou effectue une action, Gemini CLI devrait vous indiquer que votre prompt a activé sa compétence "skill-creator". Il s'agit d'une compétence préconfigurée dans Gemini CLI qui permet à Gemini de créer des compétences d'agent.
   Gemini devrait vous demander l'autorisation de créer le répertoire des compétences. Approuvez en sélectionnant 1. Autoriser une fois.
   Gemini effectue automatiquement les actions suivantes :
   • Crée un répertoire à l'emplacement ~/.gemini/skills/k8s-troubleshooter/.
   • Génère un fichier SKILL.md contenant des instructions basées sur votre requête.
   • Crée des répertoires de ressources standards.
2. Redémarrez Gemini CLI
    👉💻 Fermez Gemini CLI (/quit), puis redémarrez-le :

   gemini
   

3. Vérifiez que la compétence est chargée :
    👉💻 Vérifiez que la compétence est active en saisissant /skills dans Gemini CLI. Vous devriez voir k8s-troubleshooter dans la liste.
4. Comment cela fonctionne-t-il en pratique ? Maintenant, invoquez la compétence :
    👉💬 Saisissez ce prompt dans Gemini CLI :
   Use the k8s-troubleshooter skill to find out why the contacts service is failing.
    L'IA suit le plan structuré dans SKILL.md au lieu d'improviser, ce qui permet d'obtenir des résultats plus cohérents.

Exercice : Concevoir vos propres compétences

Pensez à votre workflow quotidien. Quelle tâche répétitive pourriez-vous automatiser avec une compétence ?

• Idée : Une compétence permettant d'auditer les fichiers manifestes pour vérifier qu'ils respectent les bonnes pratiques de sécurité avant le déploiement.
• Idée : une compétence permettant de générer des configurations de cluster GKE complexes en fonction du type de charge de travail.

8. Conclusion

Cet atelier présente une nouvelle façon d'interagir avec l'infrastructure cloud en progressant à travers différents niveaux de contexte d'IA. En passant d'un contexte nul à un contexte d'infrastructure complet (Gemini CLI + GKE MCP), vous verrez à quel point un assistant IA devient plus efficace lorsqu'il voit vos fichiers et l'état de votre cluster.

Résumé de l'atelier

• Le contexte est important : vous voyez comment les outils d'IA sans contexte ne peuvent pas aider à résoudre des problèmes spécifiques liés à la base de code.
• Contexte du terminal : vous utilisez Gemini CLI pour analyser les fichiers locaux et identifier les erreurs de configuration directement depuis votre espace de travail.
• Débogage du contexte complet : vous utilisez Gemini CLI avec MCP pour permettre à l'IA de diagnostiquer et de résoudre des problèmes complexes en corrélant les fichiers du code source avec l'état du cluster en direct.
• Extensibilité : vous découvrirez les compétences et comment les utiliser pour codifier les connaissances de l'organisation.

Nettoyage

Pour éviter que des frais ne soient facturés en permanence, exécutez le script de suppression. Notez que cette étape n'est pas nécessaire si vous exécutez l'atelier sur Qwiklabs.

👉💻 Exécutez la commande suivante à partir du répertoire de l'atelier :

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

Étapes suivantes

Voici quelques recommandations de lecture :

• Documentation Gemini CLI : documentation officielle sur Gemini CLI.
• Documentation GKE : page de destination de toute la documentation GKE.
• Ingénierie de plate-forme sur Google Cloud : conseils sur la façon d'aborder l'ingénierie de plate-forme sur Google Cloud.
• IA et machine learning sur GKE : documentation sur l'exécution de charges de travail d'IA/de ML sur GKE.
• Google Cloud Architecture Center : conseils et bonnes pratiques pour créer des charges de travail sur Google Cloud.

9. Annexe : Solution aux problèmes liés au fichier manifeste

Si vous êtes bloqué ou que vous souhaitez vérifier les erreurs, voici la liste des problèmes introduits dans le répertoire manifests-broken/ et comment les résoudre :

1. URL mal formées dans config.yaml :
   • Erreur  : TRANSACTIONS_API_ADDR: "ledgerwriter::8080" (double deux-points).
   • Pourquoi : l'application ne parvient pas à analyser l'adresse, ce qui entraîne des erreurs de connexion.
   • Solution : remplacez-le par "ledgerwriter:8080".
2. Libellés non concordants dans contacts.yaml :
   • Erreur : Le sélecteur de service est défini sur app: contacts-backend au lieu de contacts.
   • Pourquoi : le service ne trouve pas les pods (qui ont toujours app: contacts), donc le trafic ne sera pas acheminé.
   • Solution : Remplacez le sélecteur par app: contacts.
3. Incohérences de ports dans userservice.yaml
   • Erreur : Le service targetPort est défini sur 8081 au lieu de 8080.
   • Pourquoi : le trafic envoyé au service sera transféré vers le mauvais port de conteneur, ce qui entraînera un refus de connexion.
   • Solution : Remplacez targetPort par 8080.
4. Noms de services non concordants dans config.yaml :
   • Erreur  : BALANCES_API_ADDR: "balance-reader:8080" (au lieu de balancereader).
   • Pourquoi : le nom d'hôte ne sera pas résolu dans le DNS, car le service est nommé balancereader.
   • Solution : remplacez-le par "balancereader:8080".
5. Stratégies d'extraction d'images dans contacts.yaml :
   • Erreur  : imagePullPolicy: Never.
   • Pourquoi : K8s n'extrait pas l'image du registre, en supposant qu'elle est locale. Elle échouera avec ErrImagePull.
   • Solution : Supprimez la ligne ou définissez-la sur IfNotPresent.
6. Échecs de la vérification de l'aptitude dans userservice.yaml :
   • Erreur : Le chemin a été remplacé par /healthz au lieu de /ready.
   • Pourquoi : le conteneur ne diffuse pas /healthz. La vérification échoue donc et le pod n'est jamais marqué comme prêt.
   • Solution : Rétablissez le chemin d'accès sur /ready.
7. Limites de ressources dans contacts.yaml :
   • Erreur : La limite de mémoire est définie sur 10Mi au lieu de 128Mi.
   • Pourquoi : l'application a besoin de plus de mémoire pour démarrer, ce qui entraîne son arrêt par manque de mémoire.
   • Solution : Restaurez la limite de mémoire.
8. Variables d'environnement manquantes dans frontend.yaml :
   • Erreur : la variable d'environnement REGISTERED_OAUTH_CLIENT_ID a été supprimée.
   • Pourquoi : l'application peut échouer ou désactiver des fonctionnalités si des variables d'environnement attendues sont manquantes.
   • Correction : Restaurez la définition de la variable d'environnement.
9. Clé ConfigMap non concordante dans frontend.yaml :
   • Erreur  : key: DEMO_USER au lieu de DEMO_LOGIN_USERNAME.
   • Pourquoi : K8s ne trouve pas la clé dans le ConfigMap, ce qui empêche le conteneur de démarrer.
   • Solution : Remplacez la clé par DEMO_LOGIN_USERNAME.
10. Faute de frappe dans le nom de l'image dans userservice.yaml :
    • Erreur  : user-service au lieu de userservice.
    • Pourquoi : l'image n'existe pas dans le registre, ce qui provoque ImagePullBackOff.
    • Solution : Corrigez le nom de l'image.
11. Problèmes liés aux comptes de service dans contacts.yaml :
    • Erreur  : bank-of-anthos-sa au lieu de bank-of-anthos.
    • Pourquoi : le compte de service n'existe pas ou ne dispose pas des autorisations nécessaires.
    • Solution : Utilisez le nom de compte de service correct.