Domina el balanceo de carga en Kubernetes: 5 opciones técnicas con ejemplos

¿Qué es el balanceo de carga en Kubernetes?

El balanceo de carga en Kubernetes es el proceso automatizado de distribuir el tráfico de red entre varios Pods para garantizar alta disponibilidad, escalabilidad y un rendimiento óptimo. Opera en dos niveles principales: la gestión interna dentro del clúster y la exposición externa para los usuarios externos.

Al abstraer la complejidad del enrutamiento y la distribución de solicitudes, Kubernetes permite a los desarrolladores desplegar aplicaciones escalables sin gestionar manualmente la distribución del tráfico. Esta automatización es esencial para la alta disponibilidad, la tolerancia a fallos y el rendimiento en los entornos modernos basados en contenedores.

Opciones técnicas para implementar el balanceo de carga en Kubernetes:

• ClusterIP (interno): Usa una IP virtual para distribuir el tráfico entre los Pods dentro del clúster, lo que la convierte en la opción predeterminada para la comunicación interna entre servicios.
• NodePort: Expone un Service en un puerto estático en cada nodo del clúster, lo que permite a los clientes externos acceder a las aplicaciones a través de <NodeIP>:<NodePort>.
• LoadBalancer: Se integra con balanceadores de carga de la nube o de la infraestructura para ofrecer una dirección IP externa que distribuye el tráfico entre los nodos del clúster y los Pods de backend.
• Ingress: Ofrece enrutamiento HTTP/HTTPS de capa 7, lo que permite que varios Services compartan un único punto de entrada externo con reglas de enrutamiento basadas en host y en ruta.
• Gateway API: Usa recursos dedicados de Gateway y Route para ofrecer una gestión de tráfico avanzada y basada en políticas, con soporte para múltiples protocolos y separación entre equipos.

Este artículo forma parte de una serie sobre el scheduling en Kubernetes.

Por qué se necesita el balanceo de carga en Kubernetes

Los entornos de Kubernetes son dinámicos. Los pods pueden crearse, terminarse, reprogramarse o escalar en cualquier momento según la demanda de la aplicación o las condiciones del clúster. Sin balanceo de carga, el tráfico podría seguir fluyendo hacia pods sobrecargados o no disponibles, lo que provocaría respuestas lentas, solicitudes fallidas o caídas del servicio.

El balanceo de carga ayuda a Kubernetes a mantener un rendimiento y una disponibilidad consistentes de las aplicaciones. Distribuye las solicitudes entre los pods en buen estado y redirige el tráfico cuando se producen fallos. Esto permite que las aplicaciones sigan atendiendo a los usuarios durante caídas de pods, rolling updates o cambios en la infraestructura.

Las razones principales por las que se necesita balanceo de carga en Kubernetes incluyen:

• Evitar la sobrecarga de tráfico en un solo pod o nodo
• Facilitar el escalado horizontal distribuyendo las solicitudes entre réplicas
• Mantener la alta disponibilidad ante fallos de pods o nodos
• Permitir despliegues sin tiempo de inactividad y rolling updates
• Mejorar los tiempos de respuesta y la fiabilidad de las aplicaciones
• Simplificar el enrutamiento del tráfico en entornos dinámicos de contenedores
• Permitir que los servicios escalen automáticamente cuando el tráfico cambia

Como los contenedores son efímeros y los workloads cambian constantemente, el balanceo de carga automatizado es un requisito fundamental para operar Kubernetes de forma estable.

5 formas de implementar el balanceo de carga en Kubernetes

1. ClusterIP (interno)

ClusterIP es el tipo de Service predeterminado de Kubernetes. Crea una dirección IP virtual accesible únicamente desde dentro del clúster, lo que la hace adecuada para la comunicación entre servicios internos como workloads de front-end, API y bases de datos. Los clientes externos no pueden acceder directamente a un servicio ClusterIP, lo que ayuda a aislar los servicios de backend de las redes públicas.

Cuando se envía una solicitud a la dirección ClusterIP, kube-proxy intercepta el tráfico y lo reenvía a uno de los Pods en buen estado detrás del Service. Actualiza automáticamente las reglas de enrutamiento a medida que se agregan, eliminan o reemplazan Pods, garantizando que las solicitudes se distribuyan entre las réplicas disponibles sin que las aplicaciones tengan que rastrear las direcciones IP de los Pods.

La decisión de balanceo suele apoyarse en implementaciones de red basadas en iptables, IPVS o eBPF, según la configuración del clúster. Las aplicaciones se comunican con un endpoint estable del Service mientras Kubernetes gestiona los cambios en los Pods subyacentes, lo que convierte a ClusterIP en la base de la mayor parte de la comunicación interna entre servicios.

2. NodePort

Un Service de tipo NodePort expone una aplicación en un puerto estático en todos los nodos del clúster de Kubernetes. Los clientes pueden acceder a la aplicación enviando solicitudes a <NodeIP>:<NodePort>, lo que permite que el tráfico externo llegue a los workloads sin necesidad de un balanceador de carga dedicado en la nube.

Cuando el tráfico llega a un nodo, kube-proxy enruta la solicitud a uno de los Pods seleccionados por el Service, incluso si ese Pod se ejecuta en un nodo diferente. Kubernetes sigue balanceando las solicitudes entre los Pods en buen estado a medida que cambia el número de réplicas, mientras el NodePort permanece constante.

Como todos los nodos escuchan en el mismo puerto, los usuarios pueden conectarse a cualquier nodo del clúster y llegar a la aplicación. NodePort se usa habitualmente en entornos de desarrollo, clústeres on-premises o como base para servicios de nivel superior como LoadBalancer, aunque exponer aplicaciones directamente mediante NodePorts es menos común en producción.

3. LoadBalancer

Un Service de tipo LoadBalancer se apoya en NodePort e integra Kubernetes con un balanceador de carga externo proporcionado por una plataforma en la nube o una infraestructura compatible. Aprovisiona una dirección IP pública o privada que los clientes usan para acceder a la aplicación sin conectarse directamente a los nodos individuales del clúster.

El balanceador de carga externo distribuye las conexiones entrantes entre los nodos del clúster. Luego, las solicitudes se reenvían a través del Service NodePort correspondiente, donde kube-proxy selecciona un Pod de backend en buen estado. Esto proporciona balanceo de carga tanto a nivel de infraestructura entre nodos como a nivel de Kubernetes entre Pods.

La mayoría de los servicios gestionados de Kubernetes aprovisionan automáticamente balanceadores de carga nativos de la nube de proveedores como AWS, Azure o Google Cloud cuando se crea este tipo de Service. Los health checks garantizan que el tráfico solo se envíe a nodos en buen estado, mientras Kubernetes actualiza continuamente los endpoints de backend a medida que los Pods escalan o se reemplazan.

4. Ingress

Ingress proporciona enrutamiento de capa 7 (HTTP/HTTPS) para varias aplicaciones a través de un único punto de entrada. En lugar de exponer cada Service con su propia dirección IP externa, un recurso Ingress define reglas de enrutamiento basadas en nombres de host, rutas de URL u otros atributos HTTP. Un controlador de Ingress, como Traefik, implementa estas reglas.

Cuando un cliente envía una solicitud HTTP o HTTPS, el controlador de Ingress evalúa las reglas de enrutamiento y reenvía la solicitud al Service de Kubernetes correspondiente. El Service luego distribuye el tráfico entre sus Pods de backend. Este enfoque simplifica la exposición de aplicaciones y admite funciones como terminación TLS, redirecciones, autenticación y reescritura de solicitudes.

Como varios Services pueden compartir el mismo endpoint externo, Ingress reduce la cantidad de direcciones IP públicas y balanceadores de carga necesarios. Se usa habitualmente para exponer aplicaciones web, APIs y microservicios, ofreciendo una gestión centralizada del tráfico HTTP y HTTPS.

5. Gateway API

Gateway API es un estándar de red de Kubernetes más reciente que ofrece una forma más flexible y extensible de gestionar el tráfico de aplicaciones. Separa la configuración de la infraestructura del enrutamiento de las aplicaciones, permitiendo que los equipos de plataforma gestionen los gateways mientras los equipos de aplicaciones definen cómo reciben el tráfico sus servicios.

El tráfico entra primero por un Gateway, que representa el punto de entrada de la red. Los recursos de enrutamiento, como HTTPRoute, especifican cómo deben coincidir y reenviarse las solicitudes hacia los Services de Kubernetes. Una vez que una solicitud llega al Service seleccionado, Kubernetes la distribuye entre los Pods disponibles usando sus mecanismos estándar de balanceo de carga.

En comparación con Ingress, Gateway API ofrece un control más granular sobre las políticas de enrutamiento, la división del tráfico y los entornos multi-tenant. También admite múltiples protocolos más allá de HTTP, incluidos TCP y gRPC, lo que lo hace más adecuado para requisitos de red complejos y despliegues de Kubernetes a gran escala.

Kubernetes LoadBalancer vs. Ingress vs. API Gateway

La siguiente tabla resume las diferencias entre estas opciones:

Casos de uso del balanceo de carga en Kubernetes

Balanceo de carga interno entre servicios

El balanceo de carga interno entre servicios distribuye el tráfico entre las aplicaciones que se ejecutan dentro del mismo clúster de Kubernetes. Permite que los servicios se comuniquen a través de endpoints estables mientras Kubernetes enruta automáticamente las solicitudes hacia los pods disponibles. Este enfoque ayuda a mantener el rendimiento y la disponibilidad a medida que los workloads escalan o los pods se reemplazan.

Tecnologías relevantes: Kubernetes Service (ClusterIP), kube-proxy, redes basadas en eBPF, service mesh, descubrimiento de servicios basado en DNS.

Balanceo de carga externo

El balanceo de carga externo gestiona el tráfico que entra al clúster desde usuarios, aplicaciones o sistemas externos. Proporciona un punto de entrada público y distribuye las solicitudes entrantes entre los servicios de backend en buen estado. Esto permite que las aplicaciones manejen mayores volúmenes de tráfico y permanezcan disponibles durante fallos, tareas de mantenimiento u operaciones de escalado.

Tecnologías relevantes: Service de tipo LoadBalancer, balanceadores de carga de capa 4, Ingress, Gateway API, terminación TLS.

Gestión del tráfico norte-sur

La gestión del tráfico norte-sur se ocupa del tráfico que fluye entre los clientes externos y los workloads que se ejecutan dentro del clúster. Se usa comúnmente para aplicaciones públicas, APIs e integraciones con socios. Más allá del balanceo de carga, suele incluir enrutamiento, aplicación de políticas de seguridad, filtrado de tráfico y cifrado para controlar cómo acceden las solicitudes externas a los servicios internos.

Tecnologías relevantes: Ingress, Gateway API, enrutamiento de capa 7, terminación TLS, políticas de autenticación y autorización, integración con firewall de aplicaciones web.

Gestión del tráfico este-oeste

La gestión del tráfico este-oeste se centra en la comunicación entre servicios dentro del clúster o entre entornos de Kubernetes conectados. En arquitecturas de microservicios, las aplicaciones intercambian solicitudes internamente con frecuencia, por lo que una distribución eficiente del tráfico resulta crítica para el rendimiento y la fiabilidad. Este tipo de balanceo también facilita la observabilidad, las políticas de seguridad y el control del tráfico entre servicios.

Tecnologías relevantes: Kubernetes Service, kube-proxy, service mesh, redes basadas en eBPF, mTLS, políticas de tráfico, descubrimiento de servicios.

Balanceo de carga multiclúster y global

El balanceo de carga multiclúster y global distribuye el tráfico entre varios clústeres de Kubernetes ubicados en distintas regiones, zonas de disponibilidad, proveedores de nube o centros de datos. Esto mejora la resiliencia al evitar que un solo clúster se convierta en un punto único de fallo y puede reducir la latencia dirigiendo a los usuarios a la ubicación más adecuada. Se usa comúnmente para recuperación ante desastres, aplicaciones globales y despliegues a gran escala.

Tecnologías relevantes: Gateway API, balanceo de carga global, enrutamiento de tráfico basado en DNS, redes multiclúster, service mesh, failover de tráfico, geoenrutamiento.

Ejemplos de balanceo de carga en Kubernetes

Los ejemplos de esta sección están adaptados de la documentación de Kubernetes.

Ejemplo de Service de Kubernetes

El siguiente Deployment crea tres réplicas de una aplicación NGINX. Cada Pod lleva la etiqueta app: nginx, lo que permite que un Service de Kubernetes seleccione los Pods y les envíe tráfico.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

Este Deployment mantiene tres Pods de NGINX en ejecución. Si un Pod se elimina o falla, el ReplicaSet del Deployment crea un Pod de reemplazo. La readiness probe ayuda a Kubernetes a determinar cuándo cada Pod está listo para recibir tráfico a través de un Service.

Ejemplo de Service ClusterIP

El siguiente Service ClusterIP expone el Deployment de NGINX dentro del clúster. El Service selecciona los Pods con la etiqueta app: nginx y reenvía el tráfico del puerto 80 del Service al puerto 80 de los Pods seleccionados.

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Este Service es accesible desde dentro del clúster. Otros Pods pueden conectarse a él usando el nombre del Service, nginx-clusterip, siempre que el DNS del clúster esté disponible.

Ejemplo de Service LoadBalancer

El siguiente Service expone los mismos Pods de NGINX de forma externa usando un proveedor de nube u otro entorno compatible con balanceadores de carga externos.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Cuando este Service se crea en un entorno compatible, Kubernetes aprovisiona o configura un balanceador de carga externo y registra la dirección externa en el estado del Service. El tráfico enviado a la dirección externa se reenvía al Service y luego a los Pods de backend correspondientes.

Ejemplo de Ingress

El siguiente Ingress enruta el tráfico HTTP de example.com hacia el Service interno nginx-clusterip.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-clusterip
                port:
                  number: 80

Este Ingress define reglas de enrutamiento HTTP, pero solo funciona si hay un controlador de Ingress ejecutándose en el clúster. El controlador de Ingress implementa el comportamiento de enrutamiento y reenvía las solicitudes coincidentes al Service de backend.

Ejemplo de API Gateway

El siguiente ejemplo usa la Gateway API de Kubernetes para enrutar el tráfico HTTP a través de un Gateway hacia el Service interno nginx-clusterip. Gateway API es una familia de APIs de red de Kubernetes para el aprovisionamiento dinámico de infraestructura y el enrutamiento avanzado de tráfico, y los recursos HTTPRoute pueden hacer coincidir solicitudes HTTP y reenviarlas a Services de Kubernetes.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: api.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-api-route
spec:
  parentRefs:
    - name: nginx-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: nginx-clusterip
          port: 80

En este ejemplo, el Gateway representa el punto de entrada del API gateway, mientras que el HTTPRoute define cómo deben enrutarse las solicitudes HTTP. Las solicitudes enviadas a api.example.com/api son aceptadas por el listener del Gateway, coinciden con la ruta y se reenvían al Service nginx-clusterip. El Service luego distribuye el tráfico entre los Pods de NGINX correspondientes.

Nota: este ejemplo usa NGINX Gateway Fabric como implementación de la gateway class, que es distinta del controlador Ingress NGINX mantenido por la comunidad.

Este enfoque es similar a Ingress, pero Gateway API ofrece un modelo más expresivo y orientado a roles. Los equipos de infraestructura pueden gestionar los recursos Gateway, mientras que los equipos de aplicaciones gestionan los recursos de ruta como HTTPRoute. Esto lo hace útil para patrones de API gateway donde los equipos necesitan enrutamiento basado en nombre de host, enrutamiento basado en ruta, control de políticas de tráfico y una separación más limpia entre la configuración de la plataforma y el enrutamiento de las aplicaciones.