Déployer Redis sur GKE à l'aide de Redis Enterprise


Ce guide vous explique comment déployer Redis Enterprise sur des clusters Google Kubernetes Engine (GKE).

Redis est une base de données Open Source en mémoire NoSQL principalement utilisée pour la mise en cache. Elle offre une réplication intégrée, des scripts Lua, l'éviction LRU, des transactions, la persistance sur disque et une haute disponibilité.

Redis Enterprise est une solution de niveau entreprise qui étend la base de données Open Source Redis et offre une gestion simplifiée, y compris la distribution des données géo-répliquées, le scaling linéaire du débit des opérations, la hiérarchisation des données, des fonctionnalités de sécurité avancées, etc.

La tarification de Redis Enterprise diffère pour chaque option de déploiement, y compris les suivantes : Logiciels, Cloud ou hybride et multicloud.

Ce guide est destiné aux administrateurs de plate-forme, aux architectes cloud et aux professionnels des opérations qui souhaitent déployer Redis Enterprise sur Google Kubernetes Engine (GKE).

Objectifs

  • Planifier et déployer l'infrastructure GKE pour Redis
  • Déployer l'opérateur Redis Enterprise
  • Déployer un cluster Redis Enterprise
  • Créer une base de données Redis Enterprise
  • Démonstration de l'authentification de la base de données

Avantages

Redis Enterprise offre les avantages suivants :

  • Un moyen Kubernetes natif de gérer le cycle de vie d'un cluster Redis Enterprise (REC) et les bases de données Redis Enterprise (REDB)
  • Une utilisation des ressources en colocalisant plusieurs bases de données Redis dans un même pod Kubernetes
  • Une réduction des frais généraux opérationnels en gérant les tâches de maintenance de routine telles que l'application de correctifs et les mises à niveau
  • Une compatibilité des images logicielles Redis à partir de registres de conteneurs privés, tels qu'Artifact Registry, pour améliorer la sécurité et la disponibilité des conteneurs
  • Une compatibilité avec Google Cloud Managed Service pour Prometheus pour la surveillance et l'observabilité de la base de données
  • Des fonctionnalités de sécurité améliorées telles que le chiffrement, le contrôle des accès et l'intégration à Kubernetes RBAC (contrôle des accès basé sur les rôles)
  • Des méthodes d'authentification avancées, y compris le service LDAP et les gestionnaires d'identifiants tiers tels que Vault
  • La possibilité de configurer des sauvegardes planifiées

Architecture de déploiement

Redis Enterprise gère les ressources Kubernetes suivantes :

  • Cluster Enterprise et sa configuration dans un StatefulSet. Le cluster est constitué de nœuds Redis (pods) avec des packages Redis installés. Ces nœuds disposent de processus en cours d'exécution pour s'assurer qu'ils font partie d'un cluster. Chaque nœud fournit un conteneur pour exécuter plusieurs instances de base de données (fragments). Bien que les bonnes pratiques de Kubernetes stipulent qu'un pod doit représenter une application avec un conteneur, Redis Enterprise déploie plusieurs bases de données Redis vers un seul conteneur. Cette approche offre une meilleure utilisation des ressources, de meilleures performances et un débit réseau plus élevé. Chaque conteneur dispose également d'un proxy à latence nulle pour acheminer et gérer le trafic vers des processus de base de données Redis spécifiques dans un conteneur.
  • Ressource personnalisée RedisEnterpriseDatabase (REDBs) qui représente les instances de base de données Redis créées dans le REC
  • Services Kubernetes qui diffusent des instances REDB en tant que points de terminaison de base de données
  • Un pod contrôleur nommé Service Rigger, qui crée et supprime des points de terminaison de base de données lors de la création ou de la suppression d'une base de données

Dans ce tutoriel, vous allez créer un déploiement un à plusieurs en déployant un REC dans un espace de noms dédié et en utilisant des espaces de noms distincts pour les déploiements d'applications pour une meilleure isolation.

Le schéma suivant décrit les composants de Redis Enterprise et leur interconnexion :

Le schéma montre un exemple d'architecture Redis Enterprise.
Figure 1 : Exemple d'architecture Redis Enterprise.

Dans ce tutoriel, vous allez configurer le cluster Redis Enterprise pour qu'il soit hautement disponible. Pour ce faire, le REC nécessite un nombre impair de nœuds et un minimum de trois nœuds. Vous définissez également des règles d'affinité, d'anti-affinité et des rejets de nœuds qui garantissent que chaque nœud Redis est placé dans un nœud Kubernetes différent et que les nœuds Redis sont répartis uniformément dans le cluster Kubernetes.

L'utilisation de plusieurs nœuds et zones est essentielle pour obtenir un cluster GKE à haute disponibilité, pour les raisons suivantes :

  • Tolérance aux pannes : plusieurs nœuds répartissent la charge de travail sur le cluster. Ainsi, en cas de défaillance d'un nœud, les autres nœuds peuvent prendre le relais, ce qui évite les temps d'arrêt et les interruptions de service.
  • Évolutivité : l'utilisation de plusieurs nœuds permet un scaling horizontal en ajoutant ou en supprimant des nœuds selon les besoins, ce qui garantit une allocation optimale des ressources et permet d'augmenter le trafic ou les demandes.
  • Haute disponibilité : l'utilisation de plusieurs zones au sein d'une région garantit la redondance et réduit le risque de point de défaillance unique. Si toute une zone de disponibilité subit une défaillance, le cluster peut continuer à s'exécuter dans d'autres zones et maintenir la disponibilité du service.
  • Redondance géographique : en répartissant des nœuds entre les régions, les données et les services du cluster sont répartis géographiquement, ce qui permet de résister aux catastrophes naturelles, aux pannes de courant ou à d'autres perturbations locales susceptibles d'affecter une seule zone.
  • Mises à jour et maintenance progressives : en utilisant plusieurs nœuds, vous pouvez effectuer des mises à jour et une maintenance progressives sur des nœuds individuels sans affecter la disponibilité globale du cluster. Cela garantit un service continu tout en vous permettant d'effectuer les mises à jour nécessaires et d'appliquer les correctifs de manière transparente.
  • Contrats de niveau de service (SLA) : Google Cloud fournit, pour les déploiements multizones, des contrats de niveau de service qui garantissent un niveau minimal de temps d'activité et de disponibilité.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Compute Engine, IAM, GKE, and Resource Manager APIs:

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Compute Engine, IAM, GKE, and Resource Manager APIs:

    gcloud services enable compute.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com
  12. Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/compute.securityAdmin, roles/compute.viewer, roles/container.clusterAdmin, roles/container.admin, roles/iam.serviceAccountAdmin, roles/iam.serviceAccountUser

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
    • Replace PROJECT_ID with your project ID.
    • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.

    • Replace ROLE with each individual role.

Configurer votre environnement

Dans ce tutoriel, vous utilisez Cloud Shell pour gérer les ressources hébergées sur Google Cloud. Les logiciels dont vous avez besoin pour ce tutoriel sont préinstallés sur Cloud Shell, y compris kubectl, la gcloud CLI, et Terraform.

Pour configurer votre environnement avec Cloud Shell, procédez comme suit :

  1. Lancez une session Cloud Shell depuis la console Google Cloud en cliquant sur Icône d'activation Cloud Shell Activer Cloud Shell dans la console Google Cloud. Une session s'ouvre dans le volet inférieur de la console Google Cloud.

  2. Définissez les variables d'environnement :

    export PROJECT_ID=PROJECT_ID
    export KUBERNETES_CLUSTER_PREFIX=redis
    export REGION=us-central1
    

    Remplacez PROJECT_ID par votre ID de projet Google Cloud.

  3. Clonez le dépôt GitHub.

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
    
  4. Accédez au répertoire de travail :

    cd kubernetes-engine-samples/databases/redis-enterprise-operator
    

Créer l'infrastructure de votre cluster

Dans cette section, vous allez exécuter un script Terraform pour créer un VPC et un cluster GKE régional, privé, à disponibilité élevée.

Le schéma suivant présente un cluster GKE standard régional privé déployé sur trois zones différentes :

Pour déployer cette infrastructure, exécutez les commandes suivantes à partir de Cloud Shell :

  cd terraform/gke-standard
  export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
  terraform init
  terraform apply -var project_id=${PROJECT_ID}   \
    -var region=${REGION}  \
    -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

Lorsque vous y êtes invité, saisissez yes. L'exécution de cette commande et le passage du cluster à l'état prêt peuvent prendre plusieurs minutes.

Terraform crée les ressources suivantes :

  • Un réseau VPC et un sous-réseau privé pour les nœuds Kubernetes.
  • Un routeur pour accéder à Internet via NAT.
  • Un cluster GKE privé dans la région us-central1.
  • Un pool de nœuds avec autoscaling activé (un à deux nœuds par zone, un nœud par zone au minimum).

Le résultat ressemble à ce qui suit :

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...

Se connecter au cluster

Avec Cloud Shell, configurez kubectl pour communiquer avec le cluster :

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --region ${REGION}

Déployer l'opérateur Redis Enterprise sur votre cluster

Dans cette section, vous allez déployer l'opérateur Redis Enterprise sur votre cluster Kubernetes.

  1. Créez des espaces de noms pour le REC et ses applications :

    kubectl create namespace rec-ns
    kubectl create namespace application
    
  2. Ajoutez un libellé aux espaces de noms :

    kubectl label namespace rec-ns connection=redis
    kubectl label namespace application connection=redis
    
  3. Obtenez la dernière version du bundle d'opérateurs Redis Enterprise :

    VERSION=`curl --silent https://api.github.com/repos/RedisLabs/redis-enterprise-k8s-docs/releases/latest | grep tag_name | awk -F'"' '{print $4}'`
    
  4. Installez l'opérateur Redis Enterprise :

    kubectl apply -n rec-ns -f https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/bundle.yaml
    

    Le résultat ressemble à ce qui suit :

    role.rbac.authorization.k8s.io/redis-enterprise-operator created
    rolebinding.rbac.authorization.k8s.io/redis-enterprise-operator created
    serviceaccount/redis-enterprise-operator created
    service/admission created
    customresourcedefinition.apiextensions.k8s.io/redisenterpriseclusters.app.redislabs.com created
    customresourcedefinition.apiextensions.k8s.io/redisenterprisedatabases.app.redislabs.com created
    customresourcedefinition.apiextensions.k8s.io/redisenterpriseremoteclusters.app.redislabs.com created
    customresourcedefinition.apiextensions.k8s.io/redisenterpriseactiveactivedatabases.app.redislabs.com created
    deployment.apps/redis-enterprise-operator created
    

Déployer un cluster Redis Enterprise

  1. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -n rec-ns -f manifests/01-basic-cluster/rec.yaml
    

    Cette commande peut prendre plusieurs minutes.

  2. Vérifiez l'état du déploiement de REC :

    kubectl get rec -n rec-ns
    

    Le résultat ressemble à ce qui suit :

    NAME      NODES   VERSION    STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE
    gke-rec   3       7.2.4-52   Running   Valid         Valid           4              2023-09-29T20:15:32Z      4m7s
    

    Le cluster est prêt lorsque STATE est défini sur RUNNING.

Facultatif : Configurer le contrôleur d'admission

Vous pouvez éventuellement configurer l'infrastructure pour la validation de la base de données lors du déploiement.

  1. Configurez le contrôleur d'admission et vérifiez si le secret TLS d'admission est présent :

    kubectl get secret admission-tls -n rec-ns
    
  2. Obtenez le certificat :

    export CERT=$(kubectl get secret admission-tls -n rec-ns -o jsonpath='{.data.cert}')
    
  3. Copiez le certificat dans le fichier webhook.yaml :

    sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
    
  4. Déployez le webhook de validation :

    sed -i -e 's/CRT/'$CERT'/g' manifests/01-basic-cluster/webhook.yaml
    

    Le contrôleur d'admission valide la syntaxe de la base de données sur les espaces de noms étiquetés.

  5. Vérifiez le contrôleur d'admission en créant une base de données non fonctionnelle :

    kubectl apply -n rec-ns -f - << EOF
    apiVersion: app.redislabs.com/v1alpha1
    kind: RedisEnterpriseDatabase
    metadata:
      name: redis-enterprise-database
    spec:
      evictionPolicy: illegal
    EOF
    

    Le résultat ressemble à ce qui suit :

    Error from server: error when creating "STDIN": admission webhook "redisenterprise.admission.redislabs" denied the request: 'illegal' is an invalid value for 'eviction_policy'. Possible values are ['volatile-lru', 'volatile-ttl', 'volatile-random', 'allkeys-lru', 'allkeys-random', 'noeviction', 'volatile-lfu', 'allkeys-lfu']
    

Créer des espaces de noms

Par défaut, l'opérateur Redis Enterprise ne dispose d'aucun droit permettant d'effectuer des actions en dehors de son propre espace de noms. Pour autoriser l'opérateur Redis Enterprise à créer des points de terminaison REDB et de base de données dans d'autres espaces de noms, vous devez configurer RBAC.

  1. Appliquez le rôle et la liaison de rôle correspondants dans l'espace de noms de l'application :

    kubectl apply -f manifests/01-basic-cluster/role.yaml -n application
    kubectl apply -f manifests/01-basic-cluster/role-binding.yaml -n application
    
  2. Créez un rôle de cluster et une liaison de rôle de cluster dans l'espace de noms rec-ns :

    kubectl apply -n rec-ns -f manifests/01-basic-cluster/cluster_role.yaml 
    kubectl apply -n rec-ns -f manifests/01-basic-cluster/cluster_role_binding.yaml
    
  3. Modifiez le fichier ConfigMap REC pour ajouter un contrôle sur l'espace de noms de l'application :

    kubectl patch ConfigMap/operator-environment-config --type merge -p '{"data": {"REDB_NAMESPACES_LABEL": "connection=redis"}}' -n rec-ns
    

    Chaque espace de noms libellé comme ConfigMap est corrigé.

  4. Vérifiez l'état des ressources de votre infrastructure Redis dans l'espace de noms rec-ns :

    kubectl get pod,deploy,svc,rec,statefulset,cm,secrets -n rec-ns
    

    Le résultat ressemble à ce qui suit :

    NAME                                             READY   STATUS    RESTARTS        AGE
    pod/gke-rec-0                                    2/2     Running   0               172m
    pod/gke-rec-1                                    2/2     Running   0               171m
    pod/gke-rec-2                                    2/2     Running   0               168m
    pod/gke-rec-services-rigger-5f885f59dc-gc79g     1/1     Running   0               172m
    pod/redis-enterprise-operator-6668ccd8dc-kx29z   2/2     Running   2 (5m58s ago)   5h
    
    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/gke-rec-services-rigger     1/1     1            1           172m
    deployment.apps/redis-enterprise-operator   1/1     1            1           5h
    
    NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)             AGE
    service/admission      ClusterIP   10.52.11.13   <none>        443/TCP             5h
    service/gke-rec        ClusterIP   10.52.5.44    <none>        9443/TCP,8001/TCP   172m
    service/gke-rec-prom   ClusterIP   None          <none>        8070/TCP            172m
    service/gke-rec-ui     ClusterIP   10.52.3.29    <none>        8443/TCP            172m
    
    NAME                                               NODES   VERSION    STATE     SPEC STATUS   LICENSE STATE   SHARDS LIMIT   LICENSE EXPIRATION DATE   AGE
    redisenterprisecluster.app.redislabs.com/gke-rec   3       7.2.4-52   Running   Valid         Valid           4              2023-10-05T11:07:20Z      172m
    
    NAME                       READY   AGE
    statefulset.apps/gke-rec   3/3     172m
    
    NAME                                    DATA   AGE
    configmap/gke-rec-bulletin-board        1      172m
    configmap/gke-rec-health-check          5      172m
    configmap/kube-root-ca.crt              1      5h2m
    configmap/operator-environment-config   1      5h
    
    NAME                   TYPE     DATA   AGE
    secret/admission-tls   Opaque   2      5h
    secret/gke-rec         Opaque   2      172m
    

Déployer des bases de données Redis Enterprise

  1. Créez des bases de données Redis Enterprise dans les espaces de noms de l'application :

    kubectl apply -f manifests/01-basic-cluster/a-rdb.yaml -n application
    
  2. Vérifiez l'état REDB :

    kubectl get redb --all-namespaces
    

    Le résultat ressemble à ce qui suit :

    NAMESPACE       NAME       VERSION   PORT    CLUSTER   SHARDS   STATUS   SPEC STATUS   AGE
    application   app-db   7.2.0     12999   gke-rec   1        active   Valid         15s
    
  3. Vérifiez que les services de chaque REDB sont en cours d'exécution :

    kubectl get svc --all-namespaces
    

    Le résultat ressemble à ce qui suit :

    NAMESPACE      NAME      TYPE          CLUSTER-IP   EXTERNAL-IP                           PORT(S)    AGE
    application  app-db  ExternalName  <none>       redis-12999.rec-ns.svc.cluster.local  12999/TCP  72m
    
  4. Vérifiez que le secret a été créé :

    kubectl get secrets -n application
    

    Le résultat ressemble à ce qui suit :

    NAME            TYPE     DATA   AGE
    redb-app-db   Opaque   3      96m
    

S'authentifier à l'aide de mots de passe

Vous pouvez vous connecter à REDB à l'aide d'un pod avec redis-cli dans l'espace de noms de l'application. Le pod client utilise les secrets disponibles dans l'espace de noms de l'application (REDB) pour établir une connexion.

Les bases de données créées avec le REDB de ressource personnalisée ne sont compatibles qu'avec l'authentification par mot de passe sans LCA.

  1. Créez le pod client :

    kubectl apply -n application -f manifests/03-auth/client_pod.yaml
    
  2. Connectez-vous au pod client :

    kubectl exec -n application -i -t redis-client -c redis-client -- /bin/sh
    
  3. Connectez-vous à la base de données :

    redis-cli -h $SERVICE -p $PORT --pass $PASS
    
  4. Créez une clé :

    SET mykey "Hello World"
    

    Le résultat ressemble à ce qui suit :

    OK
    
  5. Obtenez la clé :

    GET mykey
    

    Le résultat ressemble à ce qui suit :

    "Hello World"
    
  6. Quittez l'interface système du pod.

    exit
    

Comprendre comment Prometheus collecte les métriques pour votre cluster Redis

Le schéma suivant illustre le fonctionnement de la collecte de métriques Prometheus :

Dans le schéma, un cluster privé GKE contient :

  • Un pod Redis qui collecte des métriques sur le chemin / et le port 8070
  • Collecteurs basés sur Prometheus qui traitent les métriques à partir du pod Redis
  • Une ressource PodMonitoring qui envoie des métriques à Cloud Monitoring

L'opérateur Redis Enterprise expose les métriques de cluster au format Prometheus.

  1. Créez le déploiement metrics-proxy :

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/metrics-proxy.yaml
    

    Étant donné que l'opérateur ne fournit qu'un point de terminaison HTTPS avec le certificat autosigné et que la ressource PodMonitoring ne permet pas de désactiver la validation du certificat TLS, utilisez le pod metrics-proxy en sens inverse. Proxy pour ce point de terminaison afin d'exposer les métriques sur le port HTTP.

  2. Créez la ressource PodMonitoring pour récupérer les métriques par labelSelector :

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/pod-monitoring.yaml
    
  3. Dans la console Google Cloud, accédez à la page Tableau de bord des clusters GKE.

    Accéder au tableau de bord des clusters GKE

    Le tableau de bord affiche un taux d'ingestion de métriques différent de zéro.

Créer un tableau de bord

Vous pouvez afficher les métriques en créant un tableau de bord.

  1. Créez le tableau de bord :

    gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json
    

    Le résultat ressemble à ce qui suit :

    Created [f4efbe4e-2605-46b4-9910-54b13d29b3be].
    
  2. Dans la console Google Cloud, accédez à la page Tableaux de bord.

    Accéder à la page Tableaux de bord

  3. Ouvrez le tableau de bord des clusters Redis Enterprise. Le provisionnement automatique du tableau de bord peut prendre plusieurs minutes.

Vérifier les métriques exportées

Pour vérifier les métriques, créez une base de données et examinez les métriques.

  1. Ouvrez le tableau de bord des clusters Redis Enterprise.

  2. Créez une base de données Redis supplémentaire :

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/c-rdb.yaml
    

    Le nombre de bases de données du tableau de bord doit être mis à jour.

  3. Créez un pod client pour vous connecter à la nouvelle base de données :

    kubectl apply -n rec-ns -f manifests/02-prometheus-metrics/client_pod.yaml
    
  4. Connectez-vous au pod client et préparez les variables :

    kubectl exec -it redis-client-c -n rec-ns -- /bin/bash
    
  5. Utilisez l'outil redis-cli pour créer des clés :

    for i in {1..50}; do \
      redis-cli -h $SERVICE -p $PORT -a $PASS \
      --no-auth-warning SET mykey-$i "myvalue-$i"; \
    done
    
  6. Actualisez la page et observez que les graphiques ont été mis à jour pour afficher l'état réel de la base de données.

  7. Quittez l'interface système du pod.

    exit
    

Effectuer un nettoyage

Supprimer le projet

    Delete a Google Cloud project:

    gcloud projects delete PROJECT_ID

Supprimer des ressources individuelles

  1. Définissez les variables d'environnement.

    export PROJECT_ID=${PROJECT_ID}
    export KUBERNETES_CLUSTER_PREFIX=redis
    export REGION=us-central1
    
  2. Exécutez la commande terraform destroy :

    export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
    cd terraform/gke-standard
    terraform destroy -var project_id=${PROJECT_ID}   \
      -var region=${REGION}  \
      -var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}
    

    Lorsque vous y êtes invité, saisissez yes.

  3. Recherchez tous les disques non associés :

    export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,zone)")
    
  4. Supprimez les disques :

    for i in $disk_list; do
      disk_name=$(echo $i| cut -d'|' -f1)
      disk_zone=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
      echo "Deleting $disk_name"
      gcloud compute disks delete $disk_name --zone $disk_zone --quiet
    done
    
  5. Supprimez le dépôt GitHub :

    rm -r ~/kubernetes-engine-samples/
    

Étapes suivantes

  • Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.