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


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 de Bank of Anthos sur GitHub.

Objectifs

  • Créez et configurez 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

  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 GKE API:

    gcloud services enable container.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 GKE API:

    gcloud services enable container.googleapis.com
  12. Installez la CLI Helm.

Préparer l'environnement

  1. 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/
    
  2. 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

  1. 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.

  2. Créez un compte de service IAM :

    gcloud iam service-accounts create bank-of-anthos
    
  3. 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.
  4. 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 de Bank of Anthos sur GitHub.

  1. 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
    
  2. 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 répliquées de départ de 1. Plus loin dans ce tutoriel, vous allez mettre à l'échelle le cluster en fonction des connexions entrantes. Cette opération peut prendre dix minutes ou plus.

  3. 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

  1. 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
    
  2. 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 un scaling automatique des ressources de calcul du cluster en fonction du nombre de charges de travail du cluster. 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 Kubernetes intégrées pour le processeur et la mémoire, ou utiliser des métriques personnalisées telles que le nombre de requêtes HTTP par seconde ou le nombre d'instructions SELECT, provenant de Cloud Monitoring.

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

  1. 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.
  2. Simulez la charge vers l'application Bank of Anthos pour déclencher des événements d'autoscaling.
  3. Observez comment le nombre de pods et de nœuds de votre cluster évolue automatiquement à la hausse ou à la baisse en fonction de votre charge.

Configurer la collecte de métriques personnalisées

Pour lire des métriques personnalisées à partir de Monitoring, vous devez déployer l'adaptateur Métriques personnalisées Stackdriver Adapter dans votre cluster.

  1. Déployez l'adaptateur :

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
    
  2. Configurez l'adaptateur pour utiliser la fédération d'identité de charge de travail pour GKE afin d'obtenir des métriques :

    1. 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]"
      
    2. 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
      
    3. 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 et PostgreSQL plus tôt dans ce tutoriel, vous avez déployé la base de données en tant que StatefulSet avec une instance répliquée principal 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 répliqué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.

  1. 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 répliquées pendant un scaling à la hausse sur 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.
  2. 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 userservice

  1. 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 répliquées pendant un scaling à la hausse sur 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.
  2. Appliquez le fichier manifeste au cluster :

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

Configurer l'autoscaling pour le déploiement du frontend

  1. 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.
  2. 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
    
  3. 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.

  4. 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 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 de 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

  1. 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
    
  2. 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"
    
  3. 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 l'adaptation du nombre d'instances répliquées et de nœuds en réponse à l'augmentation de la charge au fil du temps. Vous mettez ensuite fin au test et observez le scaling à la baisse du nombre d'instances répliquées et du nombre de nœuds.

  1. 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 lorsque le pod est en cours d'exécution.

  2. Dans un navigateur, ouvrez l'interface Web du générateur de charge.

    • Si vous utilisez un shell local, ouvrez un navigateur et accédez à l'adresse http://127.0.0.1:8080.
    • Si vous utilisez Cloud Shell, cliquez sur Aperçu Web, puis sur Prévisualiser sur le port 8080.
  3. Cliquez sur l'onglet Graphiques pour observer les performances au fil du temps.

  4. 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 répliqué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
    
  5. 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"
    
  6. 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.

  7. Ouvrez l'interface du générateur de charge et cliquez sur Arrêter pour mettre fin au test.

  8. Vérifiez à nouveau le nombre d'instances répliquées et le nombre de nœuds, et observez-les à mesure que les nombres diminuent avec la charge réduite. Le scaling à la baisse peut prendre un certain temps, car l'intervalle de stabilisation par défaut pour les instances répliquées dans la ressource HorizontalPodAutoscaler de Kubernetes 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 :

  1. 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
    
  2. 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
    
  3. 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

    Delete a Google Cloud project:

    gcloud projects delete PROJECT_ID

Étapes suivantes