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: ClusterIPdefine explícitamente el tipo de servicio como ClusterIP.selector: app: my-apple dice al servicio que seleccione los pods con la etiquetaapp: 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 oheaders. - 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.
Nicolás Georger
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.
Nicolás Georger
Comment using your social account:
You will be asked to grant read-only access to your public profile and email address only to verify your identity. We will never post to your account. Select your preferred social account to get started.
|Service provided by Spectral Web Services.