Saltar a contenido

Gateway API, Ingress Controllers, Enrutamiento y TLS

Usando Gateway API para el Tráfico Ingress

¿Qué es Gateway API?

Es un conjunto de recursos (CRDs - Custom Resource Definitions) oficiales de Kubernetes que proporcionan una forma estandarizada, avanzada y extensible de modelar el enrutamiento de redes (Capa 4 y Capa 7) hacia tus clústeres.

Viene a ser la "evolución" de Ingress y de los Services de tipo LoadBalancer.

Los 3 Componentes Principales (El Modelo de Recursos)

A diferencia de Ingress (que era un solo objeto monolítico), Gateway API divide la configuración en tres piezas fundamentales:

  • GatewayClass: Define el "tipo" de balanceador o controlador subyacente que vas a usar (ej. NGINX, Traefik, Istio, AWS ALB, GCP LoadBalancer). Es equivalente al IngressClass.
  • Gateway: Es la instancia física (o en la nube) que escucha el tráfico. Aquí defines los puertos (ej. 80, 443) y el protocolo. Es la puerta de entrada real.
  • HTTPRoute (y otros como TCPRoute, TLSRoute): Son las reglas de enrutamiento. Aquí decides que si el tráfico va a mi-app.com/api, debe enviarse al Service de tu backend.

El Superpoder: Diseño Orientado a Roles (Separación de Responsabilidades)

El mayor beneficio de Gateway API es que está diseñado para cómo trabajan las empresas reales:

  • 🛡️ El Administrador de Infraestructura / Operaciones: Crea el GatewayClass y el Gateway. Ellos se preocupan de las IPs públicas, los certificados TLS generales, los puertos y la seguridad perimetral.
  • 💻 Los Desarrolladores (Devs): Solo crean los HTTPRoute dentro de sus propios Namespaces. Ellos deciden cómo enrutar sus APIs, cómo hacer canary deployments (ej. enviar el 10% del tráfico a una versión nueva) o cómo manejar cabeceras HTTP, sin pedirle permiso ni romper la configuración de Infraestructura.

Resumen de Batalla (Tabla Mental)

Característica Service LoadBalancer Ingress Tradicional Gateway API
Capa OSI Capa 4 (TCP / UDP) Capa 7 (HTTP / HTTPS) "Capa 4 y Capa 7 (HTTP, gRPC, TCP, etc.)"
Costo en la Nube Alto (Crea 1 LB en la nube por cada Servicio) Optimizado (Múltiples rutas comparten 1 LB) Optimizado (Múltiples rutas comparten 1 LB)
Capacidades de Enrutamiento Nulas (Solo mapeo directo IP:Puerto) Básicas (Basado en host/path. Resto vía anotaciones) "Avanzadas (Split de tráfico 90/10, match de headers nativos
Enfoque de Equipo Monolítico (1 objeto) Monolítico (1 objeto para todo) Orientado a Roles (Infra vs. Devs separados)

Configuración de TLS

Paso 1: Crear el Secret con el Certificado TLS

Antes de configurar el tráfico protegido, las llaves del certificado SSL/TLS deben existir de forma segura dentro del clúster. En un entorno de producción o examen, puedes crear rápidamente un objeto de tipo Secret de forma imperativa con kubectl:

kubectl create secret tls mi-tls-secret \
  --cert=camino/al/certificado.crt \
  --key=camino/a/la/llave.key \
  -n nombre-namespace

Paso 2: Configurar el Recurso Gateway con TLS

El recurso Gateway es el punto donde ocurre la magia de la terminación TLS. Aquí es donde el Administrador de Infraestructura define un listener en el puerto 443, especifica el protocolo HTTPS y apunta al Secret creado en el paso anterior.

Crea un manifiesto llamado gateway.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mi-gateway
  namespace: nombre-namespace
spec:
  gatewayClassName: mi-gateway-class # Define el controlador subyacente (ej. NGINX, Istio, Cilium)
  listeners:
  - name: https-listener
    protocol: HTTPS
    port: 443
    hostname: "miapp.com"
    tls:
      mode: Terminate # El Gateway descifra el tráfico aquí antes de enviarlo a los Pods
      certificateRefs:
      - kind: Secret
        name: mi-tls-secret
        namespace: nombre-namespace # Opcional si está en el mismo namespace
    allowedRoutes:
      namespaces:
        from: Same # Define desde qué namespaces se permiten enlazar rutas (HTTPRoute)

Conceptos clave en este YAML:

  • mode: Terminate: Indica que el balanceador de carga o proxy recibirá el tráfico cifrado de internet, lo descifrará (terminación TLS) y enviará el tráfico internamente en texto plano hacia los backends.

  • certificateRefs: Es un arreglo de referencias. Al estar basado en la Gateway API, permite apuntar a un Secret nativo u otro recurso personalizado de certificados de forma flexible.

  • allowedRoutes: Controla la seguridad organizativa. Puedes permitir que desarrolladores de otros namespaces expongan sus aplicaciones a través de este certificado seguro (from: All o mediante selectores de etiquetas).

Paso 3: Configurar la Ruta de Aplicación (HTTPRoute)

¡Aquí viene la gran ventaja para los desarrolladores! Dado que el Gateway ya se encarga del cifrado en el puerto 443, el manifiesto de enrutamiento no necesita conocer ninguna configuración criptográfica ni nombres de secretos.

Crea un archivo llamado http-route.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: nombre-namespace
spec:
  parentRefs:
  - name: mi-gateway # Nos "enganchamos" al Gateway seguro creado en el Paso 2
    sectionName: https-listener # Opcional: apunta específicamente al listener HTTPS
  hostnames:
  - "miapp.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: mi-servicio-backend
      port: 80 # Puerto del Service interno de tu aplicación