La migración de controladores de tráfico en entornos Kubernetes es un proceso que muchas organizaciones deben afrontar cuando las tecnologías base alcanzan su fin de vida útil o simplemente quedan superadas por la evolución del ecosistema cloud nativo. Pasar de un controlador tradicional como Ingress NGINX hacia soluciones basadas en Gateway API no es solo una cuestión de sustituir un componente por otro; implica rediseñar la estrategia de enrutamiento, garantizar la continuidad operativa y alinear la infraestructura con los estándares actuales de la Cloud Native Computing Foundation. En Q2BSTUDIO, donde desarrollamos aplicaciones a medida y plataformas sobre Kubernetes, hemos abordado este desafío desde una perspectiva práctica, combinando técnicas de despliegue gradual con herramientas de observación y automatización.
El primer paso en cualquier transición de este tipo consiste en evaluar qué controlador Gateway API ofrece el equilibrio adecuado entre madurez, soporte de la comunidad y capacidad de integración con el resto del stack. En nuestro caso, tras analizar varias alternativas, seleccionamos Envoy Gateway, un proyecto que no solo cuenta con respaldo de la CNCF, sino que también se distingue por su compatibilidad con requisitos exigentes como mTLS, buffering de peticiones y un modelo de recursos dedicados que evita la proliferación de anotaciones. Esta elección encaja perfectamente con nuestra oferta de servicios cloud AWS y Azure, donde la seguridad y la escalabilidad son prioridades.
Uno de los errores más comunes en estas migraciones es asumir que mover el tráfico de un controlador a otro es suficiente. La verdadera dificultad reside en hacerlo sin que una sola petición se pierda durante el corte. La causa principal de los cortes es el tiempo de propagación del DNS: cuando se elimina un recurso Ingress antes de que los registros DNS hayan expirado según su TTL, los clientes que aún resuelven la dirección antigua se encuentran con un punto muerto. Para resolver esto, implementamos un patrón de registros DNS ponderados, apoyándonos en ExternalDNS y Route 53. La idea es sencilla pero poderosa: en lugar de un corte brusco, se ejecutan ambos controladores simultáneamente, cada uno registrado con el mismo nombre de host pero con pesos distintos. Inicialmente, todo el tráfico se dirige al Ingress antiguo (peso 100), mientras que el nuevo HTTPRoute permanece en peso 0, listo para recibir peticiones pero sin redirigir ninguna. Cuando se verifica que el nuevo controlador está funcionando correctamente, se intercambian los pesos, moviendo el tráfico de forma inmediata y sin interrupciones. Este enfoque, además, permite una reversión instantánea: si algo falla, basta con devolver los pesos originales.
Este método no solo es efectivo para Envoy Gateway, sino que es agnóstico respecto al controlador de Gateway API que se utilice. Durante el proceso de validación, probamos la estrategia en un entorno interno, utilizando una instancia de Goldilocks para monitorizar el comportamiento de las peticiones mediante un script de polling. La experiencia nos reveló que, aunque la migración técnica era viable, la gestión de múltiples namespaces en producción introducía complejidades adicionales. En clientes reales, donde se separan entornos por namespace, la configuración de listeners en el recurso Gateway puede invadir el ámbito de la plataforma, rompiendo la separación de responsabilidades que Gateway API promete. Afortunadamente, versiones recientes del estándar (1.5 y superiores) incorporan el recurso ListenerSet, que permite a los equipos de aplicación definir sus propios listeners sin modificar la puerta de enlace principal. En Q2BSTUDIO ya estamos probando esta característica en fase release candidate, preparándonos para integrarla tan pronto esté estable.
Para las organizaciones que aún dependen de Ingress NGINX, el tiempo corre. La falta de parches de seguridad y la congelación de la API Ingress original hacen que permanecer en esa tecnología sea cada vez más arriesgado. Sin embargo, la urgencia no debe traducirse en una migración apresurada. La diferencia entre un corte que provoca caídas y una transición limpia está en los detalles que la mayoría de las guías omiten: la secuencia correcta de cambios, la monitorización continua y la capacidad de volver atrás sin fricción. En este contexto, contar con un aliado tecnológico que entienda tanto la infraestructura como el negocio marca la diferencia. Nuestro equipo integra ia para empresas y servicios de inteligencia de negocio como Power BI para anticipar patrones de tráfico y optimizar decisiones de enrutamiento, además de desplegar agentes IA que automatizan la gestión de certificados y registros DNS mediante políticas definidas. También aplicamos principios de ciberseguridad para garantizar que cada nuevo componente, desde el controlador hasta los balanceadores, cumpla con las políticas de hardening más exigentes.
La migración de Ingress NGINX a Envoy Gateway no es un fin en sí mismo, sino un paso hacia una arquitectura de red más expresiva, mantenible y preparada para el futuro. Si tu equipo está evaluando este camino o necesita apoyo para diseñar una estrategia que combine software a medida con infraestructura cloud robusta, podemos compartir la experiencia acumulada en proyectos reales. La clave está en no saltarse las fases de prueba, en utilizar ponderación DNS para evitar cortes y en elegir un controlador que se alinee con la dirección del ecosistema Kubernetes. Todo lo demás es simplemente cuestión de ejecutar el plan con la precisión que exige un entorno de producción.
