Traefik Proxy 3.7 simplifica la migración desde Ingress NGINX en Kubernetes

Published:

Traefik Labs lanzó oficialmente Traefik Proxy, una versión clave para administradores Kubernetes y equipos DevOps que todavía dependen de Ingress NGINX. La novedad más importante es que el soporte para migración desde Ingress NGINX ahora es considerado production-ready, permitiendo reutilizar gran parte de los manifiestos existentes sin necesidad de reescribir configuraciones complejas.

Esta actualización llega en un contexto importante: el proyecto Ingress NGINX anunció oficialmente su retiro en marzo de 2026, lo que significa que ya no recibirá nuevas versiones, correcciones ni parches de seguridad.


¿Por qué Traefik 3.7 es relevante ahora?

Durante años, muchos clusters Kubernetes utilizaron Ingress NGINX como controlador principal debido a su flexibilidad y enorme ecosistema. El problema es que el proyecto entró oficialmente en EOL (End of Life) en marzo de 2026.

Eso implica varios riesgos:

  • Sin actualizaciones de seguridad
  • Sin compatibilidad futura garantizada con Kubernetes
  • Riesgo creciente ante vulnerabilidades críticas
  • Mayor deuda técnica operativa

Traefik apunta directamente a cubrir ese vacío ofreciendo una migración con impacto mínimo.


Compatibilidad con más de 85 anotaciones de Ingress NGINX

La característica principal de esta versión es el nuevo proveedor Kubernetes Ingress NGINX, que soporta más de 85 anotaciones ampliamente utilizadas. Según Traefik Labs, esto cubre más del 90% de los escenarios reales encontrados en producción.

Entre las anotaciones soportadas se incluyen:

Funcionalidad

Compatibilidad

Redirects HTTP/HTTPS

Session Affinity

Rate Limiting

Canary Deployments

Authentication

Custom Headers

Access Control

Load Balancing

Error Pages

Observabilidad

Esto permite reutilizar recursos existentes como:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-demo
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx

Sin necesidad de convertir inmediatamente las anotaciones hacia sintaxis específica de Traefik.


Soporte parcial para snippets NGINX

Uno de los puntos más delicados en cualquier migración desde ingress-nginx siempre fueron los snippets personalizados:

  • configuration-snippet
  • server-snippet
  • auth-snippet

Traefik 3.7 ahora ofrece soporte parcial para estos casos. Sin embargo, hay una diferencia importante:

Traefik NO ejecuta configuración NGINX arbitraria

En lugar de inyectar directamente snippets personalizados, Traefik:

  1. Analiza el contenido
  2. Traduce directivas compatibles
  3. Bloquea configuraciones inseguras o no soportadas

Esto reduce significativamente riesgos de seguridad derivados de configuraciones arbitrarias.


Nueva visibilidad de certificados TLS

Otra mejora importante es la incorporación de una nueva sección de certificados TLS dentro del dashboard.

Ahora es posible visualizar:

  • Certificados activos
  • Dominios asociados
  • Fecha de expiración
  • Routers HTTP/TCP relacionados

Esto simplifica bastante el troubleshooting en entornos con múltiples certificados y automatización ACME/Let’s Encrypt.


Middlewares ahora pueden asociarse a servicios

Hasta ahora, los middlewares en Traefik solo podían aplicarse a routers o entrypoints.

En Traefik 3.7 también pueden asociarse directamente a servicios backend.

Ejemplo práctico:

  • Aplicar autenticación única
  • Rate limiting centralizado
  • Headers comunes
  • Retry policies

Sin duplicar configuración en múltiples routers.

Esto mejora considerablemente la reutilización y mantenibilidad en arquitecturas grandes.


Migración gradual y sin downtime

Uno de los aspectos más interesantes es que Traefik propone una migración progresiva.

El flujo recomendado es:

DNS
├── Ingress NGINX
└── Traefik

Posteriormente:

  1. Instalar Traefik en paralelo
  2. Compartir tráfico gradualmente
  3. Validar comportamiento
  4. Migrar DNS/load balancer
  5. Retirar ingress-nginx

Esto evita migraciones “big bang” y reduce muchísimo el riesgo operativo.


Gateway API gana protagonismo

Traefik también actualizó soporte para Gateway API 1.5.1, alineándose con la dirección oficial del ecosistema Kubernetes.

Cada vez más organizaciones están migrando desde objetos Ingress tradicionales hacia:

  • GatewayClass
  • Gateway
  • HTTPRoute

Lo cual permite:

  • Mejor segmentación RBAC
  • Routing más flexible
  • Canary nativo
  • Multi-tenancy más limpio
  • Menos dependencia de anotaciones propietarias

Consideraciones reales antes de migrar

Aunque Traefik 3.7 mejora enormemente la compatibilidad, existen algunos puntos a revisar:

Área

Validación recomendada

Snippets personalizados

Revisar compatibilidad

ModSecurity/WAF

Evaluar alternativas

Custom Lua/NGINX directives

Reescribir

Cert-manager

Validar integración

IngressClass

Planificar coexistencia

Canary avanzado

Probar comportamiento

Algunas experiencias de la comunidad muestran que las migraciones simples funcionan muy bien, pero clusters con cientos de anotaciones customizadas pueden requerir trabajo adicional.


Conclusión

Traefik Proxy 3.7 probablemente sea una de las releases más importantes del proyecto en los últimos años. La retirada oficial de ingress-nginx obliga a muchas organizaciones a definir una estrategia de migración, y Traefik claramente quiere posicionarse como el reemplazo más directo posible.

La compatibilidad con anotaciones NGINX, el soporte progresivo para snippets y la capacidad de migrar sin downtime reducen considerablemente la complejidad operativa.

Para equipos DevOps, SRE y plataformas Kubernetes empresariales, este es un buen momento para:

  • Auditar anotaciones actuales
  • Identificar dependencias específicas de NGINX
  • Evaluar Gateway API
  • Probar Traefik en paralelo antes de un cutover definitivo

Fuentes oficiales

- Advertisement -
Jorge
Jorgehttps://nksistemas.com
Soy Jorge, Sr Sysadmin Linux/DevOps/SRE y creador de NKSistemas.com Trabajo con plataformas: Linux, Windows, AWS, GCP, VMware, Helm, kubernetes, Docker, etc.

Related articles