Kubernetes Cloud Development DevOps Microservicios Español

Ingress, Gateway, Load Balancer, ClusterIP, NodePort... Qué carajo son? Cuál debo usar en mi app? Introducción en simple

Nicolás Georger

Aug 12, 2024

Ingress, Gateway, Load Balancer, ClusterIP, NodePort... Qué carajo son? Cuál debo usar en mi app? Introducción en simple

TL;DR (Too long; Didn't Read)

Las redes en Kubernetes pueden ser tan confusas como... bueno, como el propio Kubernetes. ¿Estás hasta las ~~pelotas u ovarios~~ de que los problemas de Kubernetes te distraigan de tu código? Aquí te ofrecemos una guía sencilla sobre los Servicios de Kubernetes, centrándonos en los protagonistas: Ingress, Gateway, Load Balancer, ClusterIP y NodePort. Desvelaremos sus propósitos, fortalezas y cuándo desplegar cada uno.

Eliminando mitos de los Servicios de Kubernetes

El escenario típico: has containerizado tu aplicación utilizando Docker, dividiéndola en microservicios repartidos por un clúster de Kubernetes. Pero, ¿cómo se comunican estos microservicios? ¿Cómo llega el tráfico externo a ellos?

Aquí entran los Servicios de Kubernetes, los héroes olvidados del mundo de las redes de Kubernetes. Actúan como balanceadores de carga internos y proporcionan un endpoint estable para acceder a tus pods (esos contenedores que ejecutan tu aplicación). Imagínatelos como los amables directores de tráfico que garantizan una comunicación fluida entre los componentes de tu aplicación.

Kubernetes ofrece varios tipos de Servicios, cada uno de los cuales satisface necesidades específicas:

ClusterIP: La "sala privada" de tu aplicación

El tipo más básico es el servicio ClusterIP. Proporciona una única dirección IP estable dentro de tu clúster, accesible sólo para otras aplicaciones que se ejecuten dentro del mismo clúster. Es como tener una fiesta privada en tu casa a la que sólo pueden asistir los que tienen invitación (otros pods del clúster).

Utiliza ClusterIP cuando:

Necesitas comunicación interna entre los pods dentro de tu clúster.
No necesitas acceso externo al servicio.

Aquí tienes un ejemplo sencillo:

apiVersion: v1
kind: Service
metadata:
  name: my-internal-app
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

En este ejemplo:

type: ClusterIP define explícitamente el tipo de servicio como ClusterIP.
selector: app: my-app le dice al servicio que seleccione los pods con la etiqueta app: my-app.
ports: define las asignaciones de puertos entre el servicio (puerto 80) y los pods (targetPort 8080).

NodePort: Abriendo un hoyo en el firewall

El siguiente es NodePort, que expone tu servicio en un puerto estático en cada nodo de tu clúster. Es como abrir una puerta designada en la fiesta de tu casa y dejar entrar a cualquiera que sepa el número de la puerta (el NodePort), tanto si está en la lista de invitados como si no.

NodePort es útil para:

Exponer tu aplicación para acceso externo durante el desarrollo o la depuración.
Exponer un servicio en un puerto específico en todos los nodos, independientemente de la dirección IP del pod subyacente.

Así es como se define un servicio NodePort:

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 30080

La diferencia clave aquí es nodePort: 30080. Esta línea expone el servicio en el puerto 30080 en cada nodo de tu clúster.

LoadBalancer: El controlador de tráfico externo

Mientras que NodePort abre una puerta, LoadBalancer despliega la alfombra roja, proporcionando una dirección IP externa dedicada que enruta el tráfico a tu servicio. Es como contratar a un portero profesional (a menudo proporcionado por tu proveedor de cloud) que gestiona de forma experta la lista de invitados y garantiza una entrada fluida a tu fiesta.

Un servicio LoadBalancer es idóneo cuando quieres:

Exponer tu aplicación al mundo exterior en un entorno de producción.
Distribuir el tráfico entre múltiples pods para una alta disponibilidad y escalabilidad.

Aquí tienes un ejemplo:

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

Cuando creas un servicio LoadBalancer, Kubernetes (con la ayuda de tu proveedor de cloud) aprovisiona un balanceador de carga y le asigna una dirección IP externa, haciendo que tu aplicación sea accesible públicamente.

Ingress: El enrutador de tráfico "inteligente"

Piensa en los LoadBalancers como proveedores de un único punto de entrada a tu aplicación. Pero, ¿qué ocurre si quieres un control más preciso del tráfico entrante, como enrutar las peticiones a diferentes servicios en función de la URL solicitada?

Aquí es donde entra Ingress, el sofisticado controlador de tráfico que actúa como un proxy inverso, dirigiendo el tráfico a diferentes servicios según las reglas que definas. Imagina Ingress como el organizador de la fiesta que recibe a los invitados en la puerta y los guía a diferentes salas (servicios) en función de sus intereses (URL de la solicitud).

Ingress brilla cuando:

Necesitas enrutar el tráfico en función de atributos HTTP/HTTPS como nombres de host (hostname) , rutas o headers.
Quieres consolidar múltiples servicios bajo un único punto de entrada (como un único nombre de dominio).

Aquí tienes una configuración básica de Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service-1
            port:
              number: 80
      - path: /admin
        pathType: Prefix
        backend:
          service:
            name: my-service-2
            port:
              number: 8080

Esta configuración enruta las solicitudes a myapp.example.com/ a my-service-1 y las solicitudes a myapp.example.com/admin a my-service-2.

Gateway API: El futuro de las redes de Kubernetes

Aunque Ingress ha sido la solución preferida para el enrutamiento del tráfico HTTP, tiene sus limitaciones. Aquí es donde entra API Gateway, una forma más potente, expresiva y extensible de gestionar las redes de Kubernetes. Piensa en la API Gateway como la evolución del planificador de fiestas, ahora equipado con habilidades y herramientas avanzadas para gestionar incluso los eventos más complejos.

Aquí tienes un ejemplo simplificado:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: istio 
  listeners:
  - protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "myapp.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-service-1
      port: 80

La API Gateway proporciona una forma más estructurada y flexible de definir puertas de enlace, listeners y rutas, lo que facilita la gestión de escenarios de red complejos.

Elegir el tipo de servicio adecuado

Comunicación interna: ClusterIP es tu opción preferida.
Acceso externo durante el desarrollo: NodePort ofrece una solución sencilla.
Acceso externo listo para producción con balanceo de carga: LoadBalancer es tu mejor opción.
Enrutamiento de tráfico basado en atributos HTTP/HTTPS: Ingress es la respuesta.
Gestión avanzada del tráfico y extensibilidad: Adopta la potencia de la API Gateway.

Recuerda que comprender los Servicios de Kubernetes es clave para desbloquear todo el potencial de tus aplicaciones en contenedores. Elige sabiamente, y tus microservicios estarán comunicándose como esperas.

Un paso adelante: Service Mesh

Para una gestión avanzada de las redes y el tráfico, considera la posibilidad de explorar las mallas de servicios (service mesh) como Istio, Linkerd, Traefik Mesh, Kong o Kuma. Estas herramientas proporcionan funciones adicionales como el cifrado del tráfico, la observabilidad y un control preciso del tráfico, lo que lleva tu juego de redes de Kubernetes al siguiente nivel.