Configura el balanceo de cargas basado en la utilización para los servicios de GKE

Autopilot estándar

Vista previa

Esta función está sujeta a las “Condiciones de la Oferta de la Fase Previa a la DG” en la sección Condiciones del Servicio Generales de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles “tal cual” y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En esta página, se describe cómo configurar el balanceo de cargas basado en la utilización para los servicios de GKE. Esta página está dirigida a los equipos de infraestructura y aplicaciones, y a los administradores de GKE que son responsables de configurar y administrar la distribución del tráfico para sus servicios de GKE.

Puedes usar balanceadores de cargas basados en la utilización para optimizar el rendimiento y la disponibilidad de las aplicaciones, ya que distribuyen el tráfico de forma inteligente según el uso de recursos en tiempo real de tus Pods de GKE.

Antes de leer esta página, asegúrate de conocer el balanceo de cargas basado en la utilización para los servicios de GKE y cómo funciona el balanceo de cargas basado en la utilización.

Precios

El balanceo de cargas basado en la utilización es una capacidad de GKE Gateway que está disponible sin costo adicional. Aún se aplican los precios de Cloud Load Balancing y GKE.

Cuotas

El balanceo de cargas basado en la utilización no introduce cuotas nuevas, aunque se siguen aplicando todas las cuotas de Cloud Load Balancing y otros servicios dependientes.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

• Revisa los requisitos del controlador de la puerta de enlace.
• Revisa las limitaciones.

Requisitos del controlador de la puerta de enlace de GKE

El balanceo de cargas basado en la utilización para los servicios de GKE requiere lo siguiente:

• Versión 516.0.0 o posterior de Google Cloud CLI.
• Versión de GKE 1.33.1-gke.1918000 o posterior en el canal RAPID
• La API de Gateway debe estar habilitada en tu clúster.
• El perfil de HPA de rendimiento debe estar habilitado en tu clúster.
• La API de Autoscaling debe estar habilitada en tu proyecto de Google Cloud .
• Las cuentas de servicio de los nodos deben poder escribir en la API de Autoscaling.

El balanceo de cargas basado en la utilización para los servicios de GKE admite lo siguiente:

• Servicios de GKE de un solo clúster y de varios clústeres que actúan como backends para un balanceador de cargas administrado por Google Cloud.
• Todas las ediciones de GKE (Standard, Autopilot y Enterprise)
• Todos los Google Cloud balanceadores de cargas de aplicaciones, excepto los balanceadores de cargas de aplicaciones clásicos.

Limitaciones

El balanceo de cargas basado en la utilización para los servicios de GKE tiene las siguientes limitaciones.

• La única métrica de uso de recursos admitida es la CPU.
• No se admiten los balanceadores de cargas de red de transferencia ni de proxy.
• Solo se admite la API de Gateway. No se admiten las APIs de Service ni de Ingress.
• El balanceo de cargas basado en el uso no funciona bien si tu tráfico es muy irregular. El rebalanceo del tráfico tarda hasta 30 segundos cuando los Pods alcanzan su utilización máxima. Se espera que el indicador de utilización aumente con el tráfico entrante, pero este retraso significa que el balanceo de cargas basado en la utilización necesita tiempo para ajustarse. Para obtener un rendimiento óptimo, el balanceo de cargas basado en la utilización funciona mejor en entornos con flujos de tráfico fluidos y predecibles.
• No se admiten los clústeres de pila doble (clústeres con una dirección IPv4 y una dirección IPv6).
• El balanceo de cargas basado en la utilización puede tardar hasta 30 segundos en actualizarse y ajustar la distribución del tráfico después de los cambios de configuración, como modificar o quitar el campo dryRun en un GCPBackendPolicy. Esta demora es un comportamiento conocido en todo el sistema. Por lo tanto, esta función es más adecuada para aplicaciones con patrones de tráfico relativamente estables que pueden tolerar esta latencia de actualización.

De forma predeterminada, el balanceo de cargas basado en la utilización está inhabilitado para tus servicios de GKE. Debes habilitarlo de forma explícita. Si no estableces un umbral de utilización máximo, el sistema usará el 80% de utilización por extremo de forma predeterminada.

Tu objetivo al configurar el balanceo de cargas basado en la utilización es optimizar la distribución del tráfico para que los Pods de backend puedan administrar su carga de trabajo de manera eficiente, lo que mejora el rendimiento de la aplicación y el uso de recursos.

Habilita el balanceo de cargas basado en el uso y el perfil de HPA de rendimiento

Antes de configurar el balanceo de cargas basado en la utilización, asegúrate de que tu clúster de GKE admita las funciones requeridas. El balanceo de cargas basado en la utilización usa métricas personalizadas, como la CPU, para tomar decisiones de enrutamiento más inteligentes. Estas decisiones dependen de lo siguiente:

• API de Gateway, que permite políticas a nivel del servicio a través de GCPBackendPolicy.
• El perfil de HPA de rendimiento, que permite que las cargas de trabajo se ajusten más rápido y de forma más agresiva con el uso de indicadores de la CPU.

Habilita la API de Gateway y el perfil de HPA de rendimiento

Autopilot

La API de Gateway y el perfil de HPA de rendimiento están disponibles de forma predeterminada en un clúster de Autopilot.

Standard

Para crear un clúster Standard nuevo con el perfil de HPA de rendimiento y la API de Gateway habilitada, ejecuta el siguiente comando:

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

Reemplaza lo siguiente:

• CLUSTER_NAME por el nombre del clúster nuevo.
• LOCATION con la región o zona de Compute Engine de tu clúster.
• PROJECT_ID por el ID del proyecto
• CLUSTER_VERSION con la versión de GKE, que debe ser 1.33.1-gke.1918000 o posterior

Para habilitar el perfil de HPA de rendimiento y la API de Gateway en un clúster estándar de GKE existente, usa lo siguiente:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

Reemplaza lo siguiente:

• CLUSTER_NAME por el nombre del clúster nuevo.
• LOCATION con la región o zona de Compute Engine de tu clúster.
• PROJECT_ID por el ID del proyecto

Para obtener más información sobre el perfil de rendimiento del HPA, consulta Cómo configurar el perfil de rendimiento del HPA.

Configura el balanceo de cargas basado en la utilización

Una vez que tu clúster esté listo, define una política que indique cómo se enruta el tráfico según la utilización del backend. Debes usar la API de Kubernetes Gateway a través de GCPBackendPolicy para la configuración.

Requisitos previos

Antes de configurar el balanceo de cargas basado en la utilización con la API de Gateway, asegúrate de que tu clúster de GKE cumpla con los siguientes requisitos:

1. Implementa una aplicación: Asegúrate de implementar una aplicación de Kubernetes con un recurso de Deployment. Para obtener más información, consulta Implementa una aplicación en un clúster de GKE.

   Nota: Para que el balanceo de cargas basado en la utilización funcione correctamente, debes definir el recurso requests, en especial para la CPU, en las especificaciones del contenedor de tu Deployment. Esto permite que el sistema determine con precisión el uso de recursos de referencia y reequilibre el tráfico de manera eficaz. Si no se define requests, es posible que el mecanismo de balanceo de cargas no se comporte como se espera.

   Por ejemplo, un manifiesto de implementación típico podría incluir una sección de recursos como la siguiente:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     # ... other deployment configurations ...
     template:
       # ... other template configurations ...
       spec:
         containers:
           - name: your-container-name
             image: your-image
             ports:
               - containerPort: 8080
             resources:
               limits:
                 cpu: 100m
                 memory: 45Mi
               requests:
                 cpu: 100m
                 memory: 45Mi
   

2. Expón la aplicación con un Service: Debes exponer la aplicación con un Service de Kubernetes. Para obtener más información sobre cómo funcionan los servicios y cómo configurarlos, consulta Comprende los servicios de Kubernetes.

3. Usa un balanceador de cargas de aplicaciones basado en la API de Gateway: Expón el servicio con un balanceador de cargas de aplicaciones administrado por GKE que se configure a través de la API de Gateway. Para obtener más información, consulta Implementa Gateways.

Crea un objeto GCPBackendPolicy para el balanceo de cargas basado en la CPU

Esta configuración permite que GKE distribuya el tráfico de forma dinámica según el uso de CPU en tiempo real de cada Pod de backend.

Para habilitar el balanceo de cargas basado en la utilización para los servicios de GKE, usa el recurso personalizado GCPBackendPolicy de la API de Kubernetes Gateway.

El recurso personalizado GCPBackendPolicy te permite definir de forma declarativa el comportamiento del balanceo de cargas dentro de tu clúster de Kubernetes. Si especificas métricas de uso de CPU, controlas cómo se distribuye el tráfico entre los backends según su uso de recursos actual. Este enfoque ayuda a mantener el rendimiento de la aplicación, evita que los Pods individuales se sobrecarguen y mejora la confiabilidad y la experiencia del usuario de la aplicación.

1. Guarda el siguiente manifiesto de muestra como my-backend-policy.yaml:

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
     namespace: team-awesome
   spec:
     targetRef:
       group: ""
       kind: Service
       name: super-service
     default:
       balancingMode: CUSTOM_METRICS
       customMetrics:
       - name: gke.cpu
         dryRun: false
   

   Ten en cuenta lo siguiente:

   • spec.targetRef.kind: Service: Se orienta a un servicio de Kubernetes estándar dentro del mismo clúster.
   • spec.targetRef.kind: ServiceImport: Se orienta a un servicio de otro clúster en una configuración de varios clústeres.
   • balancingMode: CUSTOM_METRICS: Habilita el balanceo de cargas basado en métricas personalizadas.
   • name: gke.cpu: Especifica el uso de CPU como la métrica para la distribución del tráfico.

   Si no se especifica el campo maxUtilizationPercent, el umbral de utilización predeterminado es del 80%. El tráfico se reequilibra cuando un backend supera el 80% de uso de CPU.

2. Aplica el manifiesto de muestra a tu clúster:

   kubectl apply -f my-backend-policy.yaml
   

Si basas la distribución del tráfico en el uso de CPU en tiempo real, optimizarás automáticamente el rendimiento. Esta acción ayuda a evitar la sobrecarga en los Pods individuales.

Consideraciones importantes para dryRun y balancingMode

Cuando configures GCPBackendPolicy con métricas personalizadas, ten en cuenta la interacción entre GCPBackendPolicy y el campo dryRun en la definición de customMetrics.balancingMode Esta interacción determina cómo el balanceador de cargas usa tus métricas personalizadas. Para obtener más información sobre las métricas personalizadas y sus restricciones, incluidas las relacionadas con los modos de balanceo, consulta Métricas personalizadas de Cloud Load Balancing.

• balancingMode: CUSTOM_METRICS

  • Para distribuir el tráfico en función de una métrica personalizada, al menos una métrica personalizada de la lista customMetrics debe tener dryRun configurado como false. Este parámetro de configuración le indica al balanceador de cargas que use de forma activa esa métrica para las decisiones de rebalanceo.
  • Puedes incluir otras métricas personalizadas con dryRun: true junto con métricas que no sean de ejecución de prueba. Esto te permite probar o supervisar métricas nuevas, como el uso de la GPU, sin que afecten el tráfico, mientras que otra métrica, como el uso de la CPU con dryRun: false, controla el balance.
  • Si balancingMode es CUSTOM_METRICS y todas las métricas personalizadas tienen dryRun establecido en true, recibirás un error. Por ejemplo: gceSync: generic::invalid_argument: Update: Invalid value for field 'resource.backends[0]': '...'. CUSTOM_METRICS BalancingMode requires at least one non-dry-run custom metric. El balanceador de cargas necesita una métrica activa para tomar decisiones.

• balancingMode es RATE o algún otro modo que no sea de métrica personalizada

  • Si el balanceo de cargas se basa en criterios distintos de las métricas personalizadas, como RATE para las solicitudes por segundo, puedes establecer dryRun: true para todas las métricas personalizadas. Esto te permite supervisar métricas personalizadas sin afectar el mecanismo de balanceo principal. Esto es útil para probar nuevas métricas personalizadas antes de cambiar tu balancingMode a CUSTOM_METRICS.

• Supervisa métricas personalizadas

  • Después de configurar tu objeto GCPBackendPolicy y comenzar a enviar tráfico a tu aplicación, las métricas personalizadas, como gke.cpu, tardarán un tiempo en aparecer en el Explorador de métricas.
  • Para que las métricas personalizadas estén visibles y activas en el Explorador de métricas, debe haber tráfico real que fluya a través del backend que supervisa la política. Si no hay tráfico, es posible que la métrica solo se vea en "Recursos inactivos" en el Explorador de métricas.

Cómo establecer un umbral de uso de CPU personalizado

De forma predeterminada, GKE distribuye el tráfico lejos de los backends que superan el 80% de utilización de la CPU. Sin embargo, algunas cargas de trabajo pueden tolerar un uso de CPU más alto o más bajo antes de requerir una redistribución del tráfico. Puedes personalizar este umbral con el campo maxUtilizationPercent en el recurso GCPBackendPolicy.

1. Para configurar un objeto Service de GKE de modo que permita que los backends utilicen hasta el 70% de la CPU antes de que se active el rebalanceo, guarda el siguiente manifiesto de muestra como my-backend-policy.yaml:

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
     namespace: team-awesome
   spec:
     targetRef:
       group: ""
       kind: Service
       name: super-service
     default:
       balancingMode: CUSTOM_METRICS
       customMetrics:
       - name: gke.cpu
         maxUtilizationPercent: 70
   

   Ten en cuenta lo siguiente:

   • El campo maxUtilizationPercent acepta valores del 0 al 100. Un valor de 100 significa que un backend puede usar toda su capacidad de CPU antes de que se reequilibre el tráfico.
   • Para las cargas de trabajo sensibles a la latencia que requieren una descarga anticipada, usa un umbral más bajo.
   • Para las cargas de trabajo diseñadas para ejecutarse cerca de la capacidad máxima, usa un umbral más alto.
   • Para los servicios de varios clústeres, spec.targetRef.kind debe ser ServiceImport y group debe ser net.gke.io.

2. Aplica el manifiesto de muestra a tu clúster:

   kubectl apply -f my-backend-policy.yaml
   

Si habilitas un umbral de uso de CPU personalizado, puedes controlar la distribución del tráfico en función del uso de CPU del backend.

(Opcional) Habilita el modo de ejecución de prueba

El modo de ejecución de prueba supervisa la utilización de recursos de tus Pods sin cambiar la distribución del tráfico. Cuando se habilita el modo de prueba, las métricas se exportan a Cloud Monitoring, pero Cloud Load Balancing las ignora y usa el comportamiento predeterminado del balanceo de cargas.

1. Para habilitar el modo de ejecución de prueba para tu servicio de GKE, guarda el siguiente manifiesto de muestra como my-backend-policy.yaml:

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
   spec:
     targetRef:
       group: ""
       kind: Service
       name: store-v1
     default:
       balancingMode: RATE
       maxRatePerEndpoint: 10
       customMetrics:
       - name: gke.cpu
         dryRun: true
   

2. Aplica el manifiesto de muestra a tu clúster:

   kubectl apply -f my-backend-policy.yaml
   

Cuando habilitas el modo de ejecución de prueba, ocurre lo siguiente:

• Cloud Load Balancing ignora las métricas de uso de CPU y, en su lugar, usa el comportamiento predeterminado del balanceo de cargas.

• Las métricas se siguen exportando a Cloud Monitoring en network.googleapis.com/loadbalancer/backend/lb_custom_metrics.

Después de revisar las métricas, quita el campo dryRun de tu GCPBackendPolicy y vuelve a aplicar la configuración. Si se producen problemas después de inhabilitar la prueba, vuelve a habilitarla agregando dryRun: true a la política.

Verifica la política

Para confirmar que el objeto GCPBackendPolicy se aplicó a tu servicio de GKE y verificar que los controladores de GKE reconocen la política, ejecuta el siguiente comando:

kubectl describe gcpbackendpolicy POLICY_NAME -n NAMESPACE

El resultado es similar a este:

Name:         <your policy name>
Namespace:    <your namespace>
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  ...
  Generation:          1
  Resource Version:    …
  UID:                 …
Spec:
  Default:
    Balancing Mode:  CUSTOM_METRICS
    Custom Metrics:
      Dry Run:  false
      Name:     gke.cpu
  Target Ref:
    Group:
    Kind:   Service
    Name:   super-service
Status:
  Conditions:
    Last Transition Time:  …
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
…

Configura el balanceo de cargas basado en la utilización con las APIs de Compute Engine

Te recomendamos que uses la API de Gateway de Kubernetes para configurar el balanceo de cargas basado en la utilización para tus servicios de GKE.

Sin embargo, es posible que prefieras usar las APIs de Compute Engine o Terraform para administrar tus balanceadores de cargas directamente. Si eliges este enfoque, debes habilitar el balanceo de cargas basado en la utilización a nivel de BackendService.

1. Para un BackendService existente, habilita el balanceo de cargas basado en la utilización y adjunta un grupo de extremos de red (NEG), my-lb-neg, ejecutando el siguiente comando:

   gcloud compute backend-services add-backend MY_BACKEND_SERVICE \
     --network-endpoint-group my-lb-neg \
     --network-endpoint-group-zone=asia-southeast1-a \
     --global \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics 'name="gke.cpu",maxUtilization=0.8'
   

   Reemplaza lo siguiente:

   • MY_BACKEND_SERVICE por el nombre de tu BackendService.
   • CUSTOM_METRICS con CUSTOM_METRICS.

2. Para actualizar la configuración del balanceo de cargas basado en la utilización de una entrada de backend existente en tu BackendService en la que ya se adjuntó un NEG, ejecuta el siguiente comando:

   gcloud compute backend-services update-backend MY_BACKEND_SERVICE \
     --network-endpoint-group my-lb-neg \
     --network-endpoint-group-zone=asia-southeast1-a \
     --global \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics 'name="gke.cpu",maxUtilization=0.8'
   

   Reemplaza lo siguiente:

   • MY_BACKEND_SERVICE por el nombre de tu BackendService.
   • CUSTOM_METRICS con CUSTOM_METRICS.

Nota: Si usas métricas personalizadas, mantén la cantidad de dimensiones configuradas por debajo del límite del servicio. Si superas el límite, no podrás agregar más dimensiones.

Inhabilita el balanceo de cargas basado en la utilización para un servicio de GKE

Para inhabilitar el balanceo de cargas basado en la utilización en tus servicios de GKE, sigue estos pasos:

1. Si deseas conservar la política para otros parámetros de configuración, quita los campos balancingMode y customMetrics de tu GCPBackendPolicy.
2. Si ya no necesitas GCPBackendPolicy, puedes borrarlo.
3. Si usas las APIs de Compute Engine, vuelve a cambiar las marcas --balancing-mode y --custom-metrics de tu servicio de backend.

¿Qué sigue?

• Descripción general de grupos de extremos de red por zonas