Installer Agent Substrate sur GKE

Agent Substrate sur GKE exécute efficacement les charges de travail agentiques sur les clusters GKE : votre application suspend les agents inactifs, et le système les restaure lorsqu'ils doivent agir à nouveau. Agent Substrate sur GKE est un logiciel Open Source que vous pouvez installer sur un cluster GKE Standard. Pour comparer Agent Substrate sur GKE avec Agent Sandbox sur GKE et choisir une architecture pour vos charges de travail d'agent IA, consultez Planifier une architecture pour les charges de travail d'agent IA sur GKE.

Ce document vous aide à préparer votre projet Google Cloud et votre cluster GKE pour Agent Substrate sur GKE, explique comment exécuter le programme d'installation et décrit les ressources créées par l'installation.

Tarifs

Agent Substrate sur GKE est proposé sans frais supplémentaires. Les tarifs de GKE s'appliquent aux ressources que vous créez.

Limites

Agent Substrate sur GKE présente les limites d'installation suivantes :

  • Cloud Shell : vous ne pouvez pas installer Agent Substrate sur GKE dans Cloud Shell, car Cloud Shell fournit 5 Go d'espace de stockage sur disque persistant, ce qui est insuffisant pour l'installation. Vous devez exécuter le programme d'installation sur votre machine locale.
  • Mode du cluster : vous ne pouvez installer Agent Substrate sur GKE que dans des clusters GKE Standard. Les clusters Autopilot ne sont pas compatibles.
  • Version du cluster : le plan de contrôle et les pools de nœuds de votre cluster doivent exécuter GKE version 1.37 ou ultérieure. Les versions antérieures à la version 1.37 ne sont pas compatibles.
  • Canal de publication : vous ne pouvez pas installer Agent Substrate sur GKE dans des clusters enregistrés dans le canal de publication étendu. Le programme d'installation active les API bêta Kubernetes dans votre cluster, et le canal étendu n'est pas compatible avec les API bêta explicitement activées.
  • Types de machines : vous ne pouvez pas utiliser de séries de machines qui s'exécutent sur des architectures de processeur mixtes (telles que les types de machines E2).

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
  • Installez les composants suivants dans la gcloud CLI :
    • kubectl
    • gke-gcloud-auth-plugin
  • Assurez-vous que les outils suivants sont installés sur votre ordinateur local :
    • Git pour cloner le dépôt Agent Substrate.
    • Go pour exécuter les programmes du programme d'installation, qui sont distribués sous forme de code source.
    • make pour lancer le programme d'installation.
    • Docker et son plug-in Buildx pour créer les images de conteneur Agent Substrate sur GKE.
    • sha256sum, zstd, unzip et jq pour configurer l'environnement d'exécution microVM, si vous prévoyez de l'utiliser. Le programme d'installation ne propose pas l'environnement d'exécution microVM si l'un de ces outils est manquant.

  • Pour permettre au programme d'installation de transférer les images qu'il crée, configurez Docker pour qu'il s'authentifie auprès d'Artifact Registry dans la région de votre cluster :

    gcloud auth configure-docker REGION-docker.pkg.dev

    Remplacez REGION par la région de votre cluster, par exemple us-west1. Pour en savoir plus, consultez Configurer l'authentification auprès d'Artifact Registry pour Docker.

  • Étant donné que le programme d'installation agit en votre nom pour activer les API et provisionner les ressources, configurez les Identifiants par défaut de l'application (ADC) en exécutant la commande suivante :

    gcloud auth application-default login

    Pour en savoir plus sur l'authentification avec ADC, consultez Configurer les identifiants par défaut de l'application.

Rôles requis

Pour obtenir les autorisations nécessaires pour installer Agent Substrate sur GKE, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Configuration requise pour les clusters

Si vous laissez le programme d'installation créer un cluster pour vous, il configure automatiquement un cluster qui répond à toutes les exigences d'Agent Substrate sur GKE.

Si vous choisissez d'installer Agent Substrate sur GKE dans un cluster existant, ce cluster doit répondre aux exigences suivantes :

  • S'exécute sur GKE Standard (Agent Substrate sur GKE n'est compatible qu'avec les clusters Standard).
  • Exécute GKE version 1.37 ou ultérieure sur le plan de contrôle et les pools de nœuds. Si le plan de contrôle exécute une version antérieure, mettez d'abord à niveau le plan de contrôle. Ensuite, mettez à niveau tous les pools de nœuds qui exécutent une version antérieure afin que les nœuds puissent installer des certificats de pod dans les pods.
  • Il n'est pas enregistré dans le version disponible Extended. Pour en savoir plus, consultez la section Limites.
  • Utilise GKE Dataplane V2.
  • Utilise des types de machines c3-standard-4 ou plus grands pour les nœuds.

  • Si vous prévoyez d'exécuter plus d'environ 800 bacs à sable simultanés par nœud, le cluster utilise des nœuds dont les limites sont plus élevées dans le noyau Linux pour la surveillance du système de fichiers (inotify) et pour la table de voisinage du protocole ARP (Address Resolution Protocol). Sans ces limites plus élevées, les bacs à sable peuvent ne pas démarrer et la mise en réseau peut s'arrêter. Les nœuds ont besoin des paramètres de noyau suivants :

    • net.ipv4.neigh.default.gc_thresh1 : 4096
    • net.ipv4.neigh.default.gc_thresh2 : 16384
    • net.ipv4.neigh.default.gc_thresh3 : 32768
    • fs.inotify.max_user_instances : 65536
    • fs.inotify.max_user_watches : 1048576

    Le programme d'installation n'applique automatiquement ces paramètres qu'aux clusters qu'il crée. Pour appliquer ces paramètres aux pools de nœuds d'un cluster existant, utilisez une configuration de système de nœuds. Pour en savoir plus, consultez Options de configuration Sysctl.

Installer Agent Substrate sur GKE

Pour installer Agent Substrate sur GKE, exécutez l'une des commandes suivantes dans votre terminal local :

  • Pour l'installer pour vos propres charges de travail, exécutez la commande suivante :

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash

  • Pour installer, puis essayer la démo Counter, exécutez la commande suivante :

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash -s -- --demo

Le programme d'installation interactif vous invite à indiquer vos images de conteneurs, ainsi que les paramètres de votre projet, de votre cluster, de votre espace de stockage et de votre entrée. Le programme d'installation suggère des valeurs par défaut recommandées dans la mesure du possible, que vous pouvez accepter ou personnaliser :

  • Images de conteneur (obligatoire) : lorsque le programme d'installation vous demande de choisir vos images, sélectionnez Build from source (Créer à partir de la source). Le programme d'installation crée les images à partir du dépôt Agent Substrate en amont et les transfère vers un dépôt Artifact Registry de votre projet. Par défaut, le programme d'installation compile la dernière version d'Agent Substrate. Pour créer une autre version, saisissez une branche, un tag ou un SHA de commit complet à partir du dépôt en amont.
  • ID du projet (obligatoire) : spécifiez le projet Google Cloud dans lequel les ressources seront provisionnées. Si vous avez configuré un projet par défaut pour la gcloud CLI, le programme d'installation utilise cet ID de projet.
  • Cluster (obligatoire) : indiquez si vous souhaitez que le programme d'installation crée un cluster GKE avec les valeurs par défaut recommandées ou s'il doit installer Agent Substrate sur GKE dans un cluster existant. Si vous choisissez d'installer sur un cluster existant, vérifiez qu'il répond aux exigences de la section Exigences de cluster.
  • Bucket d'instantanés (facultatif) : spécifiez un nom de bucket Cloud Storage personnalisé ou laissez ce champ vide pour permettre au programme d'installation de créer un bucket par défaut nommé ate-snapshots-<project>-<cluster>-<zone>. Comme le nom par défaut inclut le nom du cluster, les clusters d'un même projet et d'une même zone ne partagent pas de bucket. Un nom personnalisé peut comporter au maximum 56 caractères, car le programme d'installation crée également un bucket d'éléments en ajoutant le suffixe -assets au nom, et les noms de bucket peuvent comporter au maximum 63 caractères. Si le nom par défaut comporte plus de 56 caractères, le programme d'installation le raccourcit et ajoute un hachage.
  • Clients Ingress (obligatoire) : saisissez les ID SPIFFE des charges de travail qui envoient des requêtes à vos acteurs, comme le service de frontend ou le service de backend de votre application. Un ID SPIFFE identifie une charge de travail par l'espace de noms et le compte de service Kubernetes sous lequel ses pods s'exécutent. Par exemple, les pods qui s'exécutent dans l'espace de noms shop en tant que compte de service frontend ont l'ID SPIFFE spiffe://cluster.local/ns/shop/sa/frontend. Comme l'ID ne dépend que de l'espace de noms et du compte de service, vous pouvez saisir les ID des clients que vous n'avez pas encore déployés. Séparez les différents ID par une virgule. Les requêtes atteignent vos acteurs via un routeur d'entrée, qui n'admet que les clients présentant un certificat de pod dont l'ID SPIFFE figure sur cette liste. N'importe quel client de la liste peut contacter n'importe quel acteur. Si vous incluez l'option --demo, le programme d'installation n'autorise que les pods de la démonstration Counter au lieu de demander des ID. Pour ajouter des clients après l'installation, consultez Atteindre les acteurs via le routeur d'entrée dans le fichier README de substrate-gke.

Ce que fait le programme d'installation

Le programme d'installation exécute les programmes suivants en votre nom :

  • setup-gcp : crée ou vérifie les ressources Google Cloud requises, active les API, crée le cluster GKE (si vous avez choisi de ne pas utiliser de cluster existant) et le bucket Cloud Storage, et configure les stratégies IAM.
  • ate-setup : déploie Agent Substrate sur les images de conteneurs et les contrôleurs GKE de votre cluster GKE.

Tout d'abord, le programme d'installation apporte les modifications suivantes à votre projet Google Cloud  :

  1. Active les API Google Cloud dont Agent Substrate sur GKE a besoin.
  2. Crée un cluster GKE Standard (si vous n'utilisez pas de cluster existant) qui exécute la version 1.37 ou une version ultérieure et qui présente les paramètres suivants :
    • Fédération d'identité de charge de travail pour GKE : permet à Agent Substrate sur GKE d'accéder à Cloud Storage sans stocker de clés sur les nœuds.
    • GKE Dataplane V2 : gère la mise en réseau requise pour acheminer les requêtes entrantes vers vos agents.
    • OpenTelemetry géré : collecte les métriques et les traces de votre cluster.
  3. Crée les buckets Cloud Storage qu'Agent Substrate sur GKE utilise : un pour vos instantanés et un pour les fichiers dont l'environnement d'exécution microVM a besoin. Le nom du deuxième bucket est le nom du bucket d'instantanés suivi du suffixe -assets.
  4. Crée un dépôt Artifact Registry nommé ate-images pour les images de conteneurs créées par le programme d'installation.
  5. Crée un compte de service nommé ate-snapshot-transfer qu'Agent Substrate sur GKE utilise pour transférer des instantanés.
  6. Accorde aux nœuds GKE, aux composants Agent Substrate sur GKE et au compte de service ate-snapshot-transfer les autorisations IAM dont ils ont besoin pour accéder aux buckets et aux images de conteneurs.
  7. Crée des tableaux de bord Cloud Monitoring qui représentent graphiquement la latence de routage, la taille des instantanés et le trafic gRPC d'Agent Substrate sur GKE.

Ensuite, le programme d'installation apporte les modifications suivantes à votre cluster :

  1. Ajoute les ressources personnalisées Agent Substrate sur GKE Kubernetes à votre cluster, telles que WorkerPool (qui définit le nombre de bacs à sable inactifs qui restent prêts) et SandboxConfig (qui définit un environnement d'exécution de bac à sable). Les autres ressources Agent Substrate sur GKE, telles que ActorTemplate (qui définit les images de conteneurs et les ressources utilisées par vos agents) et les acteurs, ne sont pas des ressources Kubernetes. Vous les gérez via l'API Agent Substrate sur GKE à l'aide du plug-in kubectl ate, un plug-in kubectl permettant de gérer les acteurs et les nœuds de calcul. Pour installer le plug-in, consultez Installer le plug-in kubectl ate.
  2. Configure les autorités de certification qui émettent les certificats identifiant Agent Substrate sur les composants GKE et vos acteurs. Les composants présentent ces certificats pour s'authentifier les uns auprès des autres à l'aide de mTLS.
  3. Déploie les composants Agent Substrate sur GKE sur votre cluster, ainsi qu'une base de données PostgreSQL qui suit l'état de vos acteurs et de vos nœuds de calcul. La base de données stocke ses données sur un disque persistant de 500 Gio. Le programme d'installation attend que la base de données et tous les pods du plan de contrôle soient prêts. Pour les clusters de production, vous pouvez isoler la base de données PostgreSQL et les composants de l'infrastructure système sur des pools de nœuds dédiés avant d'exécuter le programme d'installation. Pour obtenir des instructions, consultez Isoler l'infrastructure système et les pools de nœuds de calcul.

Agent Substrate sur GKE déploie ses composants en tant que charges de travail ordinaires dans les espaces de noms ate-system et podcertificate-controller-system. Si vous effectuez l'installation dans un cluster existant, le programme d'installation met également à jour le cluster pour activer les fonctionnalités suivantes si elles sont désactivées : Workload Identity Federation pour GKE, Managed OpenTelemetry et les versions bêta des API Kubernetes podcertificaterequests et clustertrustbundles. L'activation des API bêta met à jour le plan de contrôle GKE, ce qui prend environ 10 minutes.

Les composants déployés incluent l'environnement d'exécution basé sur gVisor qu'Agent Substrate sur GKE utilise par défaut pour isoler chacun de vos agents du nœud sur lequel il s'exécute. Si vous choisissez l'environnement d'exécution microVM lors des étapes facultatives, le programme d'installation importe également les fichiers dont l'environnement d'exécution microVM a besoin dans Cloud Storage et applique une ressource SandboxConfig à l'échelle du cluster nommée microvm qui pointe vers ces fichiers.

Les nœuds de calcul qui utilisent l'environnement d'exécution microVM ont besoin de nœuds capables d'exécuter des machines virtuelles. Lorsque le programme d'installation crée un cluster, la virtualisation imbriquée est activée sur le pool de nœuds qu'il crée. Si vous choisissez la configuration Avancée et modifiez le type de machine, choisissez une série de machines compatible avec la virtualisation imbriquée, comme C3, C4, N2 ou N4.

Si vous installez Agent Substrate sur GKE dans un cluster existant, le programme d'installation n'ajoute pas de pools de nœuds au cluster. Pour utiliser l'environnement d'exécution microVM, le cluster doit disposer d'un pool de nœuds sur lequel la virtualisation imbriquée est activée ou qui utilise un type de machine Bare Metal x86. Vous ne pouvez activer la virtualisation imbriquée que lorsque vous créez un pool de nœuds. Si le cluster ne dispose pas d'un tel pool de nœuds, le programme d'installation vous avertit lorsque vous choisissez l'environnement d'exécution microVM. Si vous continuez, les nœuds de calcul microVM resteront à l'état Pending. Pour en savoir plus sur la configuration de ces pools de nœuds, y compris les rejets, consultez la section Environnements d'exécution de bac à sable dans le fichier README de substrate-gke.

Si l'installation échoue à un moment donné (par exemple, en raison d'une erreur réseau temporaire ou de l'expiration du jeton), exécutez à nouveau la commande. Le programme d'installation conserve les ressources existantes et reprend là où il s'était arrêté.

Pour mettre à niveau une installation existante d'Agent Substrate sur GKE, exécutez le programme d'installation et sélectionnez Mettre à niveau un cluster installé. Cette option ne modifie pas votre cluster. À la place, le programme d'installation télécharge le code source de la version installée et de la version vers laquelle vous effectuez la mise à niveau, puis prépare le répertoire ~/ate-upgrade utilisé par le runbook de mise à niveau. Pour effectuer la mise à niveau, exécutez la commande affichée par le programme d'installation, puis suivez le runbook de mise à niveau dans le dépôt Agent Substrate en amont de la première étape. Le runbook est compatible avec les mises à niveau vers une version de correctif ultérieure de la même version mineure et, pour la version 1.0 et les versions ultérieures, vers la version mineure suivante. Pour les versions antérieures à la version 1.0, le passage à une version mineure ultérieure nécessite une réinstallation. Pour en savoir plus, consultez la section Mettre à niveau un cluster installé dans le fichier README de substrate-gke.

Étapes facultatives

Après avoir déployé les composants principaux, le programme d'installation propose les étapes facultatives suivantes :

  • Pilote CSI Filestore : installe le pilote CSI Filestore configuré pour Agent Substrate sur GKE. Choisissez cette option si vos agents ont besoin d'un stockage persistant qui reste disponible lorsqu'un agent reprend sur un autre nœud. Chaque agent dispose de son propre espace de stockage, qui n'est pas partagé avec les autres agents. La compatibilité en production des volumes d'agent Filestore est en disponibilité générale limitée. Vous devez donc demander l'accès. Pour en savoir plus, consultez Utiliser des volumes d'agent Filestore avec Agent Substrate sur GKE. Si le module complémentaire Filestore GKE géré est activé sur votre cluster, le programme d'installation le désactive avant de déployer le pilote. Le programme d'installation déploie le pilote dans l'espace de noms gcp-filestore-csi-driver et crée un compte de service nommé substrate-filestore-csi, qui dispose des autorisations IAM dont le pilote a besoin.
  • Autoscaling du pool de nœuds : active l'autoscaling de cluster GKE sur votre pool de nœuds. Vous spécifiez le nombre minimal et maximal de nœuds pour le pool. Choisissez cette option si vous souhaitez que GKE ajoute automatiquement des nœuds lors des pics de demande et supprime des nœuds lorsque les agents sont suspendus. Ignorez cette option si vous préférez un nombre de nœuds fixe avec des coûts de calcul prévisibles. Pour configurer le remplacement matériel automatisé avec des ComputeClasses personnalisées, des tampons de capacité de secours et des protections contre le scaling à la baisse pour les acteurs actifs, consultez Concevoir votre infrastructure pour Agent Substrate sur GKE.
  • Environnement d'exécution du bac à sable : vous permet de choisir l'environnement d'exécution qui isole vos agents. Le programme d'installation installe l'environnement d'exécution gVisor dans le cadre des composants principaux. Par conséquent, l'environnement d'exécution gVisor ne nécessite aucune configuration supplémentaire. Si vous souhaitez une isolation qui utilise la virtualisation matérielle, choisissez l'environnement d'exécution microVM. Avant de choisir cette option pour un cluster existant, assurez-vous que le cluster dispose d'un pool de nœuds pour lequel la virtualisation imbriquée est activée ou qui utilise un type de machine Bare Metal x86. Pour en savoir plus, consultez Fonctionnement du programme d'installation.
  • Démo de compteur : déploie un exemple de charge de travail qui illustre la suspension et la restauration de l'agent. Cette étape n'apparaît que si vous incluez l'option --demo lorsque vous lancez le programme d'installation. Choisissez cette option si vous souhaitez tester le cluster après l'installation. Pour en savoir plus, consultez Essayer la démo Counter.

Vérifier l'installation

Pour vérifier que l'installation a réussi et que les composants principaux sont en cours d'exécution, exécutez les commandes suivantes et assurez-vous que tous les pods ont l'état Running :

kubectl get pods -n ate-system
kubectl get pods -n podcertificate-controller-system

Installer le plug-in kubectl ate

Pour gérer les acteurs et les ressources ActorTemplate, installez le plug-in kubectl ate à partir du code source de la version d'Agent Substrate que vous avez installée :

git clone --depth 1 --branch VERSION https://github.com/agent-substrate/substrate.git
cd substrate
go install ./cmd/kubectl-ate

Remplacez VERSION par la version d'Agent Substrate que vous avez installée, par exemple v1.0.0, la version par défaut du programme d'installation.

La commande go install place le plug-in dans le répertoire bin de votre espace de travail Go. L'outil kubectl ne trouve le plug-in que si ce répertoire se trouve dans votre variable d'environnement PATH. Si votre variable d'environnement PATH n'inclut pas ce répertoire, ajoutez-le avant d'exécuter des commandes kubectl ate :

export PATH="$PATH:$(go env GOPATH)/bin"

Essayer la démo de compteur

Si vous avez inclus l'option --demo lors de l'exécution du programme d'installation et que vous avez choisi de déployer la démonstration Counter, le programme d'installation déploie un WorkerPool et un ActorTemplate pour un serveur Web qui compte les requêtes en mémoire et dans un fichier. Agent Substrate sur GKE conserve ces deux nombres lorsque vous suspendez et restaurez l'acteur qui exécute le serveur.

Après l'installation, le programme d'installation affiche les étapes suivantes de la démonstration : une commande qui installe le plug-in kubectl ate et une commande qui crée un acteur à partir de ActorTemplate. Avant d'exécuter des commandes kubectl ate, assurez-vous que le plug-in se trouve dans votre variable d'environnement PATH, comme décrit dans Installer le plug-in kubectl ate.

Le programme d'installation n'affiche pas de commande qui envoie des requêtes à l'acteur. Le routeur d'entrée n'accepte que les clients qui présentent un certificat de pod dont l'ID SPIFFE figure sur sa liste d'autorisation. Il refuse donc les requêtes que vous envoyez directement depuis votre ordinateur local. Pour en savoir plus sur la démonstration, consultez le fichier README de la démonstration Counter pour la version 1.0.0 d'Agent Substrate, que le programme d'installation déploie par défaut. Dans un cluster configuré par le programme d'installation, les étapes du fichier README qui envoient des requêtes via un transfert de port ne fonctionnent pas, pour la même raison.

Désinstaller Agent Substrate sur GKE

Une fois l'installation terminée, le programme d'installation affiche des commandes de nettoyage personnalisées pour votre environnement.

Pour supprimer les ressources créées lors de l'installation, choisissez l'une des options suivantes :

  • Supprimer Agent Substrate sur GKE d'un cluster existant : si vous l'avez installé sur un cluster existant et que vous souhaitez conserver le cluster et ses autres charges de travail, supprimez uniquement les composants Agent Substrate sur GKE en exécutant la commande ate-setup delete ate-system affichée par le programme d'installation. Le programme d'installation préremplit cette commande avec les valeurs de projet, de cluster et d'emplacement configurées lors de l'installation.

  • Supprimer toutes les ressources (y compris le cluster) : pour supprimer le cluster GKE, les buckets d'instantanés et d'éléments, le compte de service ate-snapshot-transfer, les liaisons IAM, les tableaux de bord et le dépôt Artifact Registry ate-images, exécutez la commande cleanup-gcp affichée par le programme d'installation. Le programme d'installation préremplit cette commande avec les valeurs de projet, de cluster, d'emplacement et de bucket configurées lors de l'installation. Étant donné que la commande exécute le script tools/cleanup-gcp à l'aide d'un chemin relatif, exécutez la commande à partir du répertoire dans lequel le programme d'installation a cloné le dépôt substrate-gke. Par défaut, le programme d'installation clone le dépôt dans le répertoire ~/.substrate-gke.

    Si d'autres clusters du projet exécutent Agent Substrate sur GKE, ajoutez l'option --cluster-scoped à la commande. Cette option conserve les tableaux de bord, le compte de service ate-snapshot-transfer et les liaisons IAM au niveau du projet, qui sont partagés par ces clusters. L'option --cluster-scoped ne conserve pas le dépôt ate-images. Si d'autres clusters de la même région utilisent le dépôt ate-images, ajoutez également l'option --keep-repository à la fin de la commande. Pour en savoir plus, consultez la section "Tearing down" (Suppression) du fichier README substrate-gke.

La commande cleanup-gcp ne supprime pas les ressources suivantes :

  • Le disque persistant de la base de données PostgreSQL : GKE conserve les disques persistants lorsqu'il supprime un cluster. Vous continuez donc à payer pour le disque de 500 Gio. Pour supprimer le disque, exécutez la commande ate-setup delete ate-system affichée par le programme d'installation. Ensuite, attendez que la commande kubectl get pv ne liste plus de volume pour la revendication ate-system/data-postgres-0 avant d'exécuter cleanup-gcp. Si vous avez déjà supprimé le cluster, recherchez le disque en exécutant la commande suivante, puis supprimez-le en exécutant la commande gcloud compute disks delete :

    gcloud compute disks list --filter="description~data-postgres-0"

  • Le compte de service substrate-filestore-csi : tous les clusters du projet qui exécutent le pilote CSI Filestore partagent ce compte de service. Si vous avez installé le pilote et qu'aucun autre cluster du projet ne l'exécute, supprimez le compte de service en exécutant la commande suivante :

    gcloud iam service-accounts delete substrate-filestore-csi@PROJECT_ID.

    Remplacez PROJECT_ID par l'ID du projet.

Étapes suivantes