Guía de migración: por qué, cómo y qué esperar
1. Por qué migrar: el fin de NGINX Ingress
El controlador Ingress NGINX de la comunidad entra en fase de mantenimiento de "mejor esfuerzo" hasta su retiro oficial en marzo de 2026. A partir de esa fecha, no habrá más correcciones de errores ni parches de seguridad. Cualquier CVE descubierto quedará sin respuesta.
Esto convierte la migración en una prioridad de cumplimiento y seguridad, no solo una actualización técnica opcional. Postergarla es acumular deuda técnica insostenible: un sistema de enrutamiento expuesto, sin soporte, corriendo tráfico de producción.
La migración a Gateway API no es un cambio de versión. Es una re-arquitectura del manejo de tráfico en Kubernetes.
2. El cambio de paradigma: del monolito al modelo desacoplado
El modelo Ingress combinaba en un solo objeto todo lo relacionado con el enrutamiento: aprovisionamiento de infraestructura, configuración de red y reglas de aplicación. Funcionaba, pero con fricciones importantes.
El problema con Ingress
• Dependía de anotaciones propietarias y específicas de cada proveedor para funciones avanzadas (canary, reescrituras, cabeceras). Eso generaba vendor lock-in: si cambiabas de controlador, reescribías todo.
• Al vivir en un solo objeto, un error en una ruta podía desestabilizar el controlador completo. El radio de impacto era global.
• Estaba limitado a HTTP/HTTPS. No había soporte nativo para TCP, UDP, gRPC ni TLS terminado en capa 4.
Lo que trae Gateway API
Gateway API separa las responsabilidades en tres capas bien definidas:
• GatewayClass: define el proveedor de infraestructura (quién opera el controlador).
• Gateway: gestionado por el equipo de plataforma o clúster. Aquí viven las políticas globales de TLS, WAF y seguridad.
• Routes (HTTPRoute, TCPRoute, etc.): gestionadas por los equipos de aplicación. Cada equipo controla sus propias rutas sin tocar la configuración global.
Este desacoplamiento tiene consecuencias concretas:
• Un desarrollador ya no puede sobreescribir accidentalmente la configuración de TLS del clúster.
• Un error de sintaxis en el namespace de un equipo no afecta las rutas de otros.
• Las funciones avanzadas —división de tráfico, modificación de cabeceras, enrutamiento por peso— son campos de primera clase en la especificación, no anotaciones ad hoc.
• Soporte nativo de protocolos L4 y L7: HTTP, HTTPS, TCP, UDP, TLS, gRPC.
La portabilidad es otra ganancia directa: al basarse en un estándar de SIG-Network, cambiar de controlador o de proveedor de nube ya no implica reescribir todos los manifiestos.
3.Cómo se hace: proceso de migración
La recomendación es clara: evitar el enfoque "Big-Bang". Una migración progresiva y en paralelo reduce el riesgo a niveles manejables.
El Step by Step
1. Auditoría: Inventariar todas las dependencias del Ingress actual. Identificar anotaciones personalizadas o "exóticas", configuración de DNS, certificados TLS y casos de uso especiales. No todas las anotaciones tienen equivalentes directos en Gateway API; es mejor descubrirlo antes que después.
2. Conversión asistida: Usar la herramienta ingress2gateway, que toma manifiestos de Ingress NGINX y genera recursos de Gateway API equivalentes. El output requiere revisión y ajustes manuales; es un punto de partida, no un resultado final.
3. Despliegue en paralelo ("Double Run"): Instalar el nuevo controlador de Gateway API junto al controlador NGINX existente. Crear los objetos Gateway y HTTPRoute sin dirigir tráfico real todavía. Validar configuración en un entorno de staging.
4. Cambio progresivo vía DNS: Redirigir pequeños porcentajes de tráfico al nuevo stack (comenzar con 1-5%) y monitorear métricas de latencia (p99) y tasas de error 5xx antes de continuar. Escalar gradualmente hasta el 100%.
5. Validación y limpieza: Una vez que el 100% del tráfico corre estable sobre Gateway API, eliminar los recursos Ingress y desinstalar el controlador antiguo. Esto reduce la superficie de ataque y elimina la deuda técnica.
Puntos críticos de la configuración
Dos mecanismos de Gateway API merecen atención especial durante la migración:
• permite de forma explícita que un Gateway en un namespace de infraestructura envíe tráfico a un servicio en un namespace de aplicación. Sin este recurso, el enrutamiento entre namespaces está bloqueado por defecto. Es seguridad por diseño.ReferenceGrant:
• los objetos de Gateway API reportan su estado mediante condiciones (Accepted, Programmed, ResolvedRefs). Esto permite diagnosticar problemas directamente sobre el recurso, sin necesidad de revisar logs del controlador.Status Conditions:
4. Comportamiento esperado tras la migración
Una vez completada la migración, la infraestructura opera de forma cualitativamente distinta:
Gobernanza y seguridad granular
Los equipos de infraestructura definen y protegen las políticas globales en el objeto Gateway. Los equipos de desarrollo gestionan sus HTTPRoutes de forma autónoma. El RBAC de Kubernetes hace cumplir esta separación de forma nativa, sin parches ni convenciones informales.
Reducción del blast radius
Una configuración errónea en el namespace de un equipo afecta únicamente sus propias rutas. El controlador no entra en estado inestable; simplemente reporta el error en el campo de status del objeto afectado.
**
Convergencia con Service Mesh (iniciativa GAMMA)
La iniciativa GAMMA del proyecto Gateway API permite usar la misma sintaxis para gestionar tanto el tráfico de entrada Norte-Sur como el tráfico interno Este-Oeste entre servicios. Esto simplifica la pila tecnológica y elimina la necesidad de herramientas separadas para cada tipo de tráfico.
Integración de WAF y seguridad centralizada
Implementaciones como NGINX App Protect o las políticas de seguridad de Envoy Gateway permiten centralizar la protección contra amenazas (OWASP Top 10) directamente en el punto de entrada, gestionado por el objeto Gateway y sin necesidad de configuración por cada servicio.
5. Consideraciones y puntos de atención
Gateway API resuelve problemas reales de Ingress, pero su mayor granularidad introduce complejidades propias que conviene tener presentes.
Carga cognitiva
Donde antes existía un solo objeto Ingress, ahora hay tres capas (GatewayClass, Gateway, Routes) que deben estar correctamente interconectadas. La curva de aprendizaje es real. Equipos sin experiencia previa con el modelo necesitan tiempo de adopción y documentación interna clara.
Escalabilidad del plano de control
En clústeres grandes con miles de rutas, la traducción de objetos Kubernetes a configuración de plano de datos (por ejemplo, protocolo xDS de Envoy) puede ser computacionalmente costosa. Esto puede generar picos de CPU y latencia en la propagación de actualizaciones durante períodos de alta dinámica de cambios.
Anotaciones sin equivalente directo
No todas las anotaciones avanzadas de NGINX Ingress tienen un campo equivalente en la especificación actual de Gateway API. Algunos casos de uso requieren rediseño, no conversión. La herramienta ingress2gateway ayuda, pero no cubre el 100% de los escenarios.
Fragilidad bajo carga dinámica
Algunas implementaciones han mostrado comportamientos inestables ante un flujo muy alto de cambios de rutas o picos de conexiones. En modelos de proxy compartido, un namespace con tráfico excesivo puede afectar la disponibilidad de recursos para otros. El monitoreo continuo durante y después de la migración no es opcional.
Cómo la comunidad gestiona estos riesgos
El proyecto Gateway API, liderado por SIG-Network, aborda estos riesgos mediante mecanismos concretos:
• Pruebas de conformidad estrictas que garantizan comportamiento consistente entre distintos controladores, reduciendo la fragmentación.
• El modelo de Policy Attachment permite aplicar políticas de seguridad y rate limiting de forma declarativa y jerárquica, reduciendo el impacto de configuraciones erróneas.
• Reglas de scope claras: un controlador solo reporta errores sobre objetos dentro de su cadena de propiedad, evitando conflictos entre múltiples implementaciones en el mismo clúster.
La migración a Gateway API no es urgente por moda técnica; es urgente porque marzo de 2026 es una fecha concreta, y los CVEs no esperan ventanas de mantenimiento.
Kubernetes SIG-Network · Gateway API · 2025–2026
Top comments (0)