Exécuter des charges de travail full stack à grande échelle sur GKE

Autopilot

Ce tutoriel explique comment exécuter à grande échelle une application Web reposant sur une base de données relationnelle à disponibilité élevée dans Google Kubernetes Engine (GKE).

L'exemple d'application utilisé dans ce tutoriel est Bank of Anthos, une application Web basée sur HTTP qui simule le réseau de traitement des paiements d'une banque. Bank of Anthos utilise plusieurs services pour fonctionner. Ce tutoriel se concentre sur l'interface du site Web et les bases de données relationnelles PostgreSQL sur lesquelles reposent les services de Bank of Anthos. Pour en savoir plus sur Bank of Anthos, y compris son architecture et les services qu'elle déploie, consultez la page Bank of Anthos sur GitHub.

Objectifs

Créer et configurer un cluster GKE
Déployer un exemple d'application Web et une base de données PostgreSQL à disponibilité élevée.
Configurer l'autoscaling de l'application Web et de la base de données.
Simuler des pics de trafic à l'aide d'un générateur de charge.
Observer comment les services évoluent à la hausse ou à la baisse.

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

Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

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.

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer l'API GKE :

gcloud services enable container.googleapis.com

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

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.

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer l'API GKE :

gcloud services enable container.googleapis.com

Installez la CLI Helm.

Préparer l'environnement

Clonez l'exemple de dépôt utilisé dans ce tutoriel :

git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
cd bank-of-anthos/

Définissez les variables d'environnement :

PROJECT_ID=PROJECT_ID
GSA_NAME=bank-of-anthos
GSA_EMAIL=bank-of-anthos@${PROJECT_ID}.iam.gserviceaccount.com
KSA_NAME=default

Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

Configurer le cluster et les comptes de service

Créez un cluster :
```
gcloud container clusters create-auto bank-of-anthos --region=us-central1
```
Le démarrage du cluster peut prendre jusqu'à cinq minutes.

Créez un compte de service IAM :

gcloud iam service-accounts create bank-of-anthos

Révoquez l'accès au compte de service IAM :

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/cloudtrace.agent \
  --member "serviceAccount:bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/monitoring.metricWriter \
  --member "serviceAccount:bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com"
gcloud iam service-accounts add-iam-policy-binding "bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com" \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[default/default]"

Cette étape accorde l'accès suivant :

roles/cloudtrace.agent : écrit des données de trace, telles que des informations de latence, dans Trace.
roles/monitoring.metricWriter : écrit des métriques dans Cloud Monitoring.
roles/iam.workloadIdentityUser : autorise un compte de service Kubernetes à utiliser la fédération d'identité de charge de travail pour GKE pour agir en tant que compte de service IAM.

Configurez le compte de service Kubernetes default dans l'espace de noms default pour qu'il agisse en tant que compte de service IAM que vous avez créé :
```
kubectl annotate serviceaccount default \
    iam.gke.io/gcp-service-account=bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com
```
Cela permet aux pods qui utilisent le compte de service Kubernetes default dans l'espace de noms default d'accéder aux mêmes ressources Google Cloud que le compte de service IAM.

Déployer Bank of Anthos et PostgreSQL

Dans cette section, vous installez Bank of Anthos et une base de données PostgreSQL en mode haute disponibilité, ce qui vous permet d'effectuer l'autoscaling des instances dupliquées du serveur de base de données. Si vous souhaitez afficher les scripts, le chart Helm et les fichiers manifestes Kubernetes utilisés dans cette section, consultez le dépôt Bank of Anthos sur GitHub.

Déployez le schéma de base de données et un script LDD (langage de définition de données) :

kubectl create configmap initdb \
    --from-file=src/accounts/accounts-db/initdb/0-accounts-schema.sql \
    --from-file=src/accounts/accounts-db/initdb/1-load-testdata.sql \
    --from-file=src/ledger/ledger-db/initdb/0_init_tables.sql \
    --from-file=src/ledger/ledger-db/initdb/1_create_transactions.sh

Installez PostgreSQL en utilisant l'exemple de chart Helm :
```
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install accounts-db bitnami/postgresql-ha \
    --version 10.0.1 \
    --values extras/postgres-hpa/helm-postgres-ha/values.yaml \
    --set="postgresql.initdbScriptsCM=initdb" \
    --set="postgresql.replicaCount=1" \
    --wait
```
Cette commande crée un cluster PostgreSQL avec un nombre d'instances dupliquées de démarrage égal à 1. Plus loin dans ce tutoriel, vous effectuerez le scaling du cluster en fonction des connexions entrantes. Cette opération peut prendre dix minutes ou plus.

Déployer Bank of Anthos :

kubectl apply -f extras/jwt/jwt-secret.yaml
kubectl apply -f extras/postgres-hpa/kubernetes-manifests

Cette opération peut durer quelques minutes.

Point de contrôle: valider votre configuration

Vérifiez que tous les pods de la Banque d'Anthos sont en cours d'exécution :

kubectl get pods

Le résultat ressemble à ce qui suit :

NAME                                  READY   STATUS
accounts-db-pgpool-57ffc9d685-c7xs8   3/3     Running
accounts-db-postgresql-0              1/1     Running
balancereader-57b59769f8-xvp5k        1/1     Running
contacts-54f59bb669-mgsqc             1/1     Running
frontend-6f7fdc5b65-h48rs             1/1     Running
ledgerwriter-cd74db4cd-jdqql          1/1     Running
pgpool-operator-5f678457cd-cwbhs      1/1     Running
transactionhistory-5b9b56b5c6-sz9qz   1/1     Running
userservice-f45b46b49-fj7vm           1/1     Running

Vérifiez que vous pouvez accéder à l'interface du site Web :
1. Recherchez l'adresse IP externe du service frontend :
```
kubectl get ingress frontend
```
  Le résultat ressemble à ce qui suit :
```
NAME       CLASS    HOSTS   ADDRESS         PORTS   AGE
frontend   <none>   *       203.0.113.9     80      12m
```
2. Dans un navigateur, accédez à l'adresse IP externe. La page de connexion à "Bank of Anthos" s'affiche. Si vous êtes curieux, explorez l'application.
  
  Si vous obtenez une erreur 404, attendez quelques minutes que les microservices soient provisionnés, puis réessayez.

Procéder à l'autoscaling de l'application Web et de la base de données PostgreSQL

GKE Autopilot effectue l'autoscaling des ressources de calcul du cluster en fonction du nombre de charges de travail qu'il contient. Pour adapter automatiquement le nombre de pods du cluster en fonction des métriques liées aux ressources, vous devez mettre en œuvre l'autoscaling horizontal des pods Kubernetes. Vous pouvez utiliser les métriques de processeur et de mémoire intégrées de Kubernetes ou utiliser des métriques personnalisées, telles que le nombre de requêtes HTTP par seconde ou la quantité d'instructions SELECT issues de Cloud Monitoring.

Dans cette section, vous allez exécuter les opérations suivantes :

Configurez l'autoscaling horizontal des pods pour les microservices de Bank of Anthos à l'aide de métriques intégrées et de métriques personnalisées.
Simulez la charge vers l'application Bank of Anthos pour déclencher des événements d'autoscaling.
Observez comment le nombre de pods et de nœuds de votre cluster évolue automatiquement en fonction de la charge.

Configurer la collecte de métriques personnalisées

Pour lire des métriques personnalisées depuis Monitoring, vous devez déployer l'adaptateur Métriques personnalisées – Adaptateur Stackdriver dans votre cluster.

Déployez l'adaptateur :

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml

Configurez l'adaptateur pour utiliser la fédération d'identité de charge de travail pour GKE afin d'obtenir des métriques :

Configurez le compte de service IAM :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer
gcloud iam service-accounts add-iam-policy-binding bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"

Annotez le compte de service Kubernetes utilisé par l'adaptateur :

kubectl annotate serviceaccount custom-metrics-stackdriver-adapter \
    --namespace=custom-metrics \
  iam.gke.io/gcp-service-account=bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com

Redémarrez le déploiement de l'adaptateur pour propager les modifications :

kubectl rollout restart deployment custom-metrics-stackdriver-adapter \
    --namespace=custom-metrics

Configurer l'autoscaling pour la base de données

Lorsque vous avez déployé Bank of Anthos and PostgreSQL plus tôt dans ce tutoriel, vous avez déployé la base de données en tant que StatefulSet avec une instance dupliquée principale en lecture/écriture pour gérer toutes les instructions SQL entrantes. Dans cette section, vous allez configurer l'autoscaling horizontal des pods pour ajouter de nouvelles instances dupliquées de secours en lecture seule afin de gérer les instructions SELECT entrantes. Un bon moyen de réduire la charge sur chaque instance dupliquée consiste à distribuer des instructions SELECT, qui sont des opérations de lecture. Le déploiement PostgreSQL inclut un outil nommé Pgpool-II qui effectue cet équilibrage de charge et améliore le débit du système.

PostgreSQL exporte la métrique de l'instruction SELECT en tant que métrique Prometheus. Vous utiliserez un exportateur de métriques léger nommé prometheus-to-sd pour envoyer ces métriques à Cloud Monitoring dans un format compatible.

Examinez l'objet HorizontalPodAutoscaler :

# Copyright 2022 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: accounts-db-postgresql
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 5
      selectPolicy: Max
  scaleTargetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: accounts-db-postgresql
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: External
    external:
      metric:
        name: custom.googleapis.com|mypgpool|pgpool2_pool_backend_stats_select_cnt
      target:
          type: AverageValue
          averageValue: "15"

Ce fichier manifeste effectue les opérations suivantes :

Définit le nombre maximal d'instances dupliquées lors d'un scaling à la hausse jusqu'à 5.
Définit le nombre minimal d'instances dupliquées pendant un scaling à la baisse sur 1.
Utilise une métrique externe pour prendre des décisions de scaling. Dans cet exemple, la métrique correspond au nombre d'instructions SELECT. Un événement de scaling à la hausse se produit si le nombre d'instructions SELECT entrantes dépasse 15.

Appliquez le fichier manifeste au cluster :

kubectl apply -f extras/postgres-hpa/hpa/postgresql-hpa.yaml

Configurer l'autoscaling pour l'interface Web

Dans Déployer Bank of Anthos et PostgreSQL, vous avez déployé l'interface Web de Bank of Anthos. Lorsque le nombre d'utilisateurs augmente, le service userservice consomme davantage de ressources de processeur. Dans cette section, vous allez configurer l'autoscaling horizontal des pods pour le déploiement userservice lorsque les pods existants utilisent plus de 60% de leur processeur demandé, et pour le déploiement frontend lorsque le nombre des requêtes HTTP entrantes vers l'équilibreur de charge est supérieure à 5 par seconde.

Configurer l'autoscaling pour le déploiement du service utilisateur

Examinez le fichier manifeste HorizontalPodAutoscaler pour le déploiement userservice :

# Copyright 2022 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: userservice
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 5
      selectPolicy: Max
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: userservice
  minReplicas: 5
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

Ce fichier manifeste effectue les opérations suivantes :

Définit le nombre maximal d'instances dupliquées lors d'un scaling à la hausse jusqu'à 50.
Définit le nombre minimal d'instances dupliquées pendant un scaling à la baisse sur 5.
Utilise une métrique Kubernetes intégrée pour prendre des décisions de scaling. Dans cet exemple, la métrique correspond à l'utilisation du processeur, et l'utilisation cible est de 60%, ce qui évite une surutilisation et une sous-utilisation.

Appliquez le fichier manifeste au cluster :

kubectl apply -f extras/postgres-hpa/hpa/userservice.yaml

Configurer l'autoscaling pour le déploiement de l'interface

Examinez le fichier manifeste HorizontalPodAutoscaler pour le déploiement userservice :

# Copyright 2022 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 5
      selectPolicy: Max
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend
  minReplicas: 5
  maxReplicas: 25
  metrics:
    - type: External
      external:
        metric:
          name: loadbalancing.googleapis.com|https|request_count
          selector:
            matchLabels:
              resource.labels.forwarding_rule_name: FORWARDING_RULE_NAME
        target:
          type: AverageValue
          averageValue: "5"

Ce fichier manifeste utilise les champs suivants :

spec.scaleTargetRef : ressource Kubernetes à mettre à l'échelle.
spec.minReplicas : nombre minimal d'instances dupliquées, soit 5 dans cet exemple.
spec.maxReplicas : nombre maximal d'instances dupliquées, soit 25 dans cet exemple.
spec.metrics.* : métrique à utiliser. Dans cet exemple, il s'agit du nombre de requêtes HTTP par seconde, qui est une métrique personnalisée de Cloud Monitoring fournie par l'adaptateur que vous avez déployé.
spec.metrics.external.metric.selector.matchLabels : libellé de ressource spécifique à filtrer lors de l'autoscaling.

Recherchez le nom de la règle de transfert de l'équilibreur de charge vers le déploiement frontend :

export FW_RULE=$(kubectl get ingress frontend -o=jsonpath='{.metadata.annotations.ingress\.kubernetes\.io/forwarding-rule}')
echo $FW_RULE

Le résultat ressemble à ce qui suit :

k8s2-fr-j76hrtv4-default-frontend-wvvf7381

Ajoutez votre règle de transfert au fichier manifeste :
```
sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
```
Cette commande remplace FORWARDING_RULE_NAME par votre règle de transfert enregistrée.

Appliquez le fichier manifeste au cluster :

kubectl apply -f extras/postgres-hpa/hpa/frontend.yaml

Point de contrôle : valider la configuration de l'autoscaling

Obtenez l'état de vos ressources HorizontalPodAutoscaler :

kubectl get hpa

Le résultat ressemble à ce qui suit :

NAME                     REFERENCE                            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
accounts-db-postgresql   StatefulSet/accounts-db-postgresql   10905m/15 (avg)     1         5         2          5m2s
contacts                 Deployment/contacts                  1%/70%              1         5         1          11m
frontend                 Deployment/frontend                  <unknown>/5 (avg)   5         25        1          34s
userservice              Deployment/userservice               0%/60%              5         50        5          4m56s

À ce stade, vous avez configuré votre application et configuré l'autoscaling. Votre interface et votre base de données peuvent désormais évoluer en fonction des métriques que vous avez fournies.

Simuler la charge et observer le scaling GKE

Bank of Anthos inclut un service loadgenerator qui vous permet de simuler le trafic pour tester le scaling de votre application en cas de charge élevée. Dans cette section, vous allez déployer le service loadgenerator, générer une charge et observer le scaling obtenu.

Déployer le générateur de tests de charge

Créez une variable d'environnement avec l'adresse IP de l'équilibreur de charge de la Banque d'Anthos :
```
export LB_IP=$(kubectl get ingress frontend -o=jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $LB_IP
```
Le résultat ressemble à ce qui suit :
```
203.0.113.9
```

Ajoutez l'adresse IP de l'équilibreur de charge au fichier manifeste :

sed -i "s/FRONTEND_IP_ADDRESS/$LB_IP/g" "extras/postgres-hpa/loadgenerator.yaml"

Appliquez le fichier manifeste au cluster :

kubectl apply -f  extras/postgres-hpa/loadgenerator.yaml

Le générateur de charge commence à ajouter un utilisateur toutes les secondes, jusqu'à un maximum de 250 utilisateurs.

Simuler la charge

Dans cette section, vous allez utiliser un générateur de charge pour simuler des pics de trafic, et observer le nombre d'instances dupliquées et le nombre de nœuds évoluer à la hausse pour gérer l'augmentation de la charge au fil du temps. Vous mettez ensuite fin au test et observez le scaling à la baisse de l'instance dupliquée et du nombre de nœuds.

Exposez l'interface Web du générateur de charge localement :
```
kubectl port-forward svc/loadgenerator 8080
```
Si un message d'erreur s'affiche, réessayez une fois le pod en cours d'exécution.
Dans un navigateur, ouvrez l'interface Web du générateur de charge.
- Si vous utilisez une interface système locale, ouvrez un navigateur et accédez à http://127.0.0.1:8080.
- Si vous utilisez Cloud Shell, cliquez sur Aperçu Web, puis sur Prévisualiser sur le port 8080.
Cliquez sur l'onglet Graphiques pour observer les performances au fil du temps.

Ouvrez une nouvelle fenêtre de terminal et observez le nombre d'instances dupliquées de vos autoscalers horizontaux de pods :

kubectl get hpa -w

Le nombre d'instances dupliquées augmente à mesure que la charge augmente. Le scaling à la hausse peut prendre environ dix minutes.

NAME                     REFERENCE                            TARGETS          MINPODS   MAXPODS   REPLICAS
accounts-db-postgresql   StatefulSet/accounts-db-postgresql   8326m/15 (avg)   1         5         5
contacts                 Deployment/contacts                  51%/70%          1         5         2
frontend                 Deployment/frontend                  5200m/5 (avg)    5         25        13
userservice              Deployment/userservice               71%/60%          5         50        17

Ouvrez une autre fenêtre de terminal et vérifiez le nombre de nœuds dans le cluster :

gcloud container clusters list \
    --filter='name=bank-of-anthos' \
    --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \
    --region="us-central1"

Le nombre de nœuds est passé de la quantité initiale de trois nœuds à une quantité supérieure adaptée à la nouvelle instance dupliquée.
Ouvrez l'interface du générateur de charge et cliquez sur Arrêter pour mettre fin au test.
Vérifiez à nouveau le nombre d'instances dupliquées et le nombre de nœuds, et observez le nombre d'instances répliquées qui diminuent avec la charge réduite. Le scaling à la baisse peut prendre un certain temps, car la fenêtre de stabilisation par défaut pour les instances dupliquées dans la ressource Kubernetes HorizontalPodAutoscaler est de cinq minutes. Pour en savoir plus, consultez la section Intervalle de stabilisation.

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer des ressources individuelles

Google Cloud crée des ressources, telles que des équilibreurs de charge, en fonction des objets Kubernetes que vous créez. Pour supprimer toutes les ressources de ce tutoriel, procédez comme suit :

Supprimez les exemples de ressources Kubernetes :

kubectl delete \
    -f extras/postgres-hpa/loadgenerator.yaml \
    -f extras/postgres-hpa/hpa \
    -f extras/postgres-hpa/kubernetes-manifests \
    -f extras/jwt/jwt-secret.yaml \
    -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml

Supprimez la base de données PostgreSQL :

helm uninstall accounts-db
kubectl delete pvc -l "app.kubernetes.io/instance=accounts-db"
kubectl delete configmaps initdb

Supprimez le cluster GKE et le compte de service IAM :

gcloud iam service-accounts delete "bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com" --quiet
gcloud container clusters delete "bank-of-anthos" --region="us-central1" --quiet

Supprimer le projet

Attention : La suppression d'un projet aura les effets suivants :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches de ce document, lorsque vous le supprimez, vous supprimez é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.

Supprimez un projet Google Cloud :

gcloud projects delete PROJECT_ID

Étapes suivantes

Découvrez l'autoscaling de pods vertical, qui vous permet d'ajuster automatiquement les demandes de ressources pour les charges de travail de longue durée avec des recommandations basées sur l'historique d'utilisation.
En savoir plus sur l'autoscaling horizontal des pods.