Balanceo de carga

Istio proporciona varios algoritmos de balanceo de carga mediante Envoy para distribuir el tráfico de forma eficiente.

Tabla de contenido

¿Por qué el balanceo de carga?
Descripción general del balanceo de carga
Algoritmos de balanceo de carga
Detalles de Consistent Hash
Balanceo de carga basado en localidad
Configuración de Connection Pool
Ejemplos prácticos
Guía de selección de algoritmos
Mejores prácticas
Solución de problemas

¿Por qué el balanceo de carga?

Uso eficiente de recursos

El balanceo de carga distribuye el tráfico entre varias instancias para mejorar el rendimiento general y la estabilidad del sistema.

Beneficios principales

Problema	Sin balanceo de carga	Con balanceo de carga
Disponibilidad	Punto único de fallo (SPOF)	Failover automático ante fallos
Rendimiento	Sobrecarga de una instancia específica	Distribución uniforme de carga
Escalabilidad	Escalado horizontal difícil	Scale-out sencillo
Tiempo de respuesta	Inconsistente (0-1000 ms+)	Tiempo de respuesta consistente
Uso de recursos	Ineficiente (uso parcial)	Uso eficiente de recursos

Descripción general del balanceo de carga

Algoritmos de balanceo de carga

Istio proporciona los siguientes algoritmos de balanceo de carga.

Comparación de algoritmos

Algoritmo	Descripción	Casos de uso	Ventajas	Desventajas
ROUND_ROBIN	Distribución secuencial (predeterminado)	Servicios sin estado	Simple, equitativo	Posible desequilibrio de carga
LEAST_REQUEST	Mínimo de solicitudes activas	APIs de alto rendimiento, conexiones de DB	Ecualización de carga	Ligera sobrecarga
RANDOM	Distribución aleatoria	Alto volumen de tráfico	Simple, rápido	Posible desequilibrio a corto plazo
PASSTHROUGH	Destino original	Proxy TCP, enrutamiento SNI	Flexibilidad	Control limitado
CONSISTENT_HASH	Persistencia basada en hash	Persistencia de sesión, caché	Sesiones persistentes	Posible desequilibrio

1. ROUND_ROBIN (predeterminado)

Distribuye las solicitudes secuencialmente a cada endpoint.

Ejemplo de configuración:

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-round-robin
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

Casos de uso:

APIs REST sin estado
Pods con rendimiento idéntico
Cuando la configuración predeterminada es suficiente

Ventajas:

Implementación simple y predecible
Distribución equitativa

Desventajas:

No considera las diferencias de carga por Pod
Las solicitudes largas pueden provocar desequilibrio

2. LEAST_REQUEST

Enruta al endpoint con menos solicitudes activas.

Ejemplo de configuración:

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-least-request
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      warmupDurationSecs: 60  # 60 second warmup (optional)

Configuración avanzada:

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-least-request-advanced
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      warmupDurationSecs: 120  # New pod warmup
    connectionPool:
      http:
        http2MaxRequests: 100
        maxRequestsPerConnection: 10

Casos de uso:

APIs con tiempos de respuesta variables
Pools de conexiones de base de datos
Servicios con procesamiento intensivo
Cuando el balanceo de carga en tiempo real es importante

Ventajas:

Se adapta a la carga en tiempo real
Mejora la consistencia del tiempo de respuesta
Absorbe las diferencias de rendimiento por Pod

Desventajas:

Ligera sobrecarga (seguimiento de solicitudes activas)

3. RANDOM

Selecciona un endpoint aleatoriamente.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-random
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM

Casos de uso:

Tráfico de alto volumen (estadísticamente uniforme)
Cuando se necesita una selección simple y rápida
Cuando el rendimiento de los Pods es idéntico

Ventajas:

Selección muy rápida
Implementación simple
Estadísticamente uniforme a escala

Desventajas:

Posible desequilibrio a corto plazo
Impredecible

4. PASSTHROUGH

Se conecta directamente al destino original especificado por el cliente.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: tcp-passthrough
spec:
  host: "*.external-service.com"
  trafficPolicy:
    loadBalancer:
      simple: PASSTHROUGH

Casos de uso:

Proxy TCP
Enrutamiento basado en SNI
Conexiones directas a servicios externos
Modo TLS PASSTHROUGH

Ventajas:

Conserva la dirección de destino original
Enrutamiento flexible

Desventajas:

Control limitado del balanceo de carga

5. LEAST_CONN (obsoleto -> LEAST_REQUEST)

Nota: LEAST_CONN está obsoleto y se sustituye por LEAST_REQUEST.

Migración:

yaml

# Old version (deprecated)
trafficPolicy:
  loadBalancer:
    simple: LEAST_CONN

# New version
trafficPolicy:
  loadBalancer:
    simple: LEAST_REQUEST

Detalles de Consistent Hash

Consistent Hash enruta al mismo endpoint según atributos específicos para garantizar la persistencia de sesión.

Principio de funcionamiento de Consistent Hash

1. Basado en encabezado HTTP

Calcula el hash a partir del valor de un encabezado HTTP específico.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: user-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-user-id"

Casos de uso:

Persistencia de sesión por usuario
Enrutamiento basado en clave de API
Aislamiento por tenant

Calcula el hash a partir del valor de la cookie y genera automáticamente una cookie si no existe.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: cookie-hash
spec:
  host: web-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: "user-session"
          ttl: 3600s  # 1 hour TTL

Casos de uso:

Persistencia de sesión de aplicaciones web
Persistencia del carrito de compra
Consistencia de la experiencia de usuario

3. Basado en IP de origen

Calcula el hash a partir de la dirección IP de origen del cliente.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: source-ip-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        useSourceIp: true

Casos de uso:

Persistencia de sesión basada en IP
Limitación de tasa (por IP)
Caché regional

Precauciones:

Los clientes detrás de NAT pueden enrutarse al mismo Pod
Al usar proxies, verifique la IP real del cliente

4. Basado en parámetro de consulta HTTP

Calcula el hash a partir del valor de un parámetro de consulta.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: query-param-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpQueryParameterName: "user_id"

Casos de uso:

Enrutamiento basado en ID de recurso en APIs RESTful
Enrutamiento compatible con caché
Estrategias de sharding

5. Configuración de tamaño mínimo del anillo

Establezca el tamaño mínimo del anillo de Consistent Hash para minimizar la redistribución.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: hash-with-ring-size
spec:
  host: cache-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-cache-key"
        minimumRingSize: 1024  # Default: 1024

Explicación:

Un tamaño de anillo mayor proporciona una distribución más uniforme
Reduce la proporción de claves redistribuidas al añadir o eliminar un Pod
Uso de memoria ligeramente mayor

Valores recomendados:

Escala pequeña (< 10 Pods): 1024 (predeterminado)
Escala media (10-50 Pods): 2048
Escala grande (50+ Pods): 4096

Ejemplo de combinación de Consistent Hash

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: advanced-consistent-hash
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: "session-id"
          path: "/api"
          ttl: 7200s  # 2 hours
        minimumRingSize: 2048
    connectionPool:
      http:
        maxRequestsPerConnection: 100
        idleTimeout: 300s

Precauciones de Consistent Hash

1. Riesgo de desequilibrio

Causa: Concentración de tráfico en valores hash específicos

Soluciones:

Aumente minimumRingSize
Use combinaciones de varias claves hash
Considere el algoritmo Bounded Load (no compatible con Envoy)

2. Redistribución al añadir/eliminar un Pod

yaml

# On pod scale out
# - Before: Pod 1, Pod 2, Pod 3
# - After: Pod 1, Pod 2, Pod 3, Pod 4
# - Result: ~25% of sessions redistributed to different pods

Estrategias de mitigación:

Use apagado controlado
Use almacenamiento de sesión externo (Redis, Memcached)
Escale gradualmente