Cómo Migrar de Ingress NGINX a Gateway API Antes del Retiro
Antes de comenzar
- Acceso cluster-admin o equivalente a cada clúster Kubernetes que planeas migrar
- Un inventario de recursos Ingress actuales, IngressClasses, secretos TLS y anotaciones ingress-nginx
- Un entorno de test o staging que refleje el comportamiento de enrutamiento de producción lo suficientemente de cerca para validar casos extremos
- Un plan de rollback que pueda restaurar el tráfico a la ruta ingress-nginx existente rápidamente
- Una implementación o controlador objetivo de Gateway API seleccionado para tu entorno
Lo que aprenderás
- Auditar el uso de ingress-nginx antes de convertir nada
- Elegir un objetivo de migración realista basado en funcionalidades en lugar de claims de marketing
- Instalar recursos Gateway API y un controlador compatible de forma segura
- Traducir un Ingress funcional a recursos Gateway y HTTPRoute
- Ejecutar ingress-nginx y Gateway API lado a lado mientras comparas comportamiento
- Manejar casos avanzados como rewrites, auth, manipulación de headers y enrutamiento ponderado
- Hacer cutover de tráfico con triggers de rollback y monitoreo en su lugar
En esta página
Este tutorial es para equipos que usan el controlador ingress-nginx de la comunidad y necesitan una ruta de migración práctica antes de quedarse manteniendo infraestructura de borde sin soporte. La parte urgente no es la API Kubernetes Ingress en sí. La parte urgente es que muchos clústeres dependen de comportamiento específico del controlador ingress-nginx, y esos comportamientos no se traducen limpiamente solo cambiando un manifiesto.
Lo que hace esta migración complicada es que Ingress y Gateway API modelan el problema de forma diferente. Con Ingress, mucho comportamiento avanzado se empaqueta en anotaciones en un objeto. Con Gateway API, los puntos de entrada, TLS y enrutamiento están divididos entre múltiples recursos y a menudo entre diferentes personas. Ese es un mejor modelo a largo plazo, pero significa que la migración es parte traducción, parte limpieza y parte rediseño de comportamiento.
Al final de este tutorial, tendrás un flujo de trabajo de migración repetible: auditar lo que ingress-nginx realmente está haciendo hoy, instalar Gateway API de forma segura, traducir un ingress de extremo a extremo, ejecutar ambas rutas lado a lado, migrar casos avanzados intencionalmente y hacer cutover de tráfico con rollback listo. Para contexto más amplio sobre la línea de tiempo de retiro y lo que significa para tus clústeres, consulta Ingress NGINX Retirement: What It Means and How to Migrate.
El tutorial completo cubre auditoría del uso actual de ingress, decisión sobre objetivo de migración, instalación de componentes Gateway API, traducción de Ingress a recursos Gateway, ejecución lado a lado, migración de casos avanzados y cutover seguro.
Trata cada anotación como una decisión de migración, no una conversión de sintaxis. Algunos comportamientos de ingress-nginx son defaults o peculiaridades en lugar de funcionalidades portables.
Elige tu controlador probando las funcionalidades exactas que usas hoy, no contando cuántas funcionalidades aparecen en una página de comparación.
Instala Gateway API primero como infraestructura de plataforma compartida. No empieces dejando que cada equipo de aplicación cree Gateways arbitrarios con sus propios puntos de entrada.
Una prueba de smoke que pasa no es suficiente. Compara redirects, headers, cookies, comportamiento de auth y semántica de paths antes de confiar en la nueva ruta.
Las funcionalidades estándar de Gateway API se trasladan bien entre implementaciones. Auth, rate limits y algún comportamiento de política avanzado normalmente no.
No elimines objetos ingress-nginx durante la misma ventana en la que primero mueves tráfico de usuarios. Haz cutover primero, observa, luego limpia.
Conclusión
La forma segura de migrar de ingress-nginx a Gateway API no es “convertir todo y esperar.” Es: auditar comportamiento actual, elegir un controlador objetivo basado en las funcionalidades que realmente usas, instalar Gateway API como infraestructura de plataforma compartida, traducir un ingress limpiamente, validar ambas rutas lado a lado, luego hacer cutover con rollback listo.
Esta migración no es solo reemplazar un controlador. Es una oportunidad para reducir deuda de anotaciones, hacer la propiedad del enrutamiento más clara y mover tu configuración de borde hacia un modelo nativo de Kubernetes más portable.
Artículos Relacionados
Cómo Desplegar un AI Gateway en Kubernetes para Cargas de Trabajo de Inferencia
Aprende a desplegar un AI gateway en Kubernetes para cargas de trabajo de inferencia, con patrones prácticos de enrutamiento, fiabilidad, observabilidad y seguridad.
Implementar Rate Limiting y Controles de Costos para APIs LLM: Presupuestos de Tokens, Throttling por Clave y Dashboards de Uso
Construye y despliega un proxy de API LLM con rate limiting por clave, presupuestos de tokens, caché de coincidencia exacta, dashboards de costos y alertas por webhook usando TypeScript y SQLite.
Construir, Asegurar y Desplegar un Servidor MCP Personalizado: De la Definición de Herramientas a Producción
Tutorial paso a paso para construir un servidor MCP más allá del hello-world con PostgreSQL, autenticación, sandboxing de consultas y despliegue con Docker.