Configurar el balanceo de carga basado en la utilización para servicios de GKE

Autopilot Standard

Vista previa

Esta función está sujeta a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Las funciones previas a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

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

Puedes usar balanceadores de carga basados en la utilización para optimizar el rendimiento y la disponibilidad de las aplicaciones distribuyendo el tráfico de forma inteligente en función del uso de recursos en tiempo real de tus pods de GKE.

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

Precios

El balanceo de carga basado en la utilización es una función de GKE Gateway que está disponible sin coste adicional. Se siguen aplicando los precios de Cloud Load Balancing y GKE.

Cuotas

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

Antes de empezar

Antes de empezar, asegúrate de que has 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, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
  Nota: Si ya tienes instalada la CLI de gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines 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 tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

• Consulta los requisitos del controlador de la pasarela.
• Consulta las limitaciones.

Requisitos de GKE Gateway Controller

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

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

El balanceo de carga basado en la utilización de 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 de un balanceador de carga gestionado por Google Cloud.
• Todas las ediciones de GKE (Standard, Autopilot y Enterprise).
• Todos los balanceadores de carga de aplicaciones, excepto los balanceadores de carga de aplicaciones clásicos. Google Cloud

Limitaciones

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

• La única métrica de utilización de recursos admitida es la CPU.
• No se admiten los balanceadores de carga de red de proxy ni con paso a través.
• Solo se admite la API Gateway. No se admiten las APIs Service ni Ingress.
• El balanceo de carga basado en la utilización no funciona bien si el tráfico es muy irregular. El reequilibrio del tráfico tarda hasta 30 segundos cuando los pods alcanzan su utilización máxima. Se espera que la señal de utilización aumente con el tráfico entrante, pero este retraso significa que el balanceo de carga basado en la utilización necesita tiempo para ajustarse. Para obtener un rendimiento óptimo, el balanceo de carga basado en la utilización funciona mejor en entornos con flujos de tráfico fluidos y predecibles.
• No se admiten clústeres de doble pila (clústeres con una dirección IPv4 y una dirección IPv6).
• El balanceo de carga basado en la utilización puede tardar hasta 30 segundos en actualizarse y ajustar la distribución del tráfico después de que se produzcan cambios en la configuración, como modificar o quitar el campo dryRun en un GCPBackendPolicy. Este retraso 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 carga basado en la utilización está inhabilitado en los servicios de GKE. Debes habilitarla explícitamente. Si no define un umbral de uso máximo, el sistema utilizará el 80% de uso por punto de conexión de forma predeterminada.

El objetivo de configurar el balanceo de carga basado en la utilización es optimizar la distribución del tráfico para que los pods de backend puedan gestionar su carga de trabajo de forma eficiente, lo que mejora el rendimiento de las aplicaciones y el uso de los recursos.

Habilitar el balanceo de carga basado en la utilización y el perfil de HPA de rendimiento

Antes de configurar el balanceo de carga basado en la utilización, asegúrate de que tu clúster de GKE admita las funciones necesarias. El balanceo de carga 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 Gateway, que permite aplicar políticas a nivel de servicio mediante GCPBackendPolicy.
• El perfil de HPA de rendimiento, que permite que las cargas de trabajo se escalen de forma más rápida y agresiva mediante señales de CPU.

Habilitar la API Gateway y el perfil de HPA de rendimiento

Autopilot

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

Estándar

Para crear un clúster estándar con el perfil de HPA de rendimiento y la API 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

Haz los cambios siguientes:

• CLUSTER_NAME por el nombre de tu nuevo clúster.
• 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 la 1.33.1-gke.1918000 o una posterior.

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

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

Haz los cambios siguientes:

• CLUSTER_NAME por el nombre de tu nuevo clúster.
• 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 HPA de rendimiento, consulta Configurar el perfil de HPA de rendimiento.

Configurar el balanceo de carga basado en la utilización

Cuando el clúster esté listo, define una política que dirija el tráfico en función de la utilización del backend. Para la configuración, debes usar la API Gateway de Kubernetes a través de GCPBackendPolicy.

Requisitos previos

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

1. Despliega una aplicación: asegúrate de desplegar una aplicación de Kubernetes mediante un recurso Deployment. Para obtener más información, consulta Implementar una aplicación en un clúster de GKE.

   Nota: Para que el balanceo de carga basado en la utilización funcione correctamente, debes definir el recurso requests, sobre todo la CPU, en las especificaciones del contenedor de tu implementación. De esta forma, el sistema puede determinar con precisión el uso de recursos de referencia y reequilibrar el tráfico de forma eficaz. Si no se define requests, es posible que el mecanismo de balanceo de carga no funcione como se espera.

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

   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 mediante un servicio: debes exponer la aplicación mediante un servicio de Kubernetes. Para obtener más información sobre cómo funcionan los servicios y cómo configurarlos, consulta Información sobre los servicios de Kubernetes.

3. Usar un balanceador de carga de aplicaciones basado en la API Gateway: expón el servicio mediante un balanceador de carga de aplicaciones gestionado por GKE que esté configurado a través de la API Gateway. Para obtener más información, consulta Implementar pasarelas.

Crea un GCPBackendPolicy para el balanceo de carga basado en la CPU

Esta configuración permite que GKE distribuya el tráfico de forma dinámica en función del uso de la CPU en tiempo real de cada pod de backend.

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

El recurso personalizado GCPBackendPolicy te permite definir de forma declarativa el comportamiento del balanceo de carga en tu clúster de Kubernetes. Si especificas métricas de utilización de la CPU, puedes controlar cómo se distribuye el tráfico entre los back-ends en función del uso de recursos actual. Esta estrategia ayuda a mantener el rendimiento de las aplicaciones, evita que los pods individuales se sobrecarguen y mejora la fiabilidad y la experiencia de usuario de las aplicaciones.

1. Guarda el siguiente archivo de manifiesto de ejemplo 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 dirige a un servicio de Kubernetes estándar dentro del mismo clúster.
   • spec.targetRef.kind: ServiceImport: se dirige a un servicio de otro clúster en una configuración de varios clústeres.
   • balancingMode: CUSTOM_METRICS: habilita el balanceo de carga basado en métricas personalizadas.
   • name: gke.cpu: especifica el uso de CPU como 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 vuelve a equilibrar cuando un backend supera el 80% de uso de la CPU.

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

   kubectl apply -f my-backend-policy.yaml
   

Al basar la distribución del tráfico en la utilización de la CPU en tiempo real, optimizas el rendimiento automáticamente. Esta acción ayuda a evitar la sobrecarga en los pods individuales.

Consideraciones importantes sobre dryRun y balancingMode

Cuando configure GCPBackendPolicy con métricas personalizadas, tenga en cuenta la interacción entre balancingMode y el campo dryRun en la definición de customMetrics. Esta interacción determina cómo usa el balanceador de carga 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 el valor dryRun definido como false. Este ajuste indica al balanceador de carga que use de forma activa esa métrica para tomar decisiones de reequilibrado.
  • Puede incluir otras métricas personalizadas con dryRun: true junto con métricas que no sean de prueba. De esta forma, puedes probar o monitorizar nuevas métricas, como el uso de la GPU, sin que afecten al tráfico, mientras que otra métrica, como el uso de la CPU con dryRun: false, controla el balanceo.
  • Si balancingMode es CUSTOM_METRICS y todas las métricas personalizadas tienen dryRun con el valor true, se produce 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 carga necesita una métrica activa para tomar decisiones.

• balancingMode es RATE u otros modos que no sean de métricas personalizadas

  • Si el balanceo de carga se basa en criterios distintos de las métricas personalizadas, como RATE para las solicitudes por segundo, puedes definir dryRun: true para todas las métricas personalizadas. De esta forma, puedes monitorizar métricas personalizadas sin que afecte al mecanismo de equilibrio principal. Esto resulta útil para probar nuevas métricas personalizadas antes de cambiar de balancingMode a CUSTOM_METRICS.

• Monitorizar métricas personalizadas

  • Después de configurar GCPBackendPolicy y empezar 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 Explorador de métricas, debe haber tráfico real en el backend que monitoriza la política. Si no hay tráfico, es posible que la métrica solo se vea en "Recursos inactivos" en Explorador de métricas.

Definir un umbral de uso de CPU personalizado

De forma predeterminada, GKE distribuye el tráfico lejos de los back-ends que superan el 80% de uso de la CPU. Sin embargo, es posible que algunas cargas de trabajo toleren un uso de la CPU mayor o menor antes de requerir una redistribución del tráfico. Puede personalizar este umbral mediante el campo maxUtilizationPercent del recurso GCPBackendPolicy.

1. Para configurar un servicio de GKE de forma que permita que los back-ends utilicen hasta el 70% de la CPU antes de que se active el reequilibrado, guarda el siguiente manifiesto de ejemplo 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 vuelva a equilibrar el tráfico.
   • Para cargas de trabajo sensibles a la latencia que requieran una derivación temprana, usa un umbral inferior.
   • En el caso de las cargas de trabajo diseñadas para ejecutarse cerca de la capacidad máxima, usa un umbral más alto.
   • En el caso de los servicios de varios clústeres, spec.targetRef.kind debe ser ServiceImport y group debe ser net.gke.io.

2. Aplica el manifiesto de ejemplo 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) Habilitar el modo de prueba

El modo de prueba de funcionamiento monitoriza el uso de recursos de tus pods sin cambiar la distribución del tráfico. Cuando el modo de prueba se habilita, las métricas se exportan a Cloud Monitoring, pero Cloud Load Balancing las ignora y usa el comportamiento predeterminado del balanceo de carga.

1. Para habilitar el modo de prueba en tu servicio de GKE, guarda el siguiente archivo de manifiesto de ejemplo 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 ejemplo a tu clúster:

   kubectl apply -f my-backend-policy.yaml
   

Cuando habilitas el modo de prueba, ocurre lo siguiente:

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

• Las métricas seguirán exportándose 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 añadiendo dryRun: true a la política.

Verificar la política

Para confirmar que se ha aplicado el GCPBackendPolicy 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 debería ser similar al siguiente:

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:
…

Configurar el balanceo de carga basado en la utilización mediante las APIs de Compute Engine

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

Sin embargo, puede que prefieras usar las APIs de Compute Engine o Terraform para gestionar tus balanceadores de carga directamente. Si elige este enfoque, debe habilitar el balanceo de carga basado en la utilización a nivel de BackendService.

1. En un BackendService, habilita el balanceo de carga basado en la utilización y adjunta un grupo de puntos finales 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'
   

   Sustituye lo siguiente:

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

2. Para actualizar la configuración del balanceo de carga basado en la utilización de una entrada de backend de BackendService en la que ya se ha adjuntado 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'
   

   Sustituye lo siguiente:

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

Nota: Si usa métricas personalizadas, el número de dimensiones configuradas no debe superar el límite del servicio. Si superas el límite, no podrás añadir más dimensiones.

Inhabilitar el balanceo de carga basado en la utilización de un servicio de GKE

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

1. Si quieres mantener la política para otros ajustes, quita los campos balancingMode y customMetrics de tu GCPBackendPolicy.
2. Si ya no necesitas GCPBackendPolicy, puedes eliminarlo.
3. Si usas las APIs de Compute Engine, vuelve a cambiar las marcas --balancing-mode y --custom-metrics de tu servicio de backend.

Siguientes pasos

• Información general sobre los grupos de puntos finales de red por zonas