Retiro de Ingress NGINX: Tu guía de migración de Kubernetes

El retiro de Ingress NGINX ya no es algo que los equipos de plataforma puedan dejar en el backlog. Si tus clústeres aún dependen de él, marzo de 2026 es una fecha límite operacional dura, no un recordatorio suave. El riesgo real no es que tus cargas de trabajo se detengan instantáneamente. El riesgo real es que sigan ejecutándose sobre un componente de borde sin mantenimiento, que es exactamente el tipo de exposición que convierte una decisión rutinaria de plataforma en un incidente urgente después.

Por eso esta migración necesita tratarse como ingeniería de tráfico de producción, no como un ejercicio de conversión de manifiestos. Necesitas saber dónde se está ejecutando Ingress NGINX, qué comportamientos tus aplicaciones dependen silenciosamente, qué modelo de reemplazo se ajusta a tu entorno y cómo validar la transición sin sorprender a los usuarios.

Qué se retira y cuándo

Según el anuncio del proyecto Kubernetes, Ingress NGINX se retirará el 31 de marzo de 2026, después de lo cual no habrá más releases, correcciones de errores ni actualizaciones de seguridad (blog de Kubernetes). Los despliegues existentes seguirán funcionando, y los artefactos de instalación como charts de Helm e imágenes de contenedor permanecerán disponibles, pero “sigue funcionando” no es lo mismo que “sigue soportado”. Los Comités Directivos y de Respuesta de Seguridad de Kubernetes emitieron una declaración de seguimiento reforzando la urgencia.

Esa distinción importa porque muchos equipos no sentirán dolor inmediato. El tráfico puede seguir fluyendo. Los dashboards pueden permanecer verdes. Nada obvio puede romperse el primer día. Pero el componente ya no recibirá correcciones para vulnerabilidades recién descubiertas, y eso cambia el perfil de riesgo inmediatamente.

El primer paso práctico es confirmar si realmente lo estás usando. En muchos entornos, eso significa inventariar clústeres, namespaces, releases de Helm y clases de ingress en lugar de asumir que una oferta gestionada más nueva lo reemplazó en todas partes.

Una conversación simple de migración debería comenzar con cuatro preguntas:

1. dónde se está ejecutando Ingress NGINX hoy
2. qué aplicaciones aún dependen de él
3. qué anotaciones o comportamientos personalizados están en uso
4. qué controlador o modelo de API lo reemplazará

Si no puedes responder esas preguntas limpiamente, no estás listo para una transición segura.

Riesgos de permanecer en Ingress NGINX

El mayor error que los equipos pueden cometer es tratar el retiro como una depreciación ordinaria. Esto no es solo una advertencia de que una función será menos popular el próximo año. Es un problema de seguridad y operaciones.

Después del retiro, permanecer en Ingress NGINX significa:

• sin correcciones de errores futuras
• sin parches de seguridad
• sin actualizaciones oficiales de ningún tipo
• creciente deriva de plataforma del resto del ecosistema Kubernetes
• más riesgo operacional cada vez que la infraestructura circundante cambie

El peligro oculto es que los despliegues existentes a menudo seguirán funcionando lo suficientemente bien como para evitar atención. Eso crea una falsa sensación de seguridad. Un componente de borde sin soporte sigue siendo un componente de borde, y los componentes de borde tienden a ser de alta consecuencia cuando fallan o son expuestos.

También hay un riesgo de planificación. Kubernetes ha sido explícito en que las alternativas disponibles no son reemplazos directos. Si tu plan de migración asume que puedes intercambiar un controlador en el último minuto con cero revisión de comportamiento, casi seguro estás subestimando el trabajo.

Por eso la mentalidad correcta no es “reemplazar un controlador de ingress”. Es re-modelar la entrada de tráfico, el comportamiento de enrutamiento y la propiedad de la plataforma.

Gateway API vs otras opciones de controlador

La mayoría de los equipos tienen dos caminos realistas.

Migrar a Gateway API

Gateway API es la dirección moderna que Kubernetes está impulsando para redes de servicio. Es más expresivo que el Ingress clásico, más estructurado y diseñado alrededor de roles organizacionales más claros. En lugar de amontonar comportamiento específico de implementación en anotaciones, da a los equipos de plataforma un modelo más explícito con recursos como GatewayClass, Gateway y HTTPRoute.

Esta es generalmente la mejor elección a largo plazo cuando quieres:

• separación más limpia de responsabilidades
• configuración de enrutamiento más portable
• mejor gobernanza multi-equipo
• funciones de enrutamiento de tráfico más ricas
• un estándar de plataforma orientado al futuro

Gateway API es especialmente atractivo si tu equipo de plataforma ya está pensando en políticas de tráfico más avanzadas, propiedad compartida de gateways o patrones de tráfico de IA e inferencia. Si eso está en tu hoja de ruta, nuestra guía de Kubernetes para cargas de trabajo de IA es un seguimiento útil porque la gestión moderna de tráfico se vuelve aún más importante una vez que las cargas de trabajo de inferencia y multi-inquilino entran en escena.

Permanecer en la API de Ingress pero cambiar de controlador

Este es a menudo el camino más rápido a corto plazo. Si tu objetivo es reducir el riesgo de retiro rápidamente mientras minimizas los cambios a nivel de aplicación, otro controlador de ingress soportado puede ser el puente más práctico.

Esta opción puede tener sentido cuando:

• tu modelo de tráfico sigue siendo relativamente simple
• tus equipos dependen fuertemente de la API de Ingress hoy
• tus propietarios de aplicaciones no están listos para cambios más amplios del modelo de enrutamiento
• tu línea de tiempo de migración es ajustada

La compensación es que puedes evitar el problema de retiro de marzo de 2026 sin obtener los beneficios a largo plazo de Gateway API. Para algunas organizaciones, esa sigue siendo la decisión correcta. La velocidad y la sostenibilidad importan.

El marco de decisión real

No enmarques esto como “¿Cuál es técnicamente más genial?” Enmárcalo como:

• ¿Cuánta portabilidad de comportamiento necesitamos?
• ¿Cuánto cambio pueden absorber los equipos de aplicación ahora mismo?
• ¿Cuánta deuda de anotaciones tenemos?
• ¿Necesitamos un modelo de tráfico moderno orientado a roles?
• ¿Estamos resolviendo para el próximo trimestre o los próximos tres años?

Eso te da una mejor respuesta que copiar lo que otra empresa publicó en redes sociales.

Cinco comportamientos que los equipos pasan por alto antes de la migración

Aquí es donde muchas migraciones salen mal. Convertir manifiestos es la parte fácil. Preservar el comportamiento del tráfico es la parte difícil.

Kubernetes ya ha resaltado varios comportamientos de Ingress NGINX que sorprenden a los equipos durante la migración. Incluso una traducción de manifiestos “exitosa” puede romper producción si no los consideras.

1. El comportamiento de regex puede ser más amplio de lo que piensas

Ingress NGINX puede tratar las rutas como expresiones regulares de maneras que los equipos no esperan, especialmente cuando ciertas anotaciones están presentes. Si migras a Gateway API u otro controlador y asumes que el comportamiento exacto o de prefijo se trasladará de la misma manera, puedes romper el enrutamiento.

2. use-regex puede afectar más que una regla de ruta

Un comportamiento particularmente peligroso es que nginx.ingress.kubernetes.io/use-regex: "true" puede afectar todas las rutas para un host a través de los ingresses de Ingress NGINX, no solo la regla donde lo notaste primero. Eso significa que errores tipográficos o suposiciones que parecían inofensivos pueden ser parte de tu comportamiento de tráfico actual.

3. Las reglas de reescritura pueden implicar silenciosamente coincidencia de regex

La anotación rewrite-target puede introducir efectivamente comportamiento estilo regex incluso si no pensaste explícitamente en la ruta como basada en regex. Los equipos a menudo descubren esto solo cuando las rutas migradas se vuelven más estrictas y las solicitudes previamente aceptadas comienzan a devolver 404.

4. Los redireccionamientos de barra diagonal final pueden desaparecer

Ingress NGINX puede redirigir solicitudes que les falta una barra diagonal final a la ruta con barra diagonal. Las implementaciones conformes de Gateway API no agregan silenciosamente ese redireccionamiento por ti. Si los clientes o sistemas descendentes dependen de ese comportamiento, la migración puede crear roturas sutiles.

5. La normalización de URL puede cambiar los resultados de coincidencia

Ingress NGINX normaliza las URLs antes de coincidir y enrutar. Si tus aplicaciones dependen de ese comportamiento, un nuevo controlador o implementación de Gateway API puede manejar solicitudes de aspecto equivalente de manera diferente a menos que recrees el comportamiento previsto explícitamente.

La lección clave es simple: tu comportamiento de enrutamiento de producción no es solo lo que dice tu YAML. También es lo que tu controlador realmente hace con ese YAML.

Validación, rollback y observabilidad

Una migración segura necesita tres cosas: visibilidad antes del cambio, transición controlada durante el cambio y rollback rápido si la realidad no coincide con el plan.

Validar comportamiento, no solo sintaxis

No es suficiente que los manifiestos se apliquen limpiamente. Necesitas probar:

• coincidencia exacta de rutas
• enrutamiento por prefijo
• comportamiento de regex
• reescrituras
• redireccionamientos
• terminación TLS
• manejo de encabezados
• health checks
• comportamiento de borde relacionado con autenticación
• respuestas de fallo

Si es posible, captura patrones de solicitudes en vivo antes de la migración y reproduce tráfico representativo en un entorno inferior. Eso te da una señal mucho mejor que probar manualmente dos o tres URLs.

Planificar rollback antes de la transición

El rollback debería ser parte de la primera reunión de diseño de migración, no algo que improvises después de que el cambio comience a fallar.

Un plan de rollback real debería definir:

• qué se revierte
• qué cambios de DNS o balanceador de carga deben revertirse
• cuánto tiempo toma el rollback
• quién tiene autoridad para activarlo
• qué cambios de datos o configuración son irreversibles

Si no puedes describir el rollback en cinco minutos, probablemente no está listo.

Mejorar la observabilidad antes de migrar

Los equipos a menudo esperan hasta la semana de migración para mirar la observabilidad a nivel de ingress. Eso es demasiado tarde.

Antes de la transición, asegúrate de tener buena visibilidad sobre:

• volumen de solicitudes
• cambios en códigos de estado
• percentiles de latencia
• fallos TLS
• cambios de tráfico a nivel de ruta
• salud del backend
• volumen de redireccionamientos
• picos de errores por ruta o host

No quieres que tu primera pista sea un mensaje de Slack de un equipo orientado al cliente. Las migraciones son más fáciles cuando puedes ver el comportamiento a nivel de ruta inmediatamente y comparar patrones antiguos versus nuevos en tiempo casi real.

La visibilidad de seguridad también importa. El borde es parte de tu límite de confianza, por eso una migración como esta debería revisarse junto con tu estrategia de arquitectura Zero Trust, no tratarse puramente como una tarea de redes.

Un plan de migración por fases

Los mejores planes de migración de Ingress NGINX son por fases, aburridos y altamente intencionales. Eso es algo bueno.

Fase 1: Inventariar y clasificar

Comienza catalogando cada clúster y aplicación que usa Ingress NGINX. Agrupa las cargas de trabajo por criticidad de tráfico, complejidad y uso de anotaciones.

En esta etapa, busca:

• anotaciones personalizadas
• rutas regex
• reglas de reescritura
• redireccionamientos
• nombres de host compartidos
• patrones de gateway multi-inquilino
• integraciones de autenticación y WAF
• CRDs o sidecars específicos del controlador

Si quieres migrar a Gateway API, aquí es donde herramientas como ingress2gateway pueden ayudar a traducir recursos, pero la traducción debería tratarse como un acelerador, no como prueba de corrección.

Fase 2: Elegir el modelo objetivo

Decide qué cargas de trabajo deberían moverse a Gateway API primero y cuáles pueden necesitar un reemplazo de controlador interino. No toda aplicación necesita el mismo camino.

Un patrón común es:

• aplicaciones internas simples primero
• aplicaciones externas no críticas después
• aplicaciones complejas o con muchas anotaciones más tarde
• tráfico de borde compartido y crítico para el negocio al final

Esto le da al equipo de plataforma tiempo para aprender sin apostar el tráfico más sensible primero.

Fase 3: Construir una matriz de comportamiento

Para cada aplicación o grupo de rutas, documenta:

• rutas esperadas
• redireccionamientos
• reescrituras
• requisitos de autenticación
• comportamiento TLS
• encabezados y cookies
• expectativas de salud del backend
• condiciones de fallo

Esto se convierte en el contrato que validas antes y después de la transición.

Fase 4: Ejecutar pruebas lado a lado

Donde sea posible, ejecuta el modelo objetivo en paralelo y compara el comportamiento. Eso puede significar tráfico espejado, nombres de host alternativos, puntos de entrada canary o transiciones por etapas por entorno.

Esta fase es donde las sorpresas se hacen visibles mientras el radio de impacto sigue siendo pequeño.

Fase 5: Transición en oleadas

Muévete en oleadas controladas con métricas de éxito claras, disparadores de rollback y propiedad con personal. No combines la migración de ingress con cinco cambios de plataforma no relacionados en la misma ventana.

Fase 6: Eliminar dependencias antiguas

Una vez que el tráfico es estable, elimina clases de ingress obsoletas, releases de Helm, configuraciones de controlador y suposiciones del equipo que aún apuntan a Ingress NGINX. Una migración no está completa hasta que la dependencia realmente se haya ido.

Descarga una hoja de trabajo de inventario de migración de clúster

El retiro de Ingress NGINX es urgente, pero la urgencia no es razón para apresurarse ciegamente. Los equipos que migran bien tratarán esto como un proyecto de comportamiento de tráfico, un proyecto de gobernanza de plataforma y un proyecto de exposición de seguridad todo a la vez.

El siguiente paso más práctico es construir una hoja de trabajo de inventario de migración de clúster que capture cada clase de ingress, nombre de host, anotación, reescritura, redireccionamiento, dependencia TLS y propietario de rollback en un solo lugar. Ese documento será más valioso que una declaración genérica de “deberíamos movernos a Gateway API”.

Obtén la Hoja de Trabajo Gratuita de Inventario de Migración de Clúster →

A partir de ahí, combina tu trabajo de migración con nuestra guía de Kubernetes para cargas de trabajo de IA, nuestra hoja de ruta de seguridad de cadena de suministro de software, y nuestra guía de arquitectura Zero Trust para que tu migración de borde fortalezca la plataforma más amplia en lugar de solo reemplazar un componente envejecido con otro.