En marzo de 2026 el proyecto kubernetes/ingress-nginx quedó oficialmente retirado. No hay que confundirlo: no es NGINX como servidor web ni el comercial nginxinc/kubernetes-ingress de F5 — lo que se cerró es el controlador comunitario que durante años fue el ingress por defecto en la mayoría de los clústeres. En la práctica significa una cosa: ya no hay nuevas releases, ni correcciones de bugs, ni — lo más crítico — vulnerabilidades cerradas. Las instalaciones existentes siguen aceptando tráfico, pero ahora son infraestructura sin soporte justo en el borde del clúster.
Por qué es urgente: IngressNightmare y blast radius
No es una tarea para "el próximo trimestre". El detonante del retiro fue IngressNightmare — CVE-2025-1974, con una puntuación CVSS 9.8. El admission webhook del controlador permitía RCE mediante inyección en el AdmissionReview, y los permisos por defecto daban acceso de lectura a todos los Secrets del clúster. La cadena es evidente: un controlador en la entrada que ya nadie parchea, más una clase de vulnerabilidades que filtran todos los secretos de golpe. El blast radius no es un servicio, sino el clúster entero. Cada día sobre un controlador retirado es un riesgo aceptado que crece con cada nueva CVE que jamás se corregirá.
Gateway API: una división de roles, no un logo nuevo
No hace falta entrar en pánico y reescribirlo todo de la noche a la mañana — pero tampoco se puede alargar. El modelo objetivo ya está maduro: Gateway API se estabilizó en Kubernetes 1.35. Y no es "otro Ingress con otro logo", sino un modelo de responsabilidad distinto.
El viejo Ingress mezclaba infraestructura y aplicación en un solo objeto: TLS, anotaciones del controlador y enrutamiento de negocio convivían, las anotaciones no se trasladaban entre controladores y el comportamiento dependía del proveedor. Gateway API separa los roles por propietario:
GatewayClassyGateway— el punto de entrada y el comportamiento de la infraestructura, propiedad del equipo de plataforma;HTTPRoute— las reglas de tráfico de la aplicación, propiedad del equipo de producto.
El canary ahora se define con el campo weight en la propia ruta, no con una anotación de un controlador concreto, y la configuración es portable entre implementaciones. Ese es el beneficio principal: dejas de ser rehén de un único proveedor de anotaciones.
Cómo migrar: auditoría, dos pilas, cutover por fases
La migración empieza con una auditoría, no con una instalación. Reparte todos tus objetos Ingress en dos pilas. Los simples (TLS más enrutamiento básico) pasan a Gateway + HTTPRoute casi de forma mecánica. Los complejos — casos cargados de anotaciones con rewrites, canary y dominios canónicos — son candidatos a un rediseño bajo el modelo de Gateway API, no a un traslado directo; son los que se comerán la mayor parte del tiempo.
Después viene una instalación en paralelo. Levanta el controlador nuevo junto al viejo y desplaza el tráfico mediante ingressClassName por fases: primero los servicios non-critical, luego los critical y, al final, los high-value. Las rutas del nuevo controlador conviene verificarlas bajo tráfico real antes de cambiar el DNS, no después.
Qué controlador elegir
La elección de la implementación depende de la plataforma: Envoy Gateway (CNCF, Gateway API nativo), Cilium Gateway (si Cilium ya es tu CNI — un único control plane), AWS ALB / Lattice para EKS, además de Traefik o Contour/Kong. Si aprieta el tiempo, un paso intermedio viable es Traefik como drop-in: su CRD Middleware sustituye el "zoo de anotaciones" por objetos reutilizables (rate-limit, basic-auth, CORS, strip-prefix). Pero el objetivo estratégico es el propio Gateway API: sobrevive a un cambio de controlador, a diferencia de las anotaciones.
No olvidar la higiene de upgrades
El retiro de ingress-nginx es un caso particular de una enfermedad más general: la filtración de APIs deprecadas durante los upgrades. Convierte los escáneres kubent y Pluto en un paso obligatorio de CI antes de cualquier upgrade del clúster — así verás el próximo componente "eliminado de repente" con antelación, no en producción.
"Funciona" ≠ "con soporte"
La fecha límite ya quedó atrás. Eso saca la migración de la categoría "roadmap técnico" y la mete en "gestión de riesgo": "funciona" ya no equivale a "con soporte", y en el borde del clúster esa diferencia se mide en secretos robados.