1. Relación entre Ingress, IngressClass y el Controlador

Para comprender la gestión del tráfico externo, es útil diferenciar tres componentes fundamentales que trabajan en conjunto:

• IngressClass: Define la implementación específica del motor de enrutamiento (por ejemplo, Traefik, NGINX o Envoy). Actúa como el ejecutor de las políticas.
• Ingress: Es un recurso estándar de la API de Kubernetes que declara las reglas de tráfico HTTP/HTTPS. Por sí solo no mueve paquetes; solo especifica las directrices.
• Especificación del Controlador: A través del campo spec.ingressClassName, se asocia una regla Ingress con una impleemntación concreta, garantizando que el componente correcto aplique la configuración.

Flujo de Operación Típico:

1. Implementación del controlador en el clúster.

2. Registro de la clase correspondiente.

3. Despliegue de recursos Ingress vinculados a dicha clase.

4. El controlador observa los cambios y traduce las reglas declarativas a su configuración interna.

5. El tráfico externo ingresa y se distribuye hacia los servicios internos según las directrices.

6. Limitaciones del Acceso Directo vs. Ventajas de la Orquestación Nativa

Exponer servicios sin una capa de abstracción de entrada genera varios cuellos de botella operativos:

• Gestión de puertos fragmentada: El uso de NodePort consume rangos altos (30000-32767) por cada despliegue, aumentando la superficie de ataque y la complejidad de mantenimiento.
• Ausencia de enrutamiento semántico: Sin capacidad para distinguir tráfico por dominio o ruta URI, cada aplicación requiere un endpoint de red aislado.
• Configuración estática y manual: Los servidores proxy tradicionales necesitan archivos escritos a mano y recargas explícitas cada vez que los pods se escalan o se reinician.

Beneficios al adoptar Ingress con Traefik:

• Punto de acceso centralizado: Exposición segura a través de un único balanceador de carga en los puertos 80 y 443.
• Enrutamiento contextual: Capacidades nativas para dividir tráfico basándose en encabezados, cookies, rutas y nombres de host, facilitando despliegues progresivos y pruebas A/B.
• Automatización continua: Detección instantánea de eventos del ciclo de vida de los pods. La configuración del proxy se actualiza dinámicamente sin interrupciones.
• Funcionalidades empresariales integradas: Terminación TLS automática, control de tasa, tableros de monitoreo y soporte para estrategias de liberación avanzadas.

3. Recursos Específicos de Traefik: IngressRoute e IngressRouteTCP

Traefik extiende la API nativa mediante Custom Resource Definitions (CRD) que ofrecen mayor granularidad:

• IngressRoute (Capa 7): Diseñado para tráfico web y APIs REST. Permite definir enrutamiento por ruta, virtual host, terminación TLS y encadenamiento de middlewares (autenticación, reescritura de cabeceras, límites de velocidad).
• IngressRouteTCP (Capa 4): Orientado a protocolos genéricos como base de datos, mensajería o servidores remotos. Omite las características de la aplicación web y se centra exclusivamente en el reenvío de puertos y enrutamiento basado en SNI.

4. Arquitectura de Balanceo: División de Responsabilidades

En Kubernetes, la carga de trabajo se separa naturalmente entre dos niveles:

• Nivel de Aplicación (Ingress): Interpreta el contenido de la solicitud. Decide hacia qué Service dirigir el paquete basándose en metadatos HTTP.
• Nivel de Transporte (Service): Ignora el contenido de la aplicación. Utiliza algoritmos de balanceo (como round-robin) para distribuir paquetes IP/TCP hacia los contenedores activos.

Ejemplo de recorrido de paquete:

Solicitud HTTPS: api.empresa.corp/v2/datos
↓
1. Controlador Ingress (Capa 7)
   - Analiza Host y Path
   - Deriva a svc-backend:80
↓
2. Servicio de Kubernetes (Capa 4)
   - Selecciona pod activo vía iptables/IPVS
   - Reenvía tráfico al puerto interno del contenedor (ej. 8080)
↓
3. Ejecución en el Pod destino

5. Comparativa: Proxy Estático vs. Enrutamiento Dinámico en Kubernetes

Mientras que las soluciones tradicionales dependen de módulos separados dentro de un único binario (como el bloque stream frente a http), Kubernetes delega estas responsabilidades a componentes especializados que se comunican mediante la API del clúster.

6. Ejemplos de Implementación: Ingress Estándar vs. CRD de Traefik

Configuración Nativa de Kubernetes

Enrutamiento basado en nombre de host:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: portal-reglas-entrada
spec:
  ingressClassName: trafico-web
  rules:
  - host: tienda.online.corp
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-aplicacion-v1
            port:
              number: 80

Enrutamiento segmentado por URI:

spec:
  rules:
  - host: panel.interno.corp
    http:
      paths:
      - path: /gestion
        pathType: Prefix
        backend:
          service:
            name: svc-modulo-admin
            port:
              number: 80
      - path: /reportes
        pathType: Prefix
        backend:
          service:
            name: svc-modulo-analytics
            port:
              number: 80

Recursos Personalizados de Traefik (IngressRoute)

Ruta HTTP con punto de entrada explícito:

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: regla-traefik-web
  namespace: infra-red
spec:
  entryPoints:
    - puerto-http
  routes:
    - match: Host(`observatorio.interno.corp`) && PathPrefix(`/metricas`)
      kind: Rule
      services:
        - name: svc-metricas-colector
          port:
            number: 9090

Ruta HTTPS con terminación de certificado:

spec:
  tls:
    secretName: cert-tls-produccion
  entryPoints:
    - puerto-https
  routes:
    - match: Host(`datos-seguros.corp`)
      kind: Rule
      services:
        - name: svc-api-core
          port:
            number: 8080

Análisis de Diferencias Clave

Procedimiento de Despliegue Recomendado

1. Preparación del Backend: Asegurar que los pods estén activos y los servicios de clusterIP configurados correctamente.
2. Aplicación de Reglas: Para Ingress nativo, definir la clase de controlador. Para IngressRoute, asignar los entryPoints correspondientes.
3. Verificación de Conectividad: Validar el flujo mediante el balanceador de carga externo.

Consideraciones Operativas Finales:

• Configurar la resolución de nombres en los clientes (archivo hosts o DNS interno) para apuntar al IP externo del balanceador.
• Respetar los límites de namespace; los recursos de enrutamiento y los servicios de destino deben residir en el mismo espacio de nombres o referenciarse correctamente.
• Para protocolos de capa 4, es necesario registrar previamente los puntos de entrada adicionales en la configuración estática del controlador.