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

Autopilot

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

• Helm
• PostgreSQL
• Locust

En este instructivo, se muestra cómo ejecutar una aplicación web con el respaldo de una base de datos relacional de alta disponibilidad a gran escala en Google Kubernetes Engine (GKE).

La aplicación de ejemplo que se usa en este instructivo 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. En este instructivo, se enfoca en el frontend del sitio web y 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

• Crear y configurar un clúster de GKE.
• Implementar una aplicación web de muestra y una base de datos de PostgreSQL con alta disponibilidad.
• Configurar el ajuste de escala automático de la aplicación web y la base de datos.
• Simula aumentos repentinos de tráfico mediante un generador de cargas.
• Observar cómo los servicios aumentan y reducen la escala verticalmente.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

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

Para obtener una estimación de costos en función del uso previsto, usa la calculadora de precios.

Es posible que los usuarios de Google Cloud nuevos cumplan con los requisitos para acceder a una prueba gratuita.

Cuando completes las tareas que se describen en este documento, podrás borrar los recursos que creaste para evitar que se te siga facturando. Para obtener más información, consulta Realiza una limpieza.

Antes de comenzar

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 usas un proveedor de identidad externo (IdP), primero debes Acceder a la gcloud CLI 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 role (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 usas un proveedor de identidad externo (IdP), primero debes Acceder a la gcloud CLI 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 role (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.

Prepare el entorno

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

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

2. Establece 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
   

   Reemplaza PROJECT_ID por el ID del proyecto de Google Cloud .

Configura el clúster y las cuentas de servicio

1. Crea un clúster:

   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. Revoca el acceso a la cuenta de servicio de 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]"
   

   Este paso otorga 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 la federación de identidades para cargas de trabajo para que GKE actúe como la 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 creaste:

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

   Esto permite que los Pods que usan la cuenta de servicio de Kubernetes default en el espacio de nombres default accedan a los mismos recursos de Google Cloud que la cuenta de servicio de IAM.

Implementa Bank of Anthos y PostgreSQL

En esta sección, instalarás Bank of Anthos y una base de datos de PostgreSQL en modo de alta disponibilidad (HA), que te permite escalar de forma automática las réplicas del servidor de la base de datos. Si deseas 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 Prometheus mediante el gráfico de Helm de muestra:

   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 recuento inicial de réplicas de 1. Más adelante en este instructivo, ajustarás la escala del clúster en función de las conexiones entrantes. Esta operación puede tardar diez minutos o más en completarse.

3. Implementa 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. Verifica que todos los Pods de Bank of Anthos se estén ejecutando:

   kubectl get pods
   

   El resultado es similar a este:

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

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

      kubectl get ingress frontend
      

      El resultado es similar a este:

      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. Aparecerá la página de acceso de Bank of Anthos. Si te interesa, explora la aplicación.

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

Ajusta la escala automáticamente de la app web y la base de datos de PostgreSQL

GKE Autopilot escala automáticamente los recursos de procesamiento del clúster según la cantidad de cargas de trabajo en el clúster. Para escalar automáticamente la cantidad de pods en el clúster según las métricas de recursos, debes implementar el ajuste automático de escala horizontal de Pods de Kubernetes. Puedes usar las métricas de CPU y memoria integradas de Kubernetes, o puedes usar métricas personalizadas, como solicitudes HTTP por segundo o la cantidad de sentencias SELECT, que se toman de Cloud Monitoring.

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

1. Configura el ajuste automático de escala horizontal de Pods para los microservicios de Bank of Anthos mediante métricas integradas y métricas personalizadas.
2. Simula la carga en la aplicación de Bank of Anthos para activar los eventos de ajuste de escala automático.
3. Observa cómo la cantidad de Pods y los nodos de tu clúster aumentan y reducen la escala automáticamente en respuesta a tu carga.

Configura la recopilación de métricas personalizadas

Para leer métricas personalizadas de Monitoring, debes implementar el adaptador de métricas personalizadas del 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 usar la federación de identidades para cargas de trabajo para que GKE 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 el Deployment del adaptador para propagar los cambios:

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

Configura el ajuste de escala automático para la base de datos

Cuando implementaste Bank of Anthos y PostgreSQL antes en este instructivo, implementaste la base de datos como un StatefulSet con una réplica principal de lectura y escritura para controlar todas las instrucciones de SQL entrantes. En esta sección, configurarás el ajuste automático de escala horizontal de Pods para agregar réplicas nuevas de solo lectura en espera a fin de controlar las declaraciones SELECT entrantes. Una buena manera de reducir la carga en cada réplica es distribuir las sentencias SELECT, que son operaciones de lectura. La implementación de PostgreSQL incluye una herramienta llamada Pgpool-II que logra este equilibrio de carga y mejora la capacidad de procesamiento del sistema.

PostgreSQL exporta la métrica de declaración SELECT como una métrica de Prometheus. Usarás un exportador de métricas básicas 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 manifiesto hace lo siguiente:

   • Establece la cantidad máxima de réplicas durante un escalamiento vertical hasta 5.
   • Establece la cantidad mínima de durante una reducción de escala en 1.
   • Usa una métrica externa para tomar decisiones de escalamiento. En este ejemplo, la medición es la cantidad de instrucciones SELECT. Un evento de escalamiento vertical se produce si el recuento de declaraciones SELECT entrante supera la 15.

2. Aplica el manifiesto al clúster:

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

Configura el ajuste de escala automático para la interfaz web

En Implementa Bank of Anthos y PostgreSQL, implementaste la interfaz web de Bank of Anthos. Cuando la cantidad de usuarios aumenta, el Service userservice consume más recursos de CPU. En esta sección, configurarás el ajuste automático de escala horizontal de Pods para el Deployment userservice cuando los Pods existentes usen más del 60% de su CPU solicitada y el Deployment frontend cuando la cantidad de las solicitudes HTTP entrantes al balanceador de cargas son de más de 5 por segundo.

Configura el ajuste de escala automático para el Deployment de userservice

1. Revisa el manifiesto HorizontalPodAutoscaler para el Deployment 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
   

   Este manifiesto hace lo siguiente:

   • Establece la cantidad máxima de réplicas durante un escalamiento vertical hasta 50.
   • Establece la cantidad mínima de durante una reducción de escala en 5.
   • Usa una métrica integrada de Kubernetes para tomar decisiones de escalamiento. En este ejemplo, la métrica es el uso de CPU y el uso objetivo es del 60%, lo que evita el uso excesivo e insuficiente.

2. Aplica el manifiesto al clúster:

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

Configura el ajuste de escala automático para la implementación del frontend

1. Revisa el manifiesto HorizontalPodAutoscaler para el Deployment 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"
   

   En este manifiesto, se usan los siguientes campos:

   • spec.scaleTargetRef: El recurso de Kubernetes para escalar.
   • spec.minReplicas: La cantidad mínima de réplicas, que es 5 en esta muestra.
   • spec.maxReplicas: La cantidad máxima de réplicas, que es 25 en esta muestra.
   • spec.metrics.*: La métrica que se usará. En este ejemplo, esta es la cantidad de solicitudes HTTP por segundo, que es una métrica personalizada de Cloud Monitoring que proporciona el adaptador que implementaste.
   • spec.metrics.external.metric.selector.matchLabels: La etiqueta de recurso específica que se va a filtrar cuando se ajuste la escala automáticamente.

2. Busca el nombre de la regla de reenvío del balanceador de cargas 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 es similar a este:

   k8s2-fr-j76hrtv4-default-frontend-wvvf7381
   

3. Agrega tu regla de reenvío al manifiesto:

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

   Este comando reemplaza FORWARDING_RULE_NAME por tu regla de reenvío guardada.

4. Aplica el manifiesto al clúster:

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

Punto de control: Valida la configuración del ajuste de escala automático

Obtén el estado de los recursos HorizontalPodAutoscaler:

kubectl get hpa

El resultado es similar a este:

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, configuraste tu aplicación y el ajuste de escala automático. El frontend y la base de datos ahora pueden escalar según las métricas que proporcionaste.

Simula la carga y observa el escalamiento de GKE

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

Implementa el generador de pruebas de carga

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

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

   El resultado es similar a este:

   203.0.113.9
   

2. Agrega la dirección IP del balanceador de cargas 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 cargas comienza a agregar un usuario cada segundo, hasta 250 usuarios.

Simula la carga

En esta sección, usas un generador de cargas para simular aumentos repentinos en el tráfico y observar el recuento de réplicas y el recuento de nodos para escalar verticalmente a fin de adaptarse al aumento de carga en el tiempo. Luego, finalizas la prueba y observas la reducción vertical de escala de la réplica y los nodos como respuesta.

1. Expón de manera local la interfaz web del generador de cargas:

   kubectl port-forward svc/loadgenerator 8080
   

   Si ves un mensaje de error, vuelve a intentarlo cuando el Pod se esté ejecutando.

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

   • 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 en la Web y, luego, en Vista previa en el puerto 8080.

3. Haz clic en la pestaña Charts para observar el rendimiento en el tiempo.

4. Abre una ventana de la terminal nueva y observa el recuento de réplicas de los escaladores automáticos horizontales de Pods:

   kubectl get hpa -w
   

   La cantidad de réplicas aumenta a medida que aumenta la carga. El escalamiento vertical puede tardar aproximadamente 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 la terminal y verifica la cantidad de nodos en el clúster:

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

6. La cantidad de nodos aumentó desde la cantidad inicial de tres nodos para incluir las réplicas nuevas.

7. Abre la interfaz del generador de cargas y haz clic en Stop para finalizar la prueba.

8. Verifica el recuento de réplicas y el recuento de nodos de nuevo y observa cómo los números se reducen con la carga reducida. La reducción vertical de la escala puede llevar un tiempo, ya que el período de estabilización predeterminado para las réplicas en el recurso HorizontalPodAutoscaler de Kubernetes es de cinco minutos. Para obtener más información, consulta Período de estabilización.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra los recursos individuales

Google Cloud crea recursos, como balanceadores de cargas, según los objetos de Kubernetes que crees. Para borrar todos los recursos de este instructivo, haz lo siguiente:

1. Borra los recursos de Kubernetes de muestra:

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

Borra el proyecto

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo su contenido. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los IDs personalizados de los proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID personalizado del proyecto que desees utilizar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto, en lugar de todo el proyecto.

Si planeas explorar varios instructivos, arquitecturas o guías de inicio rápido, reutilizar proyectos puede ser útil para no exceder los límites de cuota de los proyectos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

¿Qué sigue?

• Obtén información sobre el Ajuste de escala automático vertical de Pods, que puedes usar para ajustar de forma automática las solicitudes de recursos para cargas de trabajo de larga duración con recomendaciones basadas en el uso histórico.
• Obtén más información sobre el Ajuste de escala automático horizontal de Pods.