Esegui carichi di lavoro full stack su larga scala su GKE

Autopilot

---

Questo tutorial fornisce istruzioni per lavorare con Helm versione 3.9.3, PostgreSQL versione 10.0.1 e lo strumento di test del carico di Locust. Le istruzioni potrebbero non rappresentare versioni più recenti dell'app. Per ulteriori informazioni, consulta la documentazione specifica dell'app:

• Helm
• PostgreSQL
• Locusta

Questo tutorial mostra come eseguire un'applicazione web supportata da un database relazionale ad alta disponibilità su larga fare lo scale in Google Kubernetes Engine (GKE).

L'applicazione di esempio utilizzata in questo tutorial è Bank of Anthos, un'applicazione web basata su HTTP che simula la rete di elaborazione dei pagamenti di una banca. Bank of Anthos usa più servizi per funzionare. Questo tutorial è incentrato sul frontend del sito web e sui database relazionali PostgreSQL che supporta i servizi Bank of Anthos. Per saperne di più su Bank of Anthos, inclusa la sua architettura e i servizi di cui esegue il deployment, consulta Bank of Anthos su GitHub.

Obiettivi

• Creare e configurare un cluster GKE.
• Esegui il deployment di un'applicazione web di esempio e di un database PostgreSQL ad alta disponibilità.
• Configura la scalabilità automatica dell'applicazione web e del database.
• Simulare picchi di traffico utilizzando un generatore di carico.
• Osservare lo scale up e lo scale down dei servizi.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• GKE Autopilot
• Bilanciatore del carico di rete passthrough interno
• Cloud Trace

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
2. Installa Google Cloud CLI.

3. Per initialize gcloud CLI, esegui questo comando:

   gcloud init

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the 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. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

6. Attiva l'API GKE.

   gcloud services enable container.googleapis.com

7. Installa Google Cloud CLI.

8. Per initialize gcloud CLI, esegui questo comando:

   gcloud init

9. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the 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. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

11. Attiva l'API GKE.

    gcloud services enable container.googleapis.com

12. Installa l'interfaccia a riga di comando Helm.

prepara l'ambiente

1. Clona il repository di esempio utilizzato in questo tutorial:

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

2. Imposta le variabili di ambiente:

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

   Sostituisci PROJECT_ID con l'ID progetto Google Cloud.

Configura il cluster e gli account di servizio

1. Crea un cluster:

   gcloud container clusters create-auto bank-of-anthos --region=us-central1
   

   L'avvio del cluster potrebbe richiedere fino a cinque minuti.

2. Crea un account di servizio IAM:

   gcloud iam service-accounts create bank-of-anthos
   

3. Concedi l'accesso all'account di servizio 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]"
   

   Questo passaggio concede il seguente accesso:

   • roles/cloudtrace.agent: scrivi dati di traccia come le informazioni di latenza in Trace.
   • roles/monitoring.metricWriter: scrivere metriche in Cloud Monitoring.
   • roles/iam.workloadIdentityUser: consenti a un account di servizio Kubernetes di utilizzare la federazione delle identità per i carichi di lavoro in modo che GKE agisca come account di servizio IAM.

4. Configura l'account di servizio Kubernetes default nello spazio dei nomi default in modo che agisca da account di servizio IAM che hai creato:

   kubectl annotate serviceaccount default \
       iam.gke.io/gcp-service-account=bank-of-anthos@PROJECT_ID.iam.gserviceaccount.com
   

   In questo modo, i pod che utilizzano l'account di servizio Kubernetes default nello spazio dei nomi default possono accedere alle stesse risorse Google Cloud dell'account di servizio IAM.

Esegui il deployment di Bank of Anthos e PostgreSQL

In questa sezione installerai Bank of Anthos e un database PostgreSQL in modalità ad alta disponibilità, che consente di scalare automaticamente le repliche del server di database. Se vuoi visualizzare gli script, il grafico Helm e i manifest di Kubernetes utilizzati in questa sezione, controlla il repository Bank of Anthos su GitHub.

1. Esegui il deployment dello schema di database e di uno script DDL (Data Definition Language):

   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. Installa PostgreSQL utilizzando il grafico Helm di esempio:

   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
   

   Questo comando crea un cluster PostgreSQL con un numero di repliche iniziale pari a 1. Più avanti in questo tutorial scalerai il cluster in base alle connessioni in entrata. Questa operazione potrebbe richiedere dieci minuti o più.

3. Esegui il deployment di Bank of Anthos:

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

   Questa operazione potrebbe richiedere alcuni minuti.

Checkpoint: convalida la configurazione

1. Verifica che tutti i pod di Bank of Anthos siano in esecuzione:

   kubectl get pods
   

   L'output è simile al seguente:

   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. Verifica di poter accedere al frontend del sito web:

   1. Recupera l'indirizzo IP esterno del servizio frontend:

      kubectl get ingress frontend
      

      L'output è simile al seguente:

      NAME       CLASS    HOSTS   ADDRESS         PORTS   AGE
      frontend   <none>   *       203.0.113.9     80      12m
      

   2. In un browser, vai all'indirizzo IP esterno. Viene visualizzata la pagina di accesso di Bank of Anthos. Se sei curioso, esplora l'applicazione.

      Se visualizzi un errore 404, attendi qualche minuto per il provisioning dei microservizi e riprova.

Scala automaticamente l'app web e il database PostgreSQL

GKE Autopilot scala automaticamente le risorse di calcolo del cluster in base al numero di carichi di lavoro nel cluster. Per scalare automaticamente il numero di pod nel cluster in base alle metriche delle risorse, devi implementare la scalabilità automatica orizzontale dei pod di Kubernetes. Puoi utilizzare le metriche di CPU e memoria di Kubernetes integrate oppure puoi utilizzare metriche personalizzate come le richieste HTTP al secondo o la quantità di istruzioni SELECT, acquisite da Cloud Monitoring.

In questa sezione:

1. Configura la scalabilità automatica orizzontale dei pod per i microservizi Bank of Anthos utilizzando metriche integrate e personalizzate.
2. Simula il carico nell'applicazione Bank of Anthos per attivare eventi di scalabilità automatica.
3. Osserva come il numero di pod e nodi nel cluster fa automaticamente lo scale up e lo scale down in risposta al tuo carico.

Configurare la raccolta di metriche personalizzate

Per leggere le metriche personalizzate da Monitoring, devi eseguire il deployment dell'adattatore Metriche personalizzate - Adattatore Stackdriver nel tuo cluster.

1. Installa l'adattatore:

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

2. Configura l'adattatore in modo che utilizzi la federazione di Workload Identity per GKE al fine di ottenere le metriche:

   1. Configura l'account di servizio 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. Annota l'account di servizio Kubernetes utilizzato dall'adattatore:

      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. Riavvia il deployment dell'adattatore per propagare le modifiche:

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

Configura la scalabilità automatica per il database

Quando hai eseguito il deployment di Bank of Anthos e PostgreSQL in precedenza in questo tutorial, hai eseguito il deployment del database come StatefulSet con una replica di lettura/scrittura primaria per gestire tutte le istruzioni SQL in entrata. In questa sezione configurerai la scalabilità automatica orizzontale dei pod per aggiungere nuove repliche di sola lettura in standby per gestire le istruzioni SELECT in entrata. Un buon modo per ridurre il carico su ogni replica è distribuire istruzioni SELECT, che sono operazioni di lettura. Il deployment di PostgreSQL include uno strumento denominato Pgpool-II che raggiunge questo bilanciamento del carico e migliora la velocità effettiva del sistema.

PostgreSQL esporta la metrica dell'istruzione SELECT come metrica di Prometheus. Utilizzerai un esportatore di metriche leggero denominato prometheus-to-sd per inviare queste metriche a Cloud Monitoring in un formato supportato.

1. Esamina l'oggetto 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"
   

   Il file manifest svolge le seguenti operazioni:

   • Imposta il numero massimo di repliche durante uno scale up su 5.
   • Imposta il numero minimo di durante uno scale down a 1.
   • Utilizza una metrica esterna per prendere decisioni di scalabilità. In questo esempio, la metrica è il numero di istruzioni SELECT. Si verifica un evento di scale up se il numero di istruzioni SELECT in entrata supera 15.

2. Applica il manifest al cluster:

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

Configura la scalabilità automatica per l'interfaccia web

In Deployment di Bank of Anthos e PostgreSQL hai eseguito il deployment dell'interfaccia web di Bank of Anthos. Con l'aumento del numero di utenti, il servizio userservice consuma più risorse della CPU. In questa sezione, configurerai la scalabilità automatica orizzontale dei pod per il deployment userservice quando i pod esistenti utilizzano più del 60% della CPU richiesta e per il deployment frontend quando il numero di richieste HTTP in entrata al bilanciatore del carico è superiore a 5 al secondo.

Configura la scalabilità automatica per il deployment userservice

1. Esamina il manifest HorizontalPodAutoscaler per il deployment di 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
   

   Il file manifest svolge le seguenti operazioni:

   • Imposta il numero massimo di repliche durante uno scale up su 50.
   • Imposta il numero minimo di durante uno scale down a 5.
   • Utilizza una metrica Kubernetes integrata per prendere decisioni di scalabilità. In questo esempio, la metrica è l'utilizzo della CPU e l'utilizzo target è del 60%, il che evita sia un utilizzo eccessivo che insufficiente.

2. Applica il manifest al cluster:

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

Configura la scalabilità automatica per il deployment frontend

1. Esamina il manifest HorizontalPodAutoscaler per il deployment di 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"
   

   Il file manifest utilizza i seguenti campi:

   • spec.scaleTargetRef: la risorsa Kubernetes da scalare.
   • spec.minReplicas: il numero minimo di repliche, ovvero 5 in questo esempio.
   • spec.maxReplicas: il numero massimo di repliche, corrispondente a 25 in questo esempio.
   • spec.metrics.*: la metrica da utilizzare. In questo esempio, si tratta del numero di richieste HTTP al secondo, una metrica personalizzata di Cloud Monitoring fornita dall'adattatore di cui hai eseguito il deployment.
   • spec.metrics.external.metric.selector.matchLabels: l'etichetta della risorsa specifica da filtrare durante la scalabilità automatica.

2. Trova il nome della regola di forwarding dal bilanciatore del carico al deployment frontend:

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

   L'output è simile al seguente:

   k8s2-fr-j76hrtv4-default-frontend-wvvf7381
   

3. Aggiungi la regola di forwarding al manifest:

   sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
   

   Questo comando sostituisce FORWARDING_RULE_NAME con la regola di forwarding salvata.

4. Applica il manifest al cluster:

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

Checkpoint: convalida la configurazione della scalabilità automatica

Visualizza lo stato delle tue risorse HorizontalPodAutoscaler:

kubectl get hpa

L'output è simile al seguente:

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

A questo punto, hai configurato la tua applicazione e configurato la scalabilità automatica. Ora il tuo frontend e il tuo database possono scalare in base alle metriche che hai fornito.

Simula il carico e osserva la scalabilità di GKE

Bank of Anthos include un servizio loadgenerator che ti consente di simulare il traffico per testare la scalabilità dell'applicazione sotto carico. In questa sezione eseguirai il deployment del servizio loadgenerator, genererai un carico e osserverai la scalabilità risultante.

Esegui il deployment del generatore di test di carico

1. Crea una variabile di ambiente con l'indirizzo IP del bilanciatore del carico di Bank of Anthos:

   export LB_IP=$(kubectl get ingress frontend -o=jsonpath='{.status.loadBalancer.ingress[0].ip}')
   echo $LB_IP
   

   L'output è simile al seguente:

   203.0.113.9
   

2. Aggiungi l'indirizzo IP del bilanciatore del carico al manifest:

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

3. Applica il manifest al cluster:

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

Il generatore di carico inizia ad aggiungere un utente al secondo, fino a un massimo di 250 utenti.

Simula caricamento

In questa sezione utilizzerai un generatore di carico per simulare picchi di traffico e osservare lo scale up del numero di repliche e dei nodi per supportare l'aumento del carico nel tempo. Quindi, termini il test e osserverai lo fare lo scale down del conteggio delle repliche e dei nodi in risposta.

1. Esponi a livello locale l'interfaccia web del generatore di carico:

   kubectl port-forward svc/loadgenerator 8080
   

   Se viene visualizzato un messaggio di errore, riprova quando il pod è in esecuzione.

2. Apri l'interfaccia web del generatore di carico in un browser.

   • Se utilizzi una shell locale, apri un browser e vai all'indirizzo http://127.0.0.1:8080.
   • Se utilizzi Cloud Shell, fai clic su Anteprima web, quindi su Anteprima sulla porta 8080.

3. Fai clic sulla scheda Grafici per osservare il rendimento nel tempo.

4. Apri una nuova finestra del terminale e controlla il numero di repliche dei tuoi gestori della scalabilità automatica dei pod orizzontali:

   kubectl get hpa -w
   

   Il numero di repliche aumenta con l'aumentare del carico. Lo scaleup potrebbe richiedere circa dieci minuti.

   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. Apri un'altra finestra del terminale e controlla il numero di nodi nel cluster:

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

6. Il numero di nodi è aumentato rispetto alla quantità iniziale di tre nodi per ospitare le nuove repliche.

7. Apri l'interfaccia del generatore di carico e fai clic su Arresta per terminare il test.

8. Controlla di nuovo il numero di repliche e di nodi e osserva come i numeri si riducono con il carico ridotto. Lo fare lo scale down potrebbe richiedere del tempo, perché la finestra di stabilizzazione predefinita per le repliche nella risorsa Kubernetes HorizontalPodAutoscaler è di cinque minuti. Per saperne di più, consulta Finestra di stabilizzazione.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina singole risorse

Google Cloud crea risorse, ad esempio i bilanciatori del carico, in base agli oggetti Kubernetes che crei. Per eliminare tutte le risorse in questo tutorial:

1. Elimina le risorse Kubernetes di esempio:

   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. Elimina il database PostgreSQL:

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

3. Elimina il cluster GKE e l'account di servizio 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
   

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Elimina un progetto Google Cloud:

gcloud projects delete PROJECT_ID

Passaggi successivi

• Scopri di più sulla scalabilità automatica verticale dei pod, che puoi utilizzare per regolare automaticamente le richieste di risorse per i carichi di lavoro a lunga esecuzione con suggerimenti basati sull'utilizzo storico.
• Scopri di più sulla scalabilità automatica orizzontale dei pod.