Déployer un cluster Redis sur GKE

Standard

---

Ce tutoriel présente les pratiques recommandées pour la création d'une application avec état et la mise à niveau du cluster Google Kubernetes Engine (GKE) qui exécute cette application. Ce tutoriel utilise Redis comme exemple pour déployer une application avec état, mais les mêmes concepts s'appliquent à d'autres types d'applications avec état déployées sur GKE.

Objectifs

Ce tutoriel couvre les étapes suivantes :

1. Créez un cluster GKE enregistré dans un canal de publication.
2. Créez un cluster Redis sur GKE.
3. Déployez l'application cliente Redis sur GKE.
4. Suivez ces bonnes pratiques pour les mises à niveau du pool de nœuds :
   1. Configurez le budget d'interruption de pod.
   2. Définissez l'intervalle de maintenance et les exclusions.
   3. Configurez la stratégie de mise à niveau de nœuds sur mise à niveau de la surutilisation ou mise à niveau bleu-vert.
5. Testez l'application.
6. Mettez à niveau le cluster.
7. Vérifiez l'effet de la perturbation sur la charge de travail.

Le diagramme suivant montre une vue d'ensemble de l'architecture de cluster pour ce tutoriel :

Coûts

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

• GKE

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

Configurer votre projet

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. In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

   Go to project selector

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

4. Enable the GKE API.

   Enable the API

5. In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

   Go to project selector

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

7. Enable the GKE API.

   Enable the API

Définir des valeurs par défaut pour Google Cloud CLI

1. Dans la console Google Cloud, démarrez une instance Cloud Shell :
   Ouvrir Cloud Shell

2. Téléchargez le code source pour cet exemple d'application :

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
    cd kubernetes-engine-samples/quickstarts/hello-app-redis/manifests
   

3. Définissez les variables d'environnement par défaut :

    gcloud config set project PROJECT-ID
    gcloud config set compute/zone COMPUTE-ZONE
   

   Remplacez les valeurs suivantes :

   • PROJECT_ID : ID de votre projet Google Cloud.
   • COMPUTE_ZONE : zone Compute Engine.

Créer un cluster GKE enregistré dans un canal de publication

Pour créer votre cluster GKE, procédez comme suit :

1. Créez un cluster nommé redis-test avec trois nœuds :

   gcloud container clusters create redis-test \
       --num-nodes=3 \
       --release-channel regular
   

   Une fois le cluster créé, un résultat semblable à l'exemple suivant doit s'afficher :

     NAME: redis-test
     LOCATION: us-central1-c
     MASTER_VERSION: 1.22.10-gke.600
     MASTER_IP: 34.69.67.7
     MACHINE_TYPE: e2-medium
     NODE_VERSION: 1.22.10-gke.600
     NUM_NODES: 3
     STATUS: RUNNING
   

2. Configurez kubectl pour communiquer avec le cluster :

   gcloud container clusters get-credentials redis-test
   

Créer un cluster Redis sur GKE

Dans cette section, vous allez ajouter un cluster Redis sur le cluster GKE que vous avez précédemment créé en déployant un ConfigMap, StatefulSet et Service sans adresse IP de cluster.

Pour créer un cluster Redis, procédez comme suit :

1. Reportez-vous au fichier ConfigMap (redis-configmap.yaml) qui stocke la configuration Redis. L'extrait de code ci-dessous montre la vérification d'aptitude et les scripts de vérification d'activité.

   readiness.sh: |-
     #!/bin/sh
   
     pingResponse="$(redis-cli -h localhost ping)"
     if [ "$?" -eq "124" ]; then
       echo "PING timed out"
       exit 1
     fi
   
     if [ "$pingResponse" != "PONG"]; then
       echo "$pingResponse"
       exit 1
     fi
   liveness.sh: |-
     #!/bin/sh
   
     pingResponse="$(redis-cli -h localhost ping | head -n1 | awk '{print $1;}')"
     if [ "$?" -eq "124" ]; then
       echo "PING timed out"
       exit 1
     fi
   
     if [ "$pingResponse" != "PONG"] && [ "$pingResponse" != "LOADING" ] && [ "$pingResponse" != "MASTERDOWN" ]; then
       echo "$pingResponse"
       exit 1
     fi

   Les scripts readiness.sh et liveness.sh utilisent redis-cli ping pour vérifier si le serveur Redis est en cours d'exécution ou non. S'il renvoie PONG, le serveur Redis est opérationnel. Ces scripts seront utilisés dans le fichier redis-cluster.yaml.

   Pour en savoir plus sur les paramètres Redis de ce fichier ConfigMap, consultez la section dédiée aux paramètres de configuration du cluster dans le tutoriel de création d'un cluster Redis.

2. Déployez le ConfigMap :

   kubectl apply -f redis-configmap.yaml
   

3. Reportez-vous à l'extrait du StatefulSet (redis-cluster.yaml) ci-dessous, qui illustre l'utilisation de la vérification de la préparation et de la vérification d'activité.

   Pour en savoir plus sur la configuration des vérifications dans Kubernetes, consultez l'article Configurer des vérifications.

   startupProbe:
     periodSeconds: 5
     timeoutSeconds: 5
     successThreshold: 1
     failureThreshold: 20
     tcpSocket:
       port: redis
   livenessProbe:
     periodSeconds: 5
     timeoutSeconds: 5
     successThreshold: 1
     failureThreshold: 5
     exec:
       command: ["sh", "-c", "/probes/liveness.sh"]
   readinessProbe:
     periodSeconds: 5
     timeoutSeconds: 1
     successThreshold: 1
     failureThreshold: 5
     exec:
       command: ["sh", "-c", "/probes/readiness.sh"]

   Nous vous recommandons vivement d'utiliser les vérifications d'aptitude et d'activité lors de la mise à niveau des pools de nœuds. Cela garantit que vos pods sont prêts lors d'une mise à niveau.

4. Déployez le StatefulSet :

   kubectl apply -f redis-cluster.yaml
   

5. Le service sans adresse IP de cluster redis-service.yaml sert à connecter les nœuds Redis. Le champ clusterIP est défini sur None afin de créer un service sans adresse IP de cluster.

   Déployez le service :

   kubectl apply -f redis-service.yaml
   

6. Attendez environ deux minutes, puis vérifiez que tous les pods sont en cours d'exécution à l'aide de la commande suivante :

   kubectl get pods
   

   Un résultat semblable aux lignes suivantes doit s'afficher :

   NAME      READY   STATUS              RESTARTS   AGE
   redis-0   1/1     Running             0          2m29s
   redis-1   1/1     Running             0          2m8s
   redis-2   1/1     Running             0          107s
   redis-3   1/1     Running             0          85s
   redis-4   1/1     Running             0          54s
   redis-5   1/1     Running             0          23s
   

7. Vérifiez que les volumes persistants ont bien été créés en exécutant la commande suivante :

   kubectl get pv
   

   Un résultat semblable aux lignes suivantes doit s'afficher :

   NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                  STORAGECLASS   REASON   AGE
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-5   standard                75s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-1   standard                2m59s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-3   standard                2m16s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-2   standard                2m38s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-0   standard                3m20s
   pvc-HASH   1Gi        RWO            Delete           Bound    default/data-redis-4   standard                104s
   

   Dans ce résultat, HASH représente un hachage associé à chaque nom de volume persistant.

Attribuer des rôles à un cluster Redis

Une fois la configuration terminée, attribuez des rôles au cluster Redis.

Le script suivant obtient les adresses IP des pods, puis attribue les rôles de maître et d'esclave en transmettant chacune de ces adresses IP à la commande :

#!/bin/bash
# Usage: ./roles.sh

urls=$(kubectl get pods -l app=redis -o jsonpath='{range.items[*]}{.status.podIP} ')
command="kubectl exec -it redis-0 -- redis-cli --cluster create --cluster-replicas 1 "

for url in $urls
do
    command+=$url":6379 "
done

echo "Executing command: " $command
$command

Pour attribuer des rôles à votre cluster Redis, procédez comme suit :

1. Exécutez le script :

   chmod +x ./roles.sh
   ./roles.sh
   

2. Saisissez yes lorsque vous y êtes invité.

3. Connectez-vous à un nœud Redis pour vérifier son rôle. Par exemple, pour vérifier que redis-0 possède bien un rôle de maître, exécutez la commande suivante :

   kubectl exec -it redis-0 -- redis-cli role
   

   Un résultat semblable aux lignes suivantes doit s'afficher :

   1) "master"
   2) (integer) 574
   3) 1) 1) "10.28.2.3"
          2) "6379"
          3) "574"
   

Déployer l'application cliente Redis

Pour déployer votre application sur le cluster GKE que vous avez créé, définissez un déploiement pour votre application. Le fichier nommé app-deployment.yaml contient la définition de déploiement de l'application.

Pour en savoir plus sur les vérifications et les règles d'affinité de pod utilisées dans ce déploiement, consultez l'article de blog (en anglais) GKE best practices: Designing and building highly available clusters (Bonnes pratiques GKE : concevoir et créer des clusters hautement disponibles).

Pour créer le déploiement, procédez comme suit :

1. Appliquez le déploiement :

   kubectl apply -f app-deployment.yaml
   

2. Exposez l'application via un équilibreur de charge :

   kubectl expose deployment hello-web \
       --type=LoadBalancer \
       --port 80 \
       --target-port 8080
   

3. Attendez environ une minute, puis récupérez l'adresse IP externe de l'application en exécutant la commande suivante :

   kubectl get service
   

   À partir de ce résultat, copiez la valeur répertoriée dans la colonne EXTERNAL-IP de la ligne hello-web's :

   NAME             TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)              AGE
   hello-web        LoadBalancer   10.13.10.55   EXTERNAL_IP   80:30703/TCP         166m
   

4. Vérifiez que l'application fonctionne en collant l'adresse EXTERNAL_IP dans votre navigateur Web. Un résultat semblable aux lignes suivantes doit s'afficher :

   I have been hit [1] times since deployment!
   

   Notez le nombre de visites. Vous en aurez besoin à la section dédiée à la vérification de l'effet de la perturbation sur l'application.

5. Définissez une variable pour le champ EXTERNAL_IP que vous venez de copier. Vous utiliserez cette valeur lorsque vous créerez les scripts servant à tester votre application dans la section suivante :

   export IP=EXTERNAL_IP
   

Configurer les bonnes pratiques de mise à niveau des pools de nœuds

Suivez ces bonnes pratiques pour les applications avec état afin d'optimiser la disponibilité lors des mises à niveau du pool de nœuds.

Configurer le budget d'interruption de pod

Créez un budget d'interruption de pod pour limiter le nombre de pods répliqués indisponibles simultanément lors d'une interruption volontaire. Cela est utile pour les applications avec état qui nécessitent un quorum pour que le nombre d'instances dupliquées soit disponible lors d'une mise à niveau.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: redis-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: redis

Dans une définition PDB :

• app spécifie l'application à laquelle le PDB s'applique.
• minAvailable définit le nombre minimal de pods à rendre disponibles lors d'une interruption. Il peut s'agir d'une valeur ou d'un pourcentage (par exemple, 30 %).
• maxUnavailable définit le nombre maximal de pods pouvant être indisponibles pendant une interruption. Il peut également s'agir d'une valeur ou d'un pourcentage.

Remarque : En fonction du quorum ou de la préférence de l'application, choisissez l'une des options minAvailable ou maxUnavailable correspondant au budget d'interruption de pod.

Remarque : Une fois le PodDisruptionBudget défini, GKE n'arrêtera pas les pods de votre application si le nombre de pods est inférieure ou inférieure à une limite configurée pendant 60 minutes au maximum.

Pour configurer le budget d'interruption de pod, procédez comme suit :

1. Déployez le PDB :

   kubectl apply -f pdb-minavailable.yaml
   

2. Vérifiez que le budget d'interruption de pod a été créé :

   kubectl get pdb
   

Configurer les intervalles de maintenance et les exclusions

Les mises à niveau automatiques des nœuds simplifient le processus de mise à niveau et maintiennent les nœuds du cluster à jour lorsque le plan de contrôle est mis à niveau en votre nom. Cette fonctionnalité est activée par défaut. Pour en savoir plus, consultez la page Mettre à niveau automatiquement des nœuds.

Utilisez des intervalles et des exclusions de maintenance pour définir des périodes et contrôler à quel moment les tâches de maintenance peuvent être effectuées ou non sur les clusters GKE :

1. Configurer un intervalle de maintenance qui commence le 19 août 2022 à 2 h 00 (UTC) et se termine quatre heures plus tard. Cet intervalle de maintenance s'exécute quotidiennement. Pendant cette période, la maintenance automatique est autorisée.

   gcloud container clusters update redis-test \
      --maintenance-window-start 2022-08-19T02:00:00Z \
      --maintenance-window-end 2022-08-19T06:00:00Z \
      --maintenance-window-recurrence FREQ=DAILY
   

2. Configurez un intervalle d'exclusion qui empêche la maintenance pendant le Nouvel An. Cette exclusion de maintenance utilise le niveau d'accès no_upgrades. Pendant cette période, aucune maintenance automatique de quelque type que ce soit n'est autorisée. Pour en savoir plus, consultez la section Champ d'application de la maintenance à exclure.

   gcloud container clusters update redis-test \
      --add-maintenance-exclusion-name new-year \
      --add-maintenance-exclusion-start 2022-12-26T00:00:00Z \
      --add-maintenance-exclusion-end 2023-01-02T02:00:00Z \
      --add-maintenance-exclusion-scope no_upgrades
   

3. Vérifiez que l'intervalle de maintenance et les exclusions sont appliqués. Accéder à maintenancePolicy:

   gcloud container clusters describe redis-test
   

Pour en savoir plus, consultez la section Configurer des intervalles et des exclusions de maintenance.

Configurer une stratégie de mise à niveau de nœuds

Vous pouvez utiliser deux stratégies de mise à niveau de nœuds pour les pools de nœuds de votre cluster GKE : les mises à niveau bleu-vert et les mises à niveau de surutilisation. Pour en savoir plus, consultez la section Stratégies de mise à niveau de nœuds.

Mises à niveau bleu-vert

Choisissez des mises à niveau bleu-vert si les charges de travail sont moins tolérantes aux perturbations, et qu'une augmentation temporaire des coûts due à une utilisation plus élevée des ressources est acceptable.

Exécutez la commande suivante pour passer à une stratégie de mise à niveau bleu-vert pour les pools de nœuds.

gcloud container node-pools update default-pool \
--cluster=redis-test \
--enable-blue-green-upgrade \
--zone COMPUTE-ZONE \
--node-pool-soak-duration=120s

La durée de stabilisation du pool de nœuds est définie sur deux minutes pour gagner du temps pendant la phase de stabilisation du pool de nœuds pour ce tutoriel. Cette phase permet de vérifier l'état de la charge de travail après le drainage des nœuds du pool bleu. Nous vous recommandons de définir la durée de stabilisation du pool de nœuds sur une heure (3 600 secondes) ou sur la durée qui convient le mieux à l'application.

Pour en savoir plus sur la gestion de l'allocation des pods, consultez les pages Déployer un pod sur un pool de nœuds spécifique et Déployer des services sur des pools de nœuds spécifiques.

Pour en savoir plus sur la configuration des mises à niveau bleu-vert, consultez la page Configurer des mises à niveau bleu-vert.

Mises à niveau de la surutilisation

Choisissez les mises à niveau de la surutilisation si l'optimisation des coûts est importante et si les charges de travail peuvent tolérer un arrêt progressif en moins de 60 minutes (GKE respecte le budget d'interruption de pod jusqu'à 60 minutes).

Exécutez la commande suivante pour passer à la stratégie de mise à niveau de la surutilisation des pools de nœuds.

gcloud container node-pools update default-pool \
--max-surge-upgrade=1 \
--max-unavailable-upgrade=0 \
--cluster=redis-test

Avec cette configuration (maxSurge=1 et maxUnavailable=0), un seul nœud de surutilisation peut être ajouté au pool de nœuds lors d'une mise à niveau. Par conséquent, il n'est possible de mettre à niveau qu'un seul nœud. Ce paramètre accélère les redémarrages de pod pendant les mises à niveau tout en permettant une progression prudente.

Pour en savoir plus sur la configuration des mises à niveau de la surutilisation, consultez la page Configurer les mises à niveau de la surutilisation.

Vérifiez la configuration actuelle du pool de nœuds :

   gcloud container node-pools describe default-pool \
   --cluster redis-test \
   --zone COMPUTE-ZONE

Pour en savoir plus sur l'affichage des pools de nœuds, consultez la page Afficher les pools de nœuds dans un cluster.

Tester l'application

Dans cette section, vous utilisez deux scripts : l'un envoie des requêtes à votre application et l'autre mesure le taux de réussite de ces requêtes. Vous utilisez ces scripts afin de mesurer les conséquences d'une mise à niveau de votre cluster.

Pour créer ces scripts, procédez comme suit :

1. Accédez au répertoire contenant les scripts :

   cd
   cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
   

2. Reportez-vous au script nommé generate_load.sh qui envoie une requête de requêtes par seconde à votre application. Le script enregistre le code de réponse HTTP dans le répertoire actuel, dans un fichier nommé output. La valeur de output est utilisée dans le script que vous allez créer à l'étape suivante.

   #!/bin/bash
   # Usage: ./generate_load.sh <IP> <QPS>
   
   IP=$1
   QPS=$2
   
   while true
     do for N in $(seq 1 $QPS)
       do curl -I -m 5 -s -w "%{http_code}\n" -o /dev/null http://${IP}/ >> output &
       done
     sleep 1
   done

3. Reportez-vous au script nommé print_error_rate.sh qui calcule le taux de réussite en fonction du résultat généré par generate_load.sh.

   #!/bin/bash
   # Usage: watch ./print_error_rate.sh
   
   TOTAL=$(cat output | wc -l);
   SUCCESS=$(grep "200" output |  wc -l);
   ERROR1=$(grep "000" output |  wc -l)
   ERROR2=$(grep "503" output |  wc -l)
   ERROR3=$(grep "500" output |  wc -l)
   SUCCESS_RATE=$(($SUCCESS * 100 / TOTAL))
   ERROR_RATE=$(($ERROR1 * 100 / TOTAL))
   ERROR_RATE_2=$(($ERROR2 * 100 / TOTAL))
   ERROR_RATE_3=$(($ERROR3 * 100 / TOTAL))
   echo "Success rate: $SUCCESS/$TOTAL (${SUCCESS_RATE}%)"
   echo "App network Error rate: $ERROR1/$TOTAL (${ERROR_RATE}%)"
   echo "Resource Error rate: $ERROR2/$TOTAL (${ERROR_RATE_2}%)"
   echo "Redis Error rate: $ERROR3/$TOTAL (${ERROR_RATE_3}%)"

4. Accordez-vous l'autorisation d'exécuter les scripts :

   chmod u+x generate_load.sh print_error_rate.sh
   

5. Définissez une variable "QPS" correspondant au nombre de RPS. Cette valeur est utilisée dans le script generate_load.sh, tout comme la variable que vous avez définie pour l'adresse EXTERNAL_IP. Nous vous recommandons de définir une valeur de 40.

   export QPS=40
   

6. Exécutez le script generate_load.sh pour commencer à envoyer des requêtes au taux de RPS défini :

   ./generate_load.sh $IP $QPS 2>&1
   

7. Laissez le script generate_load.sh s'exécuter et ouvrez un nouveau terminal. Dans le nouveau terminal, exécutez le script print_error_rate.sh pour vérifier le taux d'erreur :

   cd
   cd kubernetes-engine-samples/quickstarts/hello-app-redis/scripts
   watch ./print_error_rate.sh
   

   Vous devriez observer un taux de réussite de 100 % et un taux d'erreur de 0 % à mesure que les requêtes par seconde sont effectuées.

8. Laissez les deux scripts s'exécuter et ouvrez un troisième terminal en prévision de la section suivante.

Mettre à niveau le cluster

Pour mettre à niveau le cluster, procédez comme suit :

1. Déterminez la version de GKE utilisée par le cluster redis-test :

   V=$(gcloud container clusters describe redis-test | grep "version:" | sed "s/version: //")
   echo $V
   

   Un résultat semblable à l'exemple suivant doit s'afficher : 1.22.9-gke.2000.

2. Récupérez la liste des versions Kubernetes disponibles :

   gcloud container get-server-config
   

3. Dans la liste des versions, localisez la section validMasterVersions: et recherchez la version de redis-cluster que vous avez récupérée à l'étape précédente. Pour éviter tout décalage de version, copiez la version figurant dans la liste située juste au-dessus de la version de redis-cluster.

4. Mettez à niveau le plan de contrôle du cluster vers la version que vous avez sélectionnée, puis saisissez y lorsque vous y êtes invité :

   gcloud container clusters upgrade redis-test \
       --master \
       --cluster-version VERSION
   

   Remplacez VERSION par la version que vous avez sélectionnée dans la liste à l'étape précédente.

   La mise à niveau du plan de contrôle prend plusieurs minutes.

5. Mettez à niveau les nœuds du cluster vers la version que vous avez sélectionnée, puis saisissez y lorsque vous y êtes invité :

   gcloud container clusters upgrade redis-test \
       --cluster-version=VERSION \
       --node-pool=default-pool
   

   Remplacez VERSION par la version que vous avez sélectionnée dans la liste.

Vérifier l'effet de la perturbation sur la charge de travail

Dans cette section, vous allez tester l'état de votre application et observer une perturbation de la charge de travail.

1. Revenez à la fenêtre de terminal qui exécute ./print_error_rate.sh et observez l'évolution du taux de réussite au cours de la mise à niveau. Vous devriez constater une légère baisse du taux de réussite et une légère augmentation du taux d'erreurs réseau de l'application lorsque les nœuds sont retirés pour être mis à niveau.

   Le champ Success rate indique le nombre de consultations du site Web ayant réussi. Notez cette valeur.

2. Arrêtez l'exécution des deux scripts en saisissant CTRL+C dans les terminaux appropriés.

3. Revenez au site Web de votre application en saisissant dans votre navigateur l'adresse IP associée (il s'agit du champ EXTERNAL_IP que vous avez copié dans la section Déployer l'application cliente Redis).

4. Examinez le nombre de visites de votre application. Le nombre affiché devrait être égal à ce qui suit :

   ORIGINAL_VISIT_NUMBER + SUCCESSFUL_VISIT_NUMBER

   où ORIGINAL_VISIT_NUMBER est le nombre que vous avez enregistré à la dernière étape de la section Déployer l'application cliente Redis et SUCCESSFUL_VISIT_NUMBER est la valeur que vous avez enregistrée à la première étape de cette section.

Effectuer un nettoyage

Une fois le tutoriel terminé, vous pouvez procéder au nettoyage des ressources que vous avez créées afin qu'elles ne soient plus comptabilisées dans votre quota et qu'elles ne vous soient plus facturées. Dans les sections suivantes, nous allons voir comment supprimer ou désactiver ces ressources.

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Pour supprimer le projet :

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Supprimer le cluster

Pour supprimer le cluster que vous avez créé dans le cadre de ce tutoriel, exécutez la commande suivante :

gcloud container clusters delete redis-test

Étapes suivantes

• Bonnes pratiques de mise à niveau des clusters
• Comment configurer les notifications de cluster
• Bonnes pratiques GKE : opérations du jour 2
• Configurer des vérifications d'état avec des vérifications