Ruta de aprendizaje: Aplicaciones escalables - Escalamiento

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.

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

2. Para permitir que el adaptador de Stackdriver obtenga métricas personalizadas de tu clúster, usa Workload Identity Federation for GKE. 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
   

3. Configura el adaptador de Stackdriver para usar Workload Identity Federation for GKE 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]"
   

4. 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 Federation for GKE. 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
   

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

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

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

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

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

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
   

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.

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

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

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

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

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

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

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

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

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