Ruta de aprendizaje: Aplicaciones escalables - Escalamiento

Este conjunto de instructivos es para administradores y operadores de TI que deseen implementar, ejecutar y administrar entornos de aplicaciones modernos que se ejecutan en la edición Enterprise de Google Kubernetes Engine (GKE). A medida que avanzas con este conjunto de instructivos, aprenderás a configurar la supervisión y las alertas, escalar cargas de trabajo y simular fallas, todo con la aplicación de microservicios de muestra de Cymbal Bank:

Crea un clúster y, luego, implementa una app de ejemplo
Supervisa con Google Cloud Managed Service para Prometheus
Escala cargas de trabajo (este instructivo)
Simula una falla

Descripción general y objetivos

Una aplicación de consumidor como Cymbal Bank suele tener una cantidad variable de usuarios en diferentes momentos. Lo ideal es que el sitio web pueda soportar aumentos de tráfico sin ralentizarse ni tener otros problemas, pero sin que la organización tenga que gastar dinero en recursos en la nube que realmente no necesitan. Una solución que Google Cloud proporciona para esto es el ajuste de escala automático.

En este instructivo, aprenderás a configurar clústeres y cargas de trabajo en un clúster de GKE para escalar con métricas integradas de Kubernetes y métricas personalizadas de Cloud Monitoring y Cloud Trace. Aprenderás a completar las siguientes tareas:

Habilitar las métricas personalizadas en Cloud Monitoring para Trace.
- Las métricas personalizadas te permiten escalar mediante datos de supervisión adicionales o entradas externas más allá del conocimiento del clúster de Kubernetes, como el tráfico de red o los códigos de respuesta HTTP.
Configura el escalador automático horizontal de pods, una característica de GKE que puede aumentar o disminuir de forma automática la cantidad de pods para una carga de trabajo según las métricas especificadas.
Simula la carga de la aplicación y visualiza que el escalador automático del clúster y el escalador automático horizontal de Pods responden.

Costos

Habilitar GKE Enterprise e implementar la aplicación de ejemplo Cymbal Bank para esta serie de instructivos significa que se generan cargos por clúster para GKE Enterprise en Google Cloud, como se indica en nuestra página de precios hasta que inhabilites GKE Enterprise o borres el proyecto.

También eres responsable de otros costos de Google Cloud generados mientras ejecutas la aplicación de muestra de Cymbal Bank, como los cargos por las VM de Compute Engine y Trace.

Antes de comenzar

Si quieres aprender a escalar tus implementaciones, debes completar el primer instructivo para crear un clúster de GKE que use Autopilot e implementar la aplicación basada en microservicios de muestra de Cymbal Bank.

Te recomendamos que completes este conjunto de instructivos para Cymbal Bank en orden. A medida que avanzas en el conjunto de instructivos, adquieres habilidades nuevas y usas productos y servicios adicionales de Google Cloud.

También debes crear una cuenta de servicio de IAM y otorgar algunos permisos para que Horizontal Pod Autoscaler funcione de forma correcta:

Crea una cuenta de servicio de IAM. Esta cuenta de servicio se usa en el instructivo para otorgar acceso a métricas personalizadas que permiten al escalador automático horizontal de pods determinar cuándo escalar o reducir la escala verticalmente:
```
gcloud iam service-accounts create scalable-apps
```

Otorga acceso a la cuenta de servicio de IAM para realizar las acciones de escalamiento necesarias:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/cloudtrace.agent \
  --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/monitoring.metricWriter \
  --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"

gcloud iam service-accounts add-iam-policy-binding "scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[default/default]"

Se otorga el siguiente acceso a la cuenta de servicio de IAM:

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 para que 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=scalable-apps@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.

Configura la recopilación de métricas personalizadas

Puedes configurar el escalador automático horizontal de Pods para usar métricas integradas de CPU y memoria de Kubernetes, o puedes usar métricas personalizadas de Cloud Monitoring, como solicitudes HTTP por segundo o la cantidad de declaraciones SELECT. Las métricas personalizadas pueden funcionar sin cambios en la aplicación y le proporcionan a tu clúster más estadísticas sobre el rendimiento general y las necesidades de la aplicación. En este instructivo, aprenderás a usar las métricas integradas y personalizadas.

Para permitir que el escalador automático horizontal de pods lea las métricas personalizadas de Monitoring, debes instalar el adaptador de métricas personalizadas del adaptador de Stackdriver en tu clúster.

Implementa el adaptador de métricas personalizadas de Stackdriver en tu clúster:
```
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
```
Para permitir que el adaptador de Stackdriver obtenga métricas personalizadas de tu clúster, usa Workload Identity. En este enfoque, se usa una cuenta de servicio de IAM que tiene permisos para leer las métricas de supervisión.

Otorga a la cuenta de servicio de IAM el rol roles/monitoring.viewer.
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer
```

Configura el adaptador de Stackdriver a fin de usar Workload Identity y la cuenta de servicio de IAM que tiene permisos para leer las métricas de supervisión:

gcloud iam service-accounts add-iam-policy-binding scalable-apps@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"

Kubernetes incluye su propio sistema para las cuentas de servicio a fin de acceder dentro de un clúster. Para permitir que las aplicaciones se autentiquen en servicios y recursos fuera de los clústeres de Google Kubernetes Engine (GKE) Enterprise, como Monitoring, usa Workload Identity. Este enfoque configura la cuenta de servicio de Kubernetes a fin de usar la cuenta de servicio de IAM para GKE.

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=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
```

Reinicia la implementación del adaptador de Stackdriver para aplicar los cambios:

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

Configura el escalador automático horizontal de Pods

Autopilot de GKE puede escalar de varias maneras. En este instructivo, verás cómo tu clúster puede escalar con los siguientes métodos:

Escalador automático de pod horizontal: escala la cantidad de pods para una carga de trabajo.
Escalador automático de clúster: escala los recursos de nodo que están disponibles en el clúster.

Estos dos métodos pueden funcionar juntos a fin de que, a medida que cambie la cantidad de Pods para tus aplicaciones, los recursos de los nodos para admitir esos Pods también cambien.

Hay otras implementaciones disponibles para escalar Pods que se compilan sobre el escalador automático horizontal de Pods, y también puedes usar el escalador automático vertical de Pods para ajustar los requisitos de CPU y memoria de un Pod en lugar de la cantidad de Pods.

En este instructivo, configurarás el escalador automático horizontal de Pods para la implementación userservice mediante métricas integradas y la implementación frontend con métricas personalizadas.

Para tus propias aplicaciones, trabaja con los desarrolladores de aplicaciones y los ingenieros de Platform a fin de comprender sus necesidades y configurar las reglas del escalador automático horizontal de pods.

Escala el Deployment `userservice`

Cuando aumenta la cantidad de usuarios de la aplicación de muestra de Cymbal Bank, el Service userservice consume más recursos de CPU. Usa un objeto HorizontalPodAutoscaler para controlar cómo quieres que tu aplicación responda a la carga. En el manifiesto YAML de HorizontalPodAutoscaler, debes definir en qué Deployment debe escalar el Horizontal Pod Autoscaler, qué métricas supervisar y la cantidad mínima y máxima de réplicas que deseas ejecutar. .

Revisa el manifiesto de muestra 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

Escala el Deployment `frontend`

En la sección anterior, configuraste el escalador automático horizontal de Pods en la implementación de userservice según las métricas integradas de Kubernetes para el uso de CPU. Para la implementación de frontend, es posible que desees escalar en función de la cantidad de solicitudes HTTP entrantes. Este enfoque usa el adaptador de Stackdriver a fin de leer métricas personalizadas de Monitoring para el objeto Ingress del balanceador de cargas HTTP(S).

Revisa el manifiesto HorizontalPodAutoscaler para la implementación frontend:

# 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 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 escala.

Busca el nombre de la regla de reenvío del balanceador de cargas de Ingress frontend:

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

El resultado es similar al siguiente:

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

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, puedes dejar de generar tráfico y observar la reducción de escala vertical del recuento de nodos y réplicas en respuesta.

Antes de comenzar, verifica el estado del escalador automático horizontal de Pods y observa la cantidad de réplicas en uso.

Obtén el estado de los recursos HorizontalPodAutoscaler:

kubectl get hpa

El resultado es similar al siguiente que muestra que hay 1 réplica frontend y 5 réplicas userservice:

NAME                     REFERENCE                            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
frontend                 Deployment/frontend                  <unknown>/5 (avg)   5         25        1          34s
userservice              Deployment/userservice               0%/60%              5         50        5          4m56s

La aplicación de muestra de Cymbal Bank incluye un Service loadgenerator. Este Service envía de forma continua solicitudes que imitan a los usuarios al frontend, y crea cuentas nuevas de forma periódica y simula transacciones entre ellas.

Expón la interfaz web loadgenerator de forma local. Usa esta interfaz para simular la carga en la aplicación de muestra de Cymbal Bank:
```
kubectl port-forward svc/loadgenerator 8080
```
Si ves un mensaje de error, vuelve a intentarlo cuando el Pod se esté ejecutando.
En un navegador en la computadora, 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.
En la interfaz web del generador de cargas, si el valor de Errores muestra 100%, completa los siguientes pasos para actualizar la configuración de la prueba:
1. Haz clic en el botón Detener junto al contador de la tasa de fallas.
2. En Estado, haz clic en la opción Prueba nueva.
3. Actualiza el valor de Host a la dirección IP de entrada de Cymbal Bank.
4. Haz clic en Start swarming.
En la interfaz web del generador de cargas, haz clic en la pestaña Gráficos para observar el rendimiento en el tiempo. Observa la cantidad de solicitudes y el uso de recursos.
Abre una ventana de la terminal nueva y observa el recuento de réplicas de los Pods frontend y userservice:
```
kubectl get hpa -w
```
La cantidad de réplicas aumenta a medida que aumenta la carga. Las acciones de scaleUp pueden tardar alrededor de diez minutos, ya que el clúster reconoce que las métricas configuradas alcanzan el umbral definido y usan el escalador automático horizontal de pods para escalar verticalmente la cantidad de pods.

En el siguiente resultado de ejemplo, se muestra que la cantidad de réplicas aumentó a medida que se ejecuta el generador de cargas:
```
NAME                     REFERENCE                            TARGETS          MINPODS   MAXPODS   REPLICAS
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=scalable-apps' \
    --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \
    --region="REGION"
```
Reemplaza REGION por la región en la que se ejecuta tu clúster.

La cantidad de nodos también aumentó desde la cantidad inicial para incluir las réplicas nuevas. Este aumento en la cantidad de nodos impulsa GKE Autopilot. No necesitas configurar nada para esta escala de nodo.
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.

En un entorno real, la cantidad de nodos y pods en tu entorno aumentaría y reduciría la escala verticalmente de forma automática de la misma manera que con esta carga simulada. La aplicación de muestra de Cymbal Bank está diseñada para adaptarse a este tipo de escalamiento. Consulta con los operadores de la app, la ingeniería de confiabilidad de sitios (SRE) o los desarrolladores de aplicaciones para ver si sus cargas de trabajo pueden beneficiarse de estas características de escalamiento.

Limpia

El conjunto de instructivos para Cymbal Bank está diseñado para completarse uno tras otro. A medida que avanzas en el conjunto de instructivos, adquieres habilidades nuevas y usas productos y servicios adicionales de Google Cloud.

Si deseas tomar un descanso antes de continuar con el siguiente instructivo y evitar que se generen cargos en tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, borra el proyecto que creaste.

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.

En la consola de Google Cloud, ve a la página Administrar recursos.
Ir a Administrar recursos
En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

Aprende a simular una falla en GKE Enterprise en el siguiente instructivo.