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,
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.
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:
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:
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).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:
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.
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:
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.
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:
hostname) , rutas o headers.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.
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
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.
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
En ciberseguridad no se compite, se colabora. La propuesta de Vulnerable.cl —hecha en Chile y liberada para la comunidad— va en esa línea: una herramienta gratuita que respeta la privacidad de tu configuración y te entrega una revisión rápida de hardening.
El gobierno chileno finalmente oficializó lo que el sector privado venía anticipando con inquietud: la entrada en vigencia de la Ley 21.719, sobre protección y tratamiento de datos personales, se posterga por un año.
