Ejecutar cargas de trabajo de pila completa a gran escala en GKE

Autopilot

En este tutorial se proporcionan instrucciones para trabajar con Helm 3.9.3, PostgreSQL 10.0.1 y la herramienta de pruebas de carga Locust. Es posible que las instrucciones no correspondan a versiones más recientes de la aplicación. Para obtener más información, consulta la documentación específica de la aplicación:

• Timón
• PostgreSQL
• Locust

En este tutorial se muestra cómo ejecutar a gran escala una aplicación web respaldada por una base de datos relacional de alta disponibilidad en Google Kubernetes Engine (GKE).

La aplicación de ejemplo que se usa en este tutorial es Bank of Anthos, una aplicación web basada en HTTP que simula la red de procesamiento de pagos de un banco. Bank of Anthos usa varios servicios para funcionar. Este tutorial se centra en el frontend del sitio web y en las bases de datos relacionales de PostgreSQL que respaldan los servicios de Bank of Anthos. Para obtener más información sobre Bank of Anthos, incluida su arquitectura y los servicios que implementa, consulta Bank of Anthos en GitHub.

Objetivos

• Crea y configura un clúster de GKE.
• Despliega una aplicación web de ejemplo y una base de datos PostgreSQL de alta disponibilidad.
• Configura el autoescalado de la aplicación web y la base de datos.
• Simula picos de tráfico con un generador de carga.
• Observa cómo se amplían y reducen los servicios.

Costes

En este documento, se utilizan los siguientes componentes facturables de Google Cloud:

• GKE Autopilot
• Internal passthrough Network Load Balancer
• Cloud Trace

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Antes de empezar

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.

Install the Google Cloud CLI.

Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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.

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com

Install the Google Cloud CLI.

Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

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.

Verify that billing is enabled for your Google Cloud project.

Enable the GKE API:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com

1. Instala la CLI de Helm.

Preparar el entorno

1. Clona el repositorio de muestra que se usa en este tutorial:

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

2. Define las variables de entorno:

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

   Sustituye PROJECT_ID por el ID de tu proyecto. Google Cloud

Configurar el clúster y las cuentas de servicio

1. Para crear un clúster, sigue estos pasos:

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

   El clúster puede tardar hasta cinco minutos en iniciarse.

2. Crea una cuenta de servicio de IAM:

   gcloud iam service-accounts create bank-of-anthos
   

3. Concede acceso a la cuenta de servicio de gestión de identidades y accesos:

   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]"
   

   Con este paso, se concede el siguiente acceso:

   • roles/cloudtrace.agent: escribe datos de seguimiento, como información de latencia, en Trace.
   • roles/monitoring.metricWriter: escribe métricas en Cloud Monitoring.
   • roles/iam.workloadIdentityUser: Permite que una cuenta de servicio de Kubernetes use Workload Identity Federation for GKE para actuar como cuenta de servicio de IAM.

4. Configura la cuenta de servicio de Kubernetes default en el espacio de nombres default para que actúe como la cuenta de servicio de IAM que has creado:

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

   De esta forma, los pods que usen la cuenta de servicio de Kubernetes default en el espacio de nombres default podrán acceder a los mismos recursos Google Cloud que la cuenta de servicio de IAM.

Desplegar Bank of Anthos y PostgreSQL

En esta sección, instalarás Bank of Anthos y una base de datos PostgreSQL en modo de alta disponibilidad (HA), lo que te permitirá escalar automáticamente las réplicas del servidor de la base de datos. Si quieres ver las secuencias de comandos, el gráfico de Helm y los manifiestos de Kubernetes que se usan en esta sección, consulta el repositorio de Bank of Anthos en GitHub.

1. Implementa el esquema de la base de datos y una secuencia de comandos del lenguaje de definición de datos (DDL):

   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. Instala PostgreSQL con el gráfico de Helm de ejemplo:

   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
   

   Este comando crea un clúster de PostgreSQL con un número inicial de réplicas de 1. Más adelante en este tutorial, escalará el clúster en función de las conexiones entrantes. Esta operación puede tardar diez minutos o más.

3. Despliega Bank of Anthos:

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

   Esta operación puede tardar unos minutos en completarse.

Punto de control: valida tu configuración

1. Comprueba que todos los pods de Bank of Anthos se estén ejecutando:

   kubectl get pods
   

   El resultado debería ser similar al siguiente:

   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. Comprueba que puedes acceder al frontend del sitio web:

   1. Obtén la dirección IP externa del servicio frontend:

      kubectl get ingress frontend
      

      El resultado debería ser similar al siguiente:

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

   2. En un navegador, ve a la dirección IP externa. Se muestra la página de inicio de sesión de Bank of Anthos. Si te interesa, explora la aplicación.

      Si recibes un error 404, espera unos minutos a que se aprovisionen los microservicios y vuelve a intentarlo.

Escalar automáticamente la aplicación web y la base de datos PostgreSQL

GKE Autopilot escala automáticamente los recursos de computación del clúster en función del número de cargas de trabajo del clúster. Para escalar automáticamente el número de pods del clúster en función de las métricas de recursos, debes implementar el autoescalado horizontal de pods de Kubernetes. Puede usar las métricas de CPU y memoria de Kubernetes integradas o métricas personalizadas, como las solicitudes HTTP por segundo o la cantidad de instrucciones SELECT, obtenidas de Cloud Monitoring.

En esta sección, harás lo siguiente:

1. Configura el autoescalado horizontal de pods para los microservicios de Bank of Anthos con métricas integradas y métricas personalizadas.
2. Simula la carga de la aplicación Bank of Anthos para activar eventos de autoescalado.
3. Observa cómo el número de pods y nodos de tu clúster se escala automáticamente en función de la carga.

Configurar la recogida de métricas personalizadas

Para leer métricas personalizadas de Monitoring, debes implementar el adaptador Métricas personalizadas - Adaptador de Stackdriver en tu clúster.

1. Implementa el adaptador:

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

2. Configura el adaptador para que use Workload Identity Federation for GKE y obtenga métricas:

   1. Configura la cuenta de servicio de 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. Anota la cuenta de servicio de Kubernetes que usa el adaptador:

      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. Reinicia la implementación del adaptador para propagar los cambios:

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

Configurar el autoescalado de la base de datos

Cuando desplegaste Bank of Anthos y PostgreSQL anteriormente en este tutorial, desplegaste la base de datos como un StatefulSet con una réplica principal de lectura/escritura para gestionar todas las instrucciones SQL entrantes. En esta sección, configurará el autoescalado horizontal de pods para añadir nuevas réplicas de solo lectura en espera que gestionen las instrucciones SELECT entrantes. Una buena forma de reducir la carga de cada réplica es distribuir las instrucciones SELECT, que son operaciones de lectura. La implementación de PostgreSQL incluye una herramienta llamada Pgpool-II que consigue este equilibrio de carga y mejora el rendimiento del sistema.

PostgreSQL exporta la métrica de la instrucción SELECT como una métrica de Prometheus. Usarás un exportador de métricas ligero llamado prometheus-to-sd para enviar estas métricas a Cloud Monitoring en un formato compatible.

1. Revisa el objeto 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"
   

   Este archivo de manifiesto hace lo siguiente:

   • Define el número máximo de réplicas durante un escalado vertical a 5.
   • Define el número mínimo de durante una reducción a 1.
   • Usa una métrica externa para tomar decisiones de escalado. En este ejemplo, la métrica es el número de instrucciones SELECT. Se produce un evento de escalado vertical si el número de instrucciones SELECT entrantes supera las 15.

2. Aplica el manifiesto al clúster:

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

Configurar el autoescalado de la interfaz web

En Desplegar Bank of Anthos y PostgreSQL, desplegaste la interfaz web de Bank of Anthos. Cuando aumenta el número de usuarios, el servicio userservice consume más recursos de CPU. En esta sección, configurará el autoescalado horizontal de pods para la userservice Deployment cuando los pods actuales usen más del 60% de la CPU solicitada y para la frontend Deployment cuando el número de solicitudes HTTP entrantes al balanceador de carga sea superior a 5 por segundo.

Configurar el autoescalado de la implementación de userservice

1. Consulta el archivo de manifiesto HorizontalPodAutoscaler de la userservice implementación:

   # 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
   

   Este archivo de manifiesto hace lo siguiente:

   • Define el número máximo de réplicas durante un escalado vertical a 50.
   • Define el número mínimo de durante una reducción a 5.
   • Usa una métrica de Kubernetes integrada para tomar decisiones de escalado. En este ejemplo, la métrica es el uso de la CPU y el uso objetivo es del 60%, lo que evita tanto el uso excesivo como el insuficiente.

2. Aplica el manifiesto al clúster:

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

Configurar el autoescalado del despliegue del frontend

1. Consulta el archivo de manifiesto HorizontalPodAutoscaler de la userservice implementación:

   # 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"
   

   Este manifiesto usa los siguientes campos:

   • spec.scaleTargetRef: el recurso de Kubernetes que se va a escalar.
   • spec.minReplicas: número mínimo de réplicas, que en este ejemplo es 5.
   • spec.maxReplicas: número máximo de réplicas, que es 25 en este ejemplo.
   • spec.metrics.*: la métrica que se va a usar. En este ejemplo, se trata del número de solicitudes HTTP por segundo, que es una métrica personalizada de Cloud Monitoring proporcionada por el adaptador que has implementado.
   • spec.metrics.external.metric.selector.matchLabels: etiqueta de recurso específica que se va a filtrar al escalar automáticamente.

2. Busca el nombre de la regla de reenvío del balanceador de carga a la implementación de frontend:

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

   El resultado debería ser similar al siguiente:

   k8s2-fr-j76hrtv4-default-frontend-wvvf7381
   

3. Añade tu regla de reenvío al archivo de manifiesto:

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

   Este comando sustituye FORWARDING_RULE_NAME por la regla de reenvío que hayas guardado.

4. Aplica el manifiesto al clúster:

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

Punto de control: validar la configuración del autoescalado

Obtén el estado de tus recursos de HorizontalPodAutoscaler:

kubectl get hpa

El resultado debería ser similar al siguiente:

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

En este punto, ya has configurado tu aplicación y el escalado automático. Ahora, el frontend y la base de datos se pueden escalar en función de las métricas que hayas proporcionado.

Simular carga y observar el escalado de GKE

Bank of Anthos incluye un loadgenerator servicio que te permite simular tráfico para probar el escalado de tu aplicación bajo carga. En esta sección, desplegarás el servicio loadgenerator, generarás una carga y observarás el escalado resultante.

Implementar el generador de pruebas de carga

1. Crea una variable de entorno con la dirección IP del balanceador de carga de Bank of Anthos:

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

   El resultado debería ser similar al siguiente:

   203.0.113.9
   

2. Añade la dirección IP del balanceador de carga al manifiesto:

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

3. Aplica el manifiesto al clúster:

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

El generador de carga empieza a añadir un usuario por segundo hasta llegar a 250 usuarios.

Simular carga

En esta sección, usarás un generador de carga para simular picos de tráfico y observar cómo aumenta el número de réplicas y de nodos para adaptarse al aumento de la carga a lo largo del tiempo. A continuación, finaliza la prueba y observa cómo se reduce el número de réplicas y nodos en respuesta.

1. Expón la interfaz web del generador de carga de forma local:

   kubectl port-forward svc/loadgenerator 8080
   

   Si aparece un mensaje de error, vuelve a intentarlo cuando el Pod esté en funcionamiento.

2. En un navegador, abre la interfaz web del generador de carga.

   • Si usas una shell local, abre un navegador y ve a http://127.0.0.1:8080.
   • Si usas Cloud Shell, haz clic en Vista previa web y, a continuación, en Obtener vista previa en el puerto 8080.

3. Haga clic en la pestaña Gráficos para observar el rendimiento a lo largo del tiempo.

4. Abre una nueva ventana de terminal y observa el número de réplicas de tus escaladores automáticos de pods horizontales:

   kubectl get hpa -w
   

   El número de réplicas aumenta a medida que lo hace la carga. El escalado puede tardar unos diez minutos.

   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. Abre otra ventana de terminal y comprueba el número de nodos del clúster:

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

6. El número de nodos ha aumentado de los tres nodos iniciales para dar cabida a las nuevas réplicas.

7. Abre la interfaz del generador de carga y haz clic en Detener para finalizar la prueba.

8. Vuelve a comprobar el número de réplicas y de nodos, y observa cómo se reducen a medida que disminuye la carga. El escalado hacia abajo puede tardar un poco, ya que la ventana de estabilización predeterminada de las réplicas del recurso HorizontalPodAutoscaler de Kubernetes es de cinco minutos. Para obtener más información, consulta Ventana de estabilización.

Limpieza

Para evitar que los recursos utilizados en este tutorial se cobren en tu cuenta de Google Cloud, elimina el proyecto que contiene los recursos o conserva el proyecto y elimina los recursos.

Eliminar recursos concretos

Google Cloud crea recursos, como balanceadores de carga, en función de los objetos de Kubernetes que crees. Para eliminar todos los recursos de este tutorial, haz lo siguiente:

1. Elimina los recursos de Kubernetes de ejemplo:

   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 la base de datos de PostgreSQL:

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

3. Elimina el clúster de GKE y la cuenta de servicio de IAM:

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

Eliminar el proyecto

Precaución: Eliminar un proyecto tiene los siguientes efectos:

• Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
• Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo el proyecto.

Si tienes previsto consultar varias arquitecturas, tutoriales o guías de inicio rápido, reutilizar los proyectos puede ayudarte a no superar los límites de cuota de proyectos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Siguientes pasos

• Consulta información sobre el autoescalado vertical de pods, que puedes usar para ajustar automáticamente las solicitudes de recursos de cargas de trabajo de larga duración con recomendaciones basadas en el uso histórico.
• Consulta más información sobre el autoescalado horizontal de pods.