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

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.

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, debes hacer 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.