Gestión de Redes en Kubernetes: Servicios, Ingress y Network Policies 🌐

La gestión de redes es uno de los pilares fundamentales para el funcionamiento efectivo de las aplicaciones en un entorno de Kubernetes. Entender cómo tus pods se comunican entre sí, cómo el tráfico externo llega a tus servicios y cómo puedes asegurar estas comunicaciones es crucial para desplegar aplicaciones robustas y escalables. Este tutorial te guiará a través de los conceptos esenciales de red en Kubernetes: Servicios, Ingress y Network Policies.

🚀 ¿Por qué es Vital la Red en Kubernetes?

Kubernetes está diseñado para ejecutar aplicaciones distribuidas y efímeras. Los pods pueden crearse y destruirse dinámicamente, y sus direcciones IP cambian constantemente. Esto presenta un desafío: ¿cómo se conectan los clientes externos o incluso otros pods internos a una aplicación que no tiene una IP fija? Aquí es donde entra en juego la capa de red de Kubernetes, abstraiendo la complejidad y proporcionando mecanismos estables para la conectividad y el control del tráfico.

Desafíos Comunes de Red en Contenedores

• IPs Efímeras: Los pods nacen y mueren, y con ellos sus IPs.
• Descubrimiento de Servicios: ¿Cómo encuentra un microservicio a otro?
• Exposición al Exterior: ¿Cómo acceden los usuarios a una aplicación que corre dentro del clúster?
• Seguridad: ¿Cómo controlo quién puede hablar con quién dentro del clúster?

🎯 Servicios: Exponiendo tus Aplicaciones Internamente y Externamente

Un Service en Kubernetes es una abstracción que define un conjunto lógico de Pods y una política para acceder a ellos. Es la forma en que los pods se hacen accesibles, tanto para otros pods dentro del clúster como para el mundo exterior. Los Services proporcionan una dirección IP estable y un nombre DNS para acceder a una aplicación, incluso si los pods subyacentes cambian.

Tipos de Servicios

Kubernetes ofrece varios tipos de Services para diferentes casos de uso:

• ClusterIP: El tipo por defecto. Expone el Service en una IP interna del clúster. Solo accesible desde dentro del clúster. Ideal para comunicación entre microservicios.
• NodePort: Expone el Service en cada Node del clúster en un puerto estático. Cualquier petición a <NodeIP>:<NodePort> se redirige al Service. No es ideal para producción debido a los puertos altos y la falta de balanceo de carga avanzado.
• **LoadBalancer: Expone el Service externamente usando el balanceador de carga de la nube (si el clúster corre en una). Proporciona una IP pública dedicada y balanceo de carga. Es el estándar para aplicaciones en la nube.
• ExternalName: Mapea el Service a un CNAME de DNS arbitrario. No hay proxy. Útil para acceder a servicios externos al clúster.

Ejemplo de Service de Tipo ClusterIP

Vamos a crear un Deployment simple y luego exponerlo con un Service de tipo ClusterIP.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-app-web
  labels:
    app: mi-app-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mi-app-web
  template:
    metadata:
      labels:
        app: mi-app-web
    spec:
      containers:
      - name: web
        image: nginx
        ports:
        - containerPort: 80

kubectl apply -f deployment.yaml

Ahora, el Service:

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: mi-app-service
spec:
  selector:
    app: mi-app-web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

kubectl apply -f service.yaml

Después de aplicar, puedes ver el Service:

kubectl get svc mi-app-service

Verás una CLUSTER-IP que otros pods pueden usar para acceder a tu aplicación. También puedes usar el nombre del Service (mi-app-service) como nombre de host dentro del clúster.

✨ Ingress: El Acceso Externo Inteligente a tus Aplicaciones

Mientras que los Services de tipo LoadBalancer o NodePort pueden exponer tus aplicaciones al mundo exterior, Ingress proporciona una forma más flexible y potente de gestionar el acceso HTTP y HTTPS a múltiples servicios. Ingress actúa como un router de capa 7 para el tráfico entrante, permitiendo reglas de enrutamiento basadas en el nombre de host, la ruta URL y otras características de la petición HTTP.

Un Ingress requiere un Ingress Controller para funcionar. Los Ingress Controllers son pods que se ejecutan dentro del clúster (por ejemplo, NGINX Ingress Controller, Traefik, GKE Ingress) y son responsables de cumplir las reglas definidas en los recursos Ingress.

Beneficios de Usar Ingress

• Centralización: Un único punto de entrada para múltiples servicios.
• Enrutamiento flexible: Basado en dominio (host) o ruta (path).
• Terminación SSL/TLS: Maneja certificados SSL para conexiones seguras.
• Balanceo de carga: Distribuido a través de los pods del Service.
• Menos IPs públicas: Un Ingress puede manejar muchos dominios con una sola IP pública.

Componentes de Ingress

1. Ingress: El recurso de Kubernetes que define las reglas de enrutamiento.
2. Ingress Controller: Un pod que monitorea los recursos Ingress y configura un proxy inverso (como NGINX) para aplicar esas reglas.
3. Service: El Service ClusterIP o NodePort al que Ingress redirige el tráfico.

Ejemplo de Ingress

Supongamos que tenemos dos aplicaciones, mi-app-web (Nginx) y mi-app-api (por ejemplo, un backend Node.js), cada una expuesta por un Service ClusterIP. Queremos acceder a web.ejemplo.com para la web y api.ejemplo.com para la API.

Primero, los Services (asumiendo que los Deployments ya existen):

# service-web.yaml
apiVersion: v1
kind: Service
metadata:
  name: mi-app-web-service
spec:
  selector:
    app: mi-app-web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

# service-api.yaml
apiVersion: v1
kind: Service
metadata:
  name: mi-app-api-service
spec:
  selector:
    app: mi-app-api
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 3000 # Puerto del contenedor de la API
  type: ClusterIP

Ahora, el Ingress:

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mi-aplicacion-ingress
  annotations:
    # Estas anotaciones pueden variar según el Ingress Controller
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx # Asegúrate de tener un Ingress Controller NGINX instalado
  rules:
  - host: web.ejemplo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mi-app-web-service
            port:
              number: 80
  - host: api.ejemplo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mi-app-api-service
            port:
              number: 8080

kubectl apply -f service-web.yaml -f service-api.yaml -f ingress.yaml

Ahora, cuando accedas a web.ejemplo.com (asumiendo que tu DNS apunta a la IP pública del Ingress Controller), se te redirigirá a mi-app-web-service. Si accedes a api.ejemplo.com, se te redirigirá a mi-app-api-service.

# Ingress con TLS
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mi-aplicacion-ingress-tls
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - web.ejemplo.com
    - api.ejemplo.com
    secretName: tls-secret-ejemplo # Este secret debe contener tus certificados TLS
  rules:
  - host: web.ejemplo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mi-app-web-service
            port:
              number: 80
  - host: api.ejemplo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mi-app-api-service
            port:
              number: 8080

🔒 Network Policies: Asegurando la Comunicación Interna

Por defecto, todos los pods en Kubernetes pueden comunicarse entre sí. Esto es genial para la flexibilidad, pero terrible para la seguridad en entornos de producción. Las Network Policies te permiten especificar cómo los grupos de pods están autorizados a comunicarse entre sí y con otros puntos de la red. Son como firewalls a nivel de pod.

Conceptos Clave de Network Policies

• Pod Selector: Define a qué pods se aplica la política.
• Ingress Rules: Permiten especificar de dónde se permite el tráfico entrante a los pods seleccionados.
• Egress Rules: Permiten especificar a dónde se permite el tráfico saliente desde los pods seleccionados.
• Namespace Selector: Para especificar namespaces de origen/destino.
• IP Block: Para especificar rangos de IP CIDR.

Funcionamiento por Defecto

• Si no hay Network Policies en un Namespace, todo el tráfico entrante y saliente está permitido.
• Si al menos una Network Policy selecciona un pod, ese pod es aislado. Esto significa que todo el tráfico que no está explícitamente permitido por una política será denegado.
• Las políticas son aditivas: si un pod es seleccionado por múltiples políticas, se aplican todas las reglas de permiso combinadas.

Ejemplo: Aislando un Backend

Imagina que tienes una aplicación web (app: frontend) y una API de backend (app: backend). Quieres que el frontend pueda hablar con el backend, pero nadie más (ni siquiera otros pods en el mismo namespace) pueda acceder al backend. También quieres que el backend solo pueda salir a una base de datos específica (por ejemplo, en otro namespace).

# network-policy-backend.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default # O el namespace donde estén tus pods
spec:
  podSelector:
    matchLabels:
      app: backend # Esta política aplica a los pods con label app: backend
  policyTypes:
    - Ingress # Esta política define reglas de entrada
    - Egress # Y también define reglas de salida
  ingress:
    # Permitir tráfico entrante desde pods con app: frontend
    - from:
      - podSelector:
          matchLabels:
            app: frontend
      ports:
        - protocol: TCP
          port: 8080 # Puerto en el que escucha el backend
  egress:
    # Permitir tráfico saliente solo hacia pods con app: database en el namespace 'data'
    - to:
      - namespaceSelector:
          matchLabels:
            name: data # Selecciona el namespace 'data'
        podSelector:
          matchLabels:
            app: database
      ports:
        - protocol: TCP
          port: 5432 # Puerto de la base de datos

kubectl apply -f network-policy-backend.yaml

Con esta política:

• Los pods app: backend solo aceptarán conexiones TCP en el puerto 8080 desde pods con app: frontend.
• Cualquier otro tráfico entrante a app: backend será bloqueado.
• Los pods app: backend solo podrán iniciar conexiones TCP en el puerto 5432 hacia pods con app: database en el namespace data.
• Cualquier otro tráfico saliente de app: backend será bloqueado.

Tabla Comparativa: Opciones de Control de Red

📈 Buenas Prácticas y Consideraciones Avanzadas

• Seguridad por Defecto: Implementa Network Policies desde el principio, adoptando un enfoque de mínimo privilegio. Bloquea todo el tráfico por defecto y solo permite lo esencial.
• Nombres de Servicios: Usa los nombres de los Services como nombres de host DNS para la comunicación entre pods. Esto es más fiable que depender de IPs de Service.
• Probes de Salud: Asegúrate de configurar liveness y readiness probes en tus Deployments para que los Services solo redirijan tráfico a pods saludables.
• IngressClassName: Siempre especifica ingressClassName en tus recursos Ingress para claridad y compatibilidad con múltiples controladores.
• Herramientas de Observabilidad: Monitoriza el tráfico de red con herramientas como Prometheus y Grafana. Los Ingress Controllers y los CNI a menudo exponen métricas útiles.
• Helm Charts: Para implementaciones complejas, usa Helm Charts que incluyan la configuración de Services, Deployments e Ingress de forma conjunta.

Resolución de Nombres (DNS) en Kubernetes

Kubernetes tiene su propio DNS interno (CoreDNS) que permite a los pods resolver los nombres de los Services y otros recursos del clúster. Por ejemplo, un pod en el default namespace puede acceder a mi-app-service simplemente usando ese nombre. Si el Service está en otro namespace, se usa el formato nombre-del-service.nombre-del-namespace.svc.cluster.local.

La Ruta del Tráfico: Un Resumen Visual

Imagina un request HTTP desde un navegador web a tu aplicación en Kubernetes:

✅ Conclusión

La gestión de redes en Kubernetes es un tema amplio pero fundamental. Al dominar los Services, Ingress y Network Policies, obtendrás el control completo sobre cómo tus aplicaciones se comunican y cómo son accesibles. Esta combinación te permite construir arquitecturas robustas, seguras y altamente disponibles, aprovechando al máximo las capacidades de orquestación de contenedores de Kubernetes.

Practica con ejemplos, experimenta con diferentes tipos de Services e Ingress, y sobre todo, sé meticuloso con tus Network Policies para asegurar que tus aplicaciones no solo sean accesibles, sino también estén bien protegidas.