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

Autopilot

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, nos enfocamos 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:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Instala Google Cloud CLI.

Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

gcloud init

Crea o selecciona un proyecto de Google Cloud.

Crea un proyecto de Google Cloud:
```
gcloud projects create PROJECT_ID
```
Reemplaza PROJECT_ID por un nombre para el proyecto de Google Cloud que estás creando.
Selecciona el proyecto de Google Cloud que creaste:
```
gcloud config set project PROJECT_ID
```
Reemplaza PROJECT_ID por el nombre del proyecto de Google Cloud.

Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

Habilita la API de GKE:

gcloud services enable container.googleapis.com

Instala Google Cloud CLI.

Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

gcloud init

Crea o selecciona un proyecto de Google Cloud.

Crea un proyecto de Google Cloud:
```
gcloud projects create PROJECT_ID
```
Reemplaza PROJECT_ID por un nombre para el proyecto de Google Cloud que estás creando.
Selecciona el proyecto de Google Cloud que creaste:
```
gcloud config set project PROJECT_ID
```
Reemplaza PROJECT_ID por el nombre del proyecto de Google Cloud.

Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

Habilita la API de GKE:

gcloud services enable container.googleapis.com

Instala la CLI de Helm.

Prepare el entorno

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/

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

Crea un clúster:

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

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

Crea una cuenta de servicio de IAM:

gcloud iam service-accounts create bank-of-anthos

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

En este paso, se 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.

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 hacer ajuste de escala automático de las réplicas del servidor de base de datos. Si deseas ver las secuencias de comandos, el gráfico de Helm y los manifiestos de Kubernetes usados en esta sección, consulta el repositorio de Bank of Anthos en GitHub.

Implementa el esquema de la base de datos y una secuencia de comandos de 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

Instala PostgreSQL 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 de réplicas inicial de 1. Más adelante en este instructivo, escalarás el clúster según las conexiones entrantes. Esta operación puede tardar diez minutos o más en completarse.

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:

Punto de control: Valida tu configuración

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

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 hasta que se aprovisionen los microservicios y vuelve a intentarlo.

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

Autopilot de GKE 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 integradas de CPU y memoria de Kubernetes o puedes usar métricas personalizadas, como solicitudes HTTP por segundo o la cantidad de declaraciones SELECT que se toman de Cloud Monitoring.

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

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.
Simula la carga en la aplicación de Bank of Anthos para activar eventos de ajuste de escala automático.
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 las métricas personalizadas de Monitoring, debes implementar el adaptador de Métricas personalizadas: adaptador de Stackdriver en tu clúster.

Implementa el adaptador:

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

Configura el adaptador para usar la federación de identidades para cargas de trabajo para que GKE obtenga métricas:

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

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

Reinicia la implementación 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 forma de reducir la carga en cada réplica es distribuir declaraciones SELECT, que son operaciones de lectura. La implementación de PostgreSQL incluye una herramienta llamada Pgpool-II que logra este balanceo de cargas 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.

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 métrica es el número de declaraciones SELECT. Un evento de escalamiento vertical ocurre si el recuento de declaraciones SELECT entrantes supera los 15.

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 servicio 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 la implementación de userservice

Revisa el manifiesto HorizontalPodAutoscaler para la implementación 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.

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 de frontend

Revisa el manifiesto HorizontalPodAutoscaler para la implementación 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 esta muestra, 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 realiza el ajuste de escala automático.

Busca el nombre de la regla de reenvío del balanceador de cargas al Deployment 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

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.

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

Simula una carga y observa el escalamiento de GKE

Bank of Anthos incluye un servicio 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 servicio loadgenerator, generarás una carga y observarás el escalamiento resultante.

Implementa el generador de pruebas de carga

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
```

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"

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.

Expón la interfaz web del generador de cargas de forma local:
```
kubectl port-forward svc/loadgenerator 8080
```
Si ves un mensaje de error, vuelve a intentarlo cuando el Pod se esté ejecutando.
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.
Haz clic en la pestaña Charts para observar el rendimiento en el tiempo.

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 alrededor de 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

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)' \
    --region="us-central1"

La cantidad de nodos aumentó desde la cantidad inicial de tres nodos para incluir las réplicas nuevas.
Abre la interfaz del generador de cargas y haz clic en Stop para finalizar la prueba.
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 Ventana de estabilización.

Realiza una limpieza

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:

Borra los recursos de muestra de 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

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

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" --region="us-central1" --quiet

Borra el proyecto

Precaución: Borrar un proyecto tiene estas consecuencias:

Se borra todo en el proyecto. 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 ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

Borra un proyecto de Google Cloud:

gcloud projects delete PROJECT_ID

¿Qué sigue?

Obtén información sobre el Ajuste de escala automático vertical de Pods, que puedes usar a fin de 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.