Soluciona problemas de distribución desigual del tráfico

En este documento, se muestra cómo resolver problemas relacionados con la distribución de tráfico desigual a los servicios de Kubernetes.

Identifica los síntomas de la distribución de tráfico desigual

La distribución desigual del tráfico, a menudo denominada puntos de acceso, se produce cuando un subconjunto de Pods o nodos controla una cantidad desproporcionada de la carga de trabajo total, mientras que otros permanecen subutilizados.

Entre los síntomas comunes, se incluyen los siguientes:

• Cuellos de botella de rendimiento: Los usuarios pueden experimentar tiempos de espera intermitentes, errores HTTP 5xx o pérdida de paquetes en conexiones de red sobreutilizadas.
• Agotamiento de recursos: Los Pods o nodos específicos muestran un uso de CPU o memoria significativamente más alto que el resto de la flota.
• Patrones de desequilibrio de tráfico:
  • Desequilibrio por Pod: El tráfico llega solo a un pequeño subconjunto de Pods disponibles, aunque todos los Pods se informan como en buen estado y listos.
  • Desequilibrio por nodo: Uno o más nodos reciben significativamente más paquetes o solicitudes que otros, lo que suele ocurrir cuando se usa externalTrafficPolicy: Local con una ubicación desigual de los Pods.
  • Sesiones de cliente persistentes: Todas las solicitudes de un solo cliente de gran volumen se enrutan de forma coherente al mismo Pod de backend.

Diagnóstico con Cloud Monitoring

Para confirmar estos síntomas, visualiza los patrones de tráfico con las siguientes métricas:

• Para la capa 7 (entrada/puerta de enlace): traza loadbalancing.googleapis.com/backend/request_count y agrupa por backend_target para comparar los volúmenes de solicitudes en diferentes backends.

Comprende las causas comunes de la distribución de tráfico desigual

En esta sección, se describen las causas comunes de la distribución desigual del tráfico a los servicios de Kubernetes. Este desequilibrio puede generar cuellos de botella de rendimiento, agotamiento de recursos en ciertos Pods y una disponibilidad reducida de la aplicación, ya que algunos Pods reciben significativamente más tráfico que otros, mientras que algunos reciben muy poco o nada.

La afinidad de sesión causa una distribución desigual

El siguiente problema ocurre cuando los balanceadores de cargas con la afinidad de sesión habilitada enrutan de forma coherente las solicitudes del mismo cliente al mismo Pod de backend. Si un cliente en particular genera un gran volumen de tráfico, ese Pod se sobrecarga, lo que genera un punto de acceso en el que recibe significativamente más carga que otros, mientras que otros Pods permanecen subutilizados.

Puedes configurar la afinidad de sesión en objetos de servicio de Kubernetes con el campo sessionAffinity.

Cuando sessionAffinity se establece en ClientIP, el servicio se asegura de que todas las conexiones que se originan en la misma dirección IP del cliente se enruten de forma coherente al mismo Pod de backend. Esto proporciona una verdadera afinidad de sesión basada en la IP del cliente.

Cuando sessionAffinity se establece en None (el comportamiento predeterminado), los balanceadores de cargas de capa 4 suelen distribuir las conexiones con un hash de varios parámetros de red, como una tupla de 4 (dirección IP del cliente, dirección IP de destino, puerto de destino, protocolo) o una tupla de 5 (incluido el puerto de origen). Si bien este hash puede proporcionar cierta "persistencia" de conexión mediante el enrutamiento coherente de conexiones con valores de tupla idénticos al mismo backend, no garantiza que todas las conexiones de una dirección IP de cliente específica siempre vayan al mismo Pod si cambian otros elementos de tupla.

Para obtener más información, consulta Afinidad de sesión.

En el caso de la puerta de enlace de GKE, el CRD GCPTrafficDistributionPolicy configura la afinidad de sesión. Para obtener más información, consulta Configura los recursos de la puerta de enlace con políticas.

Para los balanceadores de cargas de red de transferencia externos regionales, puedes usar la afinidad de sesión para mantener la persistencia de la conexión a un backend específico. Sin embargo, ten en cuenta que la afinidad de sesión puede causar una distribución desigual si algunos clientes generan más tráfico que otros.

Para obtener más información, consulta Afinidad de sesión y Descripción general del balanceador de cargas de red de transferencia externo basado en servicios de backend.

En el siguiente ejemplo, se muestra un manifiesto de servicio con sessionAffinity: ClientIP:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  sessionAffinity: ClientIP  # This can cause uneven distribution
  ports:
  -   port: 80
    targetPort: 8080
  selector:
    app: my-app

La agrupación de conexiones causa una distribución desigual

La agrupación de conexiones se produce cuando los balanceadores de cargas reutilizan las conexiones existentes a Pods específicos, incluso si otros Pods tienen capacidad disponible. Este comportamiento puede causar un desequilibrio si algunas conexiones son más duraderas o controlan significativamente más solicitudes que otras. Esto concentra el tráfico en ciertos Pods, de manera similar a la afinidad de sesión, lo que crea puntos de acceso en los que esos Pods se sobrecargan mientras que otros permanecen subutilizados.

Los balanceadores de cargas implementan la agrupación de conexiones para mejorar el rendimiento mediante la reducción de la sobrecarga de establecer conexiones nuevas. Sin embargo, si no se administra correctamente, la agrupación de conexiones puede causar una distribución desigual del tráfico, en especial con las aplicaciones que mantienen conexiones de larga duración.

Para mitigar la distribución desigual causada por la agrupación de conexiones, implementa estrategias a nivel de la aplicación o del cliente:

• Configura los clientes para que usen varias conexiones: En lugar de depender de una sola conexión de larga duración, configura los clientes para que abran y administren un grupo de varias conexiones al balanceador de cargas. Esto permite que el balanceador de cargas distribuya los nuevos intentos de conexión entre los Pods de backend disponibles, lo que mejora la distribución de tráfico general.

• Cierra y vuelve a abrir las conexiones de forma periódica: Para las aplicaciones que mantienen conexiones de larga duración de forma natural, configúralas o configura sus clientes para que cierren y vuelvan a abrir las conexiones de forma periódica. Si bien esto genera una ligera sobrecarga de restablecimiento de la conexión, le proporciona al balanceador de cargas nuevas oportunidades para distribuir los intentos de conexión posteriores a Pods de backend diferentes y menos utilizados. Este enfoque es particularmente eficaz para los servicios en los que la finalización y el restablecimiento de la conexión no son demasiado perjudiciales.

• Implementa un vaciado de conexiones agresivo: Asegúrate de que tus Pods estén configurados para el cierre ordenado y el vaciado de conexiones. Cuando un Pod se finaliza de forma correcta (por ejemplo, durante una implementación o una reducción), el balanceador de cargas debe dejar de enviarle conexiones nuevas y permitir que las conexiones existentes se completen o se vacíen. Esto permite que el tráfico se desplace a otros Pods con mayor fluidez y ayuda a evitar que el tráfico se concentre en los Pods que finalizan.

Si administras de forma activa el comportamiento de la conexión, puedes ayudar a los balanceadores de cargas a distribuir el tráfico de manera más uniforme, incluso con conexiones de larga duración.

El hash de 5 tuplas causa una distribución desigual

Este es el comportamiento predeterminado para muchos balanceadores de cargas de capa 4 cuando no configuras de forma explícita la afinidad de sesión. Si muchas conexiones se originan en el mismo cliente o usan las mismas combinaciones de puertos, esto genera una distribución desigual.

Para resolver los desequilibrios causados por el hash, considera lo siguiente:

• Usa el balanceo de cargas de capa 7: La entrada y la puerta de enlace de GKE operan a nivel de la solicitud, lo que les permite distribuir solicitudes de un solo cliente en varios Pods de backend.

• Ajusta el comportamiento del cliente: Configura los clientes para que usen varias conexiones o un grupo más grande de puertos de origen.

La distribución desigual de Pods entre nodos causa una distribución desigual

Este problema surge cuando los Pods no se distribuyen de manera uniforme entre los nodos y el balanceador de cargas no usa el balanceo de cargas nativo del contenedor. Los nodos con más Pods reciben más tráfico, lo que puede provocar que algunos nodos se sobrecarguen mientras que otros se subutilizan.

Este problema es especialmente relevante cuando usas externalTrafficPolicy: Local.

La configuración de la política de tráfico externo causa una distribución desigual

El parámetro de configuración externalTrafficPolicy en tu servicio afecta la forma en que se enruta el tráfico.

• Clúster: Permite que el balanceador de cargas distribuya el tráfico a cualquier nodo en el clúster. Usa el parámetro de configuración Cluster para obtener la distribución más uniforme en todos los nodos y Pods disponibles.
• Local: Enruta el tráfico solo a los Pods que se ejecutan en el mismo nodo que recibió el tráfico. Esto puede generar una distribución desigual si no distribuyes los Pods de manera uniforme entre los nodos.

La afinidad de nodos causa una distribución desigual

El uso de la afinidad de nodos para restringir los Pods a un subconjunto de nodos puede provocar que esos nodos se sobrecarguen, en especial si la carga de trabajo no está bien balanceada entre ellos.

Asegúrate de que tus Pods no estén fijados a nodos específicos.