NodePort vs. LoadBalancer vs. Ingress: Cómo Elegir la Mejor Exposición de Servicios

Kubernetes asigna IPs temporales a los Pods y luego utiliza Servicios para proporcionar una forma estable de alcanzarlos. Dentro del clúster, un Servicio ClusterIP normal suele ser suficiente. La pregunta se vuelve más interesante cuando algo fuera del clúster necesita conectarse.

Los tres nombres que aparecen con más frecuencia son NodePort, LoadBalancer e Ingress. Están relacionados, pero no son intercambiables. NodePort abre un puerto en cada nodo. LoadBalancer solicita al proveedor de infraestructura un balanceador de carga externo. Ingress define reglas de enrutamiento HTTP y necesita un controlador Ingress para hacer realidad esas reglas.

---

1. Tipo de Exposición de Servicio: NodePort

El tipo de servicio NodePort es la forma más simple y primitiva de exponer un servicio externamente. Cuando defines un servicio como NodePort, Kubernetes abre un puerto estático específico en cada Nodo del clúster. Cualquier tráfico dirigido a ese puerto en cualquier nodo se enruta directamente al servicio.

Cómo Funciona NodePort

1. Se selecciona automáticamente un puerto aleatorio dentro de un rango designado (predeterminado: 30000-32767).
2. Este puerto se abre en todos los nodos del clúster.
3. El Servicio escucha en este NodePort, reenviando el tráfico a los Pods apropiados.

Para acceder a la aplicación, usas http://<IP_del_Nodo>:<NodePort>.

Casos de Uso y Limitaciones

Característica	Descripción
Caso de Uso	Entornos de desarrollo, pruebas, o donde el balanceo de carga externo es manejado por un dispositivo externo que no es en la nube.
Complejidad	Muy Baja.
Costo	Cero (si ignoras los costos subyacentes de las VMs).
Limitación	Requiere gestionar manualmente las reglas del firewall externo. Las IPs de los nodos suelen ser dinámicas. Restricción del rango de puertos (30000-32767).

Ejemplo de NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 8080
      # Opcional: especificar un NodePort, de lo contrario se elige uno automáticamente
      # nodePort: 30001 

Advertencia: NodePort expone el servicio a través de las IPs de los nodos y un puerto alto. Puede ser útil detrás de tu propio balanceador de carga externo, especialmente en bare metal, pero es incómodo como interfaz pública para una aplicación web en producción.

---

2. Tipo de Exposición de Servicio: LoadBalancer

El tipo de servicio LoadBalancer es el método estándar para exponer aplicaciones a Internet público en entornos de nube (AWS EKS, GCP GKE, Azure AKS).

Cuando un servicio se define como LoadBalancer, Kubernetes solicita a la integración del balanceador de carga del clúster que aprovisione un balanceador de carga externo. En clústeres gestionados en la nube, eso a menudo significa un balanceador de carga L4 de la nube. En clústeres bare-metal, podría significar un proyecto como MetalLB u otra integración local. El resultado suele ser una dirección externa estable que reenvía el tráfico al Servicio.

Integración con el Proveedor de Nube

El diferenciador clave de LoadBalancer es la integración profunda con la infraestructura de nube subyacente. El proveedor de nube maneja el ciclo de vida del balanceador de carga, las comprobaciones de salud y el enrutamiento.

Casos de Uso e Implicaciones de Costo

Característica	Descripción
Caso de Uso	Aplicaciones simples orientadas al público que requieren una dirección IP dedicada y estable. Adecuado para protocolos no HTTP/S (TCP/UDP).
Complejidad	Baja (en cuanto a configuración).
Costo	A menudo más alto en entornos de nube porque cada Servicio puede crear un recurso de balanceador de carga separado.
Beneficio	Proporciona alta disponibilidad inmediata y comprobaciones de salud automáticas.

Ejemplo de LoadBalancer

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

Tras la creación, el clúster asignará una dirección IP externa (visible en el estado del servicio) gestionada por el proveedor de nube.

---

3. Ingress de Kubernetes: Enrutamiento de Capa 7

Ingress es fundamentalmente diferente de NodePort y LoadBalancer. Ingress no es un tipo de Servicio, sino un objeto API que define reglas para el acceso externo, típicamente HTTP y HTTPS (Capa 7).

Ingress actúa como un punto de entrada central, permitiendo un enrutamiento sofisticado basado en nombres de host y rutas URL. Este enfoque es esencial para gestionar múltiples servicios detrás de una única dirección IP.

El Rol del Controlador Ingress

Para que las reglas de Ingress funcionen, primero debes desplegar un Controlador Ingress como ingress-nginx, Traefik, HAProxy, o un controlador del proveedor de nube. Las mallas de servicios como Istio también pueden proporcionar gestión de tráfico tipo gateway, pero no son lo mismo que la API básica de Ingress de Kubernetes.

El propio controlador Ingress suele exponerse utilizando un único Servicio LoadBalancer o NodePort.

Características Avanzadas de Ingress

Ingress brilla cuando necesitas características avanzadas de gestión de tráfico:

1. Optimización de Costos: Usar un único LoadBalancer de nube (para exponer el Controlador) en lugar de un LoadBalancer por servicio de aplicación.
2. Alojamiento Virtual: Enrutar el tráfico basado en nombres de host (api.example.com va al Servicio A; www.example.com va al Servicio B).
3. Enrutamiento Basado en Rutas: Enrutar el tráfico basado en rutas URL (/v1/usuarios va al Servicio A; /v2/publicaciones va al Servicio B).
4. Terminación SSL/TLS: Gestionar la gestión de certificados y el descifrado de forma centralizada.

Ejemplo de Recurso Ingress

Este ejemplo enruta el tráfico para api.example.com/v1 al servicio my-api-v1.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx # Especificar el controlador en uso
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api-v1
            port:
              number: 80
  # ... otras reglas para diferentes servicios/hosts

---

4. Guía de Comparación y Selección

Elegir el método óptimo implica sopesar factores como el entorno, la complejidad, el conjunto de características y el costo operativo.

Tabla Comparativa de Características

Característica	NodePort	LoadBalancer	Ingress
Capa	L4 (TCP/UDP)	L4 (TCP/UDP)	L7 (HTTP/S)
Estabilidad (IP)	Inestable (usa IP del Nodo)	Estable (IP de Nube Dedicada)	Estable (usa IP del Controlador)
Costo	Bajo (Alto overhead operativo)	Alto (Costo de recurso por servicio)	Moderado (Un LoadBalancer para el Controlador)
Lógica de Enrutamiento	Reenvío de puerto simple	Reenvío de puerto simple	Nombre de host, Ruta, Terminación SSL
Dependencia de Nube	Ninguna	Depende de la integración del proveedor	Depende del controlador y método de exposición
Preparado para Producción	A veces, normalmente detrás de otro balanceador de carga	Sí para exposición L4 simple	Sí para enrutamiento HTTP/S

Criterios de Decisión: Elegir tu Método de Exposición

1. Solo para Interno o Pruebas: Si solo necesitas probar la conectividad dentro de tu clúster, o si gestionas la red externa tú mismo (por ejemplo, en un entorno bare-metal), usa NodePort.

2. Para Exposición L4 Simple y Dedicada: Si tu aplicación usa protocolos no HTTP (como protocolos TCP personalizados o UDP) o si solo tienes una única aplicación pública que necesita acceso L4 dedicado e inmediato, usa LoadBalancer.

3. Para Exposición L7 Compleja con Múltiples Servicios: Si tienes múltiples servicios que exponer, requieres enrutamiento basado en rutas o nombres de host, necesitas terminación SSL centralizada, o deseas minimizar los costos de nube compartiendo una única IP externa, usa Ingress.

Para muchas aplicaciones HTTP/S en producción, Ingress es la opción habitual porque centraliza certificados y enrutamiento. Para bases de datos, brokers de mensajes, servidores de juegos, servicios TCP sin procesar, o cualquier cosa que no sea realmente HTTP, un Servicio LoadBalancer puede ser más claro. Para clústeres bare-metal, NodePort puede seguir siendo parte del diseño, pero comúnmente se coloca detrás de un balanceador de carga externo adecuado o una regla de firewall.

Cómo Encajan en Clústeres Reales

Una parte confusa es que estas opciones pueden apilarse unas sobre otras. Un objeto Ingress no expone paquetes por sí mismo. El controlador recibe tráfico de alguna manera, y ese "de alguna manera" suele ser un Servicio LoadBalancer en un clúster en la nube:

Internet
  -> Balanceador de Carga de Nube
  -> Servicio tipo LoadBalancer para ingress-nginx
  -> Pods del controlador Ingress
  -> Regla Ingress
  -> Servicio ClusterIP
  -> Pods de la Aplicación

En bare metal, la ruta podría usar NodePort en su lugar:

Internet o red de oficina
  -> Balanceador de carga externo / firewall
  -> IP_Nodo:NodePort
  -> Pods del controlador Ingress
  -> Servicio de la Aplicación

Por eso decir "usa Ingress en lugar de LoadBalancer" es un poco impreciso. Ingress a menudo sigue usando un balanceador de carga, pero permite que muchas aplicaciones HTTP compartan un único punto de entrada.

Ejemplos Prácticos

Usa NodePort cuando estés depurando un clúster de laboratorio, exponiendo un servicio temporalmente a una red privada, o integrándote con hardware de balanceo de carga que ya gestionas. No hagas que los usuarios recuerden https://app.example.com:31427 a menos que esto sea realmente una herramienta interna.

Usa LoadBalancer cuando un servicio necesite una dirección externa estable y el reenvío L4 sea suficiente. Una API TCP pública, un servicio UDP, o un único endpoint de administración interno pueden ser más simples de esta manera. También es útil cuando el protocolo de la aplicación no se ajusta al enrutamiento normal HTTP host/ruta.

Usa Ingress cuando tengas aplicaciones web. Si api.example.com, docs.example.com y app.example.com viven todos en el mismo clúster, Ingress te da un lugar para gestionar el enrutamiento de hosts y TLS. Añade cert-manager, y la renovación de certificados puede convertirse en un flujo de trabajo normal del clúster en lugar de una tarea manual de servidor.

Comprobaciones de Seguridad y Operaciones

El objeto de exposición es solo una parte de la decisión de producción. También necesitas preguntar quién puede alcanzar el endpoint, dónde termina TLS, cómo se preservan las IPs de origen y cómo se observan las fallas.

Con NodePort, revisa cuidadosamente las reglas del firewall. Kubernetes puede abrir el puerto en cada nodo, pero tu red aún decide si el mundo exterior puede alcanzarlo. En entornos de nube, los grupos de seguridad o las reglas de firewall a menudo necesitan permitir el rango de NodePort. En bare metal, la misma preocupación puede residir en un firewall perimetral. Si solo pretendes que una herramienta de administración privada sea accesible desde una VPN, haz cumplir eso fuera de Kubernetes también como dentro de él.

Con LoadBalancer, inspecciona las anotaciones específicas del proveedor. A menudo controlan si el balanceador de carga es interno o de cara a Internet, qué protocolo usa, qué ruta de comprobación de salud sondea y si preserva la IP de origen del cliente. Esos detalles varían según el proveedor, así que no asumas que un manifiesto copiado de una nube se comportará igual en otra.

Con Ingress, el centro operativo se traslada al controlador. Necesitas registros y métricas de los pods del controlador, no solo de los pods de la aplicación. Si una ruta falla, el Servicio y los Pods pueden estar saludables mientras que el controlador rechazó la regla, usó la clase de ingress incorrecta, perdió un secreto TLS, o enrutó a la ruta de backend equivocada. Una lista de verificación rápida ayuda:

kubectl get ingress
kubectl describe ingress example-ingress
kubectl get svc -n ingress-nginx
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

También sé claro sobre TLS. Ingress comúnmente termina HTTPS en el controlador y envía HTTP al Servicio backend. Eso está bien para muchos clústeres internos, pero algunos equipos requieren cifrado hasta el pod de la aplicación. Si ese es tu requisito, configura el backend TLS intencionalmente en lugar de asumir que Ingress lo proporciona automáticamente.

Modos de Falla Comunes

Si un NodePort funciona desde un nodo pero no desde otro, verifica si kube-proxy o el CNI del clúster están saludables en el nodo que falla. También verifica si el firewall externo permite el tráfico a cada IP de nodo que esperas usar.

Si un Servicio LoadBalancer permanece en Pending, el clúster probablemente no puede aprovisionar el balanceador de carga externo. En Kubernetes gestionado, eso puede significar falta de integración del controlador de nube, permisos, etiquetas de subred, cuota o configuraciones específicas del proveedor. En Kubernetes bare-metal, generalmente significa que no hay una implementación de balanceador de carga instalada.

Si un Ingress devuelve una página de backend predeterminada o un 404 del controlador, la solicitud llegó al controlador pero no coincidió con tu regla de host o ruta. Verifica DNS, el encabezado Host, ingressClassName, el tipo de ruta, y si el nombre del Servicio y el puerto son correctos. Si obtienes un certificado TLS para el nombre de host incorrecto, verifica el secreto referenciado por el Ingress y si otra regla de Ingress está reclamando el mismo host.

Un Atajo de Decisión Simple

Comienza con el protocolo. Si es HTTP o HTTPS y más de una aplicación podría eventualmente compartir el punto de entrada, usa Ingress. Si es TCP o UDP sin procesar y necesita una dirección externa estable, usa LoadBalancer. Si estás probando, integrándote con tu propio equipo de red, o construyendo una ruta bare-metal, NodePort puede ser parte de la respuesta.

Luego verifica el modelo operativo. Un equipo pequeño que ejecuta una API pública puede preferir un LoadBalancer porque es obvio y fácil de depurar. Un equipo de plataforma que aloja docenas de servicios web generalmente preferirá Ingress porque el enrutamiento compartido, los certificados y las políticas importan más que la capa adicional del controlador.

Notas Finales

Elige basándote en el protocolo y las operaciones, no en qué objeto suena más avanzado. NodePort es un bloque de construcción. LoadBalancer es acceso L4 externo directo. Ingress es enrutamiento HTTP/S a través de un controlador. En un clúster pequeño, los tres pueden aparecer en el mismo diseño, y eso está bien siempre que cada uno tenga un trabajo claro.