La vida después de Ingress NGINX

Si tu clúster sigue enrutando tráfico con ingress-nginx, estás ejecutando software que ya no tiene a nadie detrás para arreglarlo. El repositorio se archivó el 24 de marzo de 2026. No habrá más versiones, ni correcciones de errores y — lo importante — ningún parche de seguridad, para ninguna vulnerabilidad, nunca más. Ese día no se rompió nada, y ese es exactamente el problema: tu ingress sigue funcionando, así que nada te obligó a actuar.

Esta es una guía de migración escrita después de la fecha límite, no antes. Cubre cómo medir tu exposición en cuatro comandos, cómo elegir destino con datos en lugar de intuición, los comportamientos de ingress-nginx que cambian de significado en silencio al traducirlos, y una secuencia de despliegue que te permite devolver el tráfico si el nuevo plano de datos se comporta mal.

Qué ha pasado de verdad — y qué no

La cronología es corta y conviene contarla con precisión, porque mucho comentario de segunda mano la ha deformado. El SIG Network de Kubernetes y el Security Response Committee anunciaron la retirada el 11 de noviembre de 2025. El 29 de enero de 2026 el Steering Committee y el SRC subieron el tono con una declaración conjunta poco habitual por lo directa: «seguir con Ingress NGINX después de su retirada os deja a vosotros y a vuestros usuarios expuestos a un ataque», y «ninguna de las alternativas disponibles es un reemplazo directo».^{[retire][steering]}

La última fila es la que más gente entiende mal. La API Ingress no está obsoleta. La documentación dice que es de disponibilidad general, que el proyecto no tiene planes de eliminarla y que simplemente está congelada: sin más cambios ni actualizaciones. Tus objetos Ingress de networking.k8s.io/v1 son Kubernetes válido y lo seguirán siendo. Lo que ha muerto es un controlador concreto que los lee.^[ingressdoc]

Lo que heredas si te quedas

La forma más clara de dimensionar el riesgo es mirar los arreglos de seguridad que el proyecto publicó en sus últimas semanas. El 2 de febrero de 2026 — cuatro días después de la declaración del Steering, siete semanas antes de que el repositorio pasara a solo lectura — el SRC divulgó cuatro vulnerabilidades en ingress-nginx: CVE-2026-1580, CVE-2026-24512, CVE-2026-24513 y CVE-2026-24514. Las más graves se calificaron como ALTA con 8,8, corregidas en v1.13.7 y v1.14.3.^[advisory]

CVE-2026-24512 es la que hay que interiorizar. El campo rules.http.paths.path de un Ingress permitía inyectar configuración en NGINX, lo que llevaba a ejecución arbitraria de código en el contexto del controlador y a la divulgación de todos los Secret que el controlador puede leer — que, en una instalación por defecto, son todos los del clúster. La mitigación provisional era un validating admission controller que rechazase los Ingress con path type ImplementationSpecific. Fíjate en lo que exige esa clase de fallo al atacante: poder crear un Ingress. Cualquiera con permisos de escritura en un namespace cumple el requisito.^[cve24512]

Después llegaron dos más, y son las que rematan el argumento. CVE-2026-3288, divulgada el 9 de marzo de 2026 y calificada como ALTA con 8,8, era inyección de configuración a través de la anotación rewrite-target — la misma anotación sobre la que avisa la tabla de semántica más abajo — corregida en v1.13.8, v1.14.4 y v1.15.0. Y CVE-2026-4342, divulgada el 19 de marzo de 2026, con 8,8 y el mismo vector: inyección de configuración a través de comentarios, otra vez con ejecución de código en el controlador y divulgación de Secrets de todo el clúster. Se corrigió en v1.13.9, v1.14.5 y controller-v1.15.1. Es decir, la versión final. Lo último que publicó este proyecto fue un parche de seguridad, cinco días antes de que el repositorio pasara a solo lectura. Lo que venga después no tendrá nada.^{[cve3288][cve4342][lastrel]}

Si quieres la cota superior, el precedente es CVE-2025-1974 — «IngressNightmare», marzo de 2025, CVSS 9,8. El proyecto Kubernetes lo describió sin rodeos: cualquier cosa en la red de pods tenía muchas posibilidades de tomar el control del clúster, sin necesidad de credenciales. Aquella tuvo parche. La siguiente no lo tendrá.^[nightmare]

Los despliegues existentes seguirán funcionando, así que a menos que lo compruebes de forma proactiva, es posible que no sepas que estás afectado hasta que te hayan comprometido.^[steering]

Sobre la escala: el Steering Committee y el SRC afirman que alrededor del 50 % de los entornos cloud native dependen del controlador, citando investigación interna de Datadog. Tómalo como una cifra orientativa y no exacta — el conjunto de datos no es público y refleja entornos monitorizados por Datadog — pero el orden de magnitud lo corrobora el propio dato del proyecto en 2025: «más del 40 % de los clústeres de Kubernetes». En cualquier caso, no es una tarea de limpieza menor.

Averigua si te afecta

Antes de planificar nada, mide. El primer comando es el que publica el propio proyecto Kubernetes; los otros tres te dicen cuánto trabajo tienes realmente delante, porque el coste de esta migración no es el número de objetos Ingress, sino el número de anotaciones distintas que hay detrás.

# 1. The check the Kubernetes project itself publishes
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

# 2. Which controller image, and therefore which version, is actually running
kubectl get deploy -A -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'

# 3. How much surface you have to translate: every Ingress bound to it
kubectl get ingress -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.ingressClassName}{"\n"}{end}'

# 4. The real cost driver - the annotations, ranked by how often you use them
kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]' \
  | grep -F 'nginx.ingress.kubernetes.io/' | sort | uniq -c | sort -rn

El cuarto comando es la estimación. Un clúster con sesenta Ingress y cuatro anotaciones es una tarde. Un clúster con doce Ingress y veintidós anotaciones — incluida configuration-snippet — es un proyecto, y acabas de descubrir por qué.

Elige el destino antes de tocar un solo YAML

Hay tres opciones honestas, y la correcta depende de cuánto dependas realmente del comportamiento de ingress-nginx. Conviene saberlo antes de hacer la lista corta: los únicos controladores de Ingress que Kubernetes soporta y mantiene como proyecto son el de AWS y el de GCE. Todo lo demás en la lista documentada — Traefik, HAProxy, Contour, Kong, APISIX, Cilium, Higress, Istio y el resto — es de terceros. Y ojo: kubernetes/ingress-nginx ya ni siquiera aparece en esa página.^[ctrldoc]

Si eliges la vía Gateway API, la versión actual es la v1.6.0, etiquetada a finales de junio de 2026 y anunciada el 3 de agosto de 2026. TCPRoute y UDPRoute pasaron de Experimental a Standard en v1 con esa versión, junto a Gateway, GatewayClass, HTTPRoute, GRPCRoute, TLSRoute, ListenerSet, ReferenceGrant y BackendTLSPolicy. Las versiones v1alpha2 de TCPRoute y UDPRoute quedan obsoletas desde la v1.6 y se eliminarán. Instala el parche actual, v1.6.1 del 16 de julio de 2026, no la v1.6.0. Sobre versiones de clúster: el proyecto no publica un mínimo fijo; su política declarada es dar soporte a las cinco versiones menores más recientes de Kubernetes, así que contrástalo con tu clúster en lugar de fiarte de un número leído en un blog.^{[gw16][gw16rel][gw161][versioning]}

Hay un cambio estructural en la v1.6 que conviene tener en cuenta al planificar: los recursos experimentales nuevos viven ahora en un grupo de API aparte, gateway.networking.x-k8s.io, con un prefijo X en el nombre del tipo — XBackend, XMesh. Cuando uno se gradúa, se renombra dentro de gateway.networking.k8s.io y pierde el prefijo. Es una señal deliberada: si el kind del que vas a depender empieza por X, no es un compromiso de producción.^[gw16]

Elige con datos. El proyecto Gateway API publica informes de conformidad por versión que indican exactamente cuántas funciones extendidas supera cada implementación, por tipo de ruta. Esa tabla es mejor herramienta de criba que cualquier página comparativa de fabricante, incluida esta — consulta la fila de la versión que piensas ejecutar, no la del año pasado. Ten en cuenta que no todas las implementaciones envían informe en cada versión: una fila ausente significa «sin informe para esta versión», no «no conforme».^[conform]

Un apunte para quien trabaje con plataformas gestionadas en España y Latinoamérica: si estás en un servicio gestionado, comprueba primero qué controlador ofrece tu proveedor y en qué versión de Gateway API está certificado, porque en muchos casos el ciclo de actualización de la plataforma marca el ritmo real de la migración. Si además operas bajo el Esquema Nacional de Seguridad o alguna certificación equivalente, un componente sin mantenimiento expuesto a internet es un hallazgo de auditoría documentable, no solo una deuda técnica.

Cinco comportamientos que no sobreviven a la traducción

Aquí es donde se tuercen las migraciones, y merece la pena leerlo aunque ya hayas decidido el destino. ingress-nginx acumuló comportamientos que nunca estuvieron en la especificación de Ingress, de los que tus aplicaciones dependen ahora en silencio, y que ninguna implementación conforme de Gateway API reproduce. El proyecto Kubernetes documentó cinco de ellos precisamente para ahorrarle a la gente este descubrimiento.^[gotchas]

La redirección por barra final es la que más duele en la práctica, porque no falla de forma ruidosa. Las peticiones a /api que antes se redirigían a /api/ ahora devuelven un 404 desde la aplicación, y el error aparece en los logs de tu servicio en lugar de en el borde — así que la primera hipótesis es un bug del servicio, no la migración que hiciste anoche.

ingress2gateway: qué convierte y qué se niega a convertir

Existe un conversor oficial, y está mucho mejor que antes. ingress2gateway llegó a la 1.0 el 20 de marzo de 2026 como subproyecto del SIG Network. El cambio principal: la cobertura de anotaciones de ingress-nginx pasó de tres a más de treinta, incluyendo CORS, TLS hacia el backend, coincidencia por regex y reescritura de rutas. La versión 1.0 añadió además pruebas de integración a nivel de controlador que levantan un ingress-nginx real y un controlador Gateway API real en clústeres vivos y comparan su comportamiento en ejecución, en vez de limitarse a comparar YAML.^[i2gblog]

# Install the official converter (Go 1.25.5 or newer to build from source)
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# or: brew install ingress2gateway

# Convert a manifest on disk, without touching the cluster
ingress2gateway print --input-file ingress.yaml \
  --providers=ingress-nginx > gwapi.yaml

# Convert one namespace from a live cluster
ingress2gateway print --namespace shop \
  --providers=ingress-nginx > gwapi.yaml

# Convert everything, and keep the warnings - they are the migration backlog
ingress2gateway print --all-namespaces \
  --providers=ingress-nginx > gwapi.yaml 2> unsupported.log

Soporta nueve proveedores — ingress-nginx, nginx, traefik, kong, istio, apisix, cilium, gce y openapi — con seis emisores de salida, entre ellos envoy-gateway y kgateway. Su salida apunta a Gateway API v1.5.0. Lo que no va a hacer por ti:^[i2g]

• configuration-snippet y server-snippet: sin soporte, y no existe equivalente. Las directivas NGINX arbitrarias fueron exactamente la decisión de diseño que el proyecto Kubernetes señaló como origen de una «deuda técnica insalvable». Si tus snippets codifican lógica de negocio, esa lógica tiene que moverse a la aplicación, a un filtro o a un CRD de política específico de la implementación.^[retire]
• proxy-body-size: no hay equivalente en Gateway API. Se configura en el plano de datos, lo que significa que pasa a ser específico de la implementación y deja de ser portable.
• proxy-read-timeout / proxy-send-timeout: mapeo de mejor esfuerzo a timeouts.request, que no es lo mismo. Vuelve a medir bajo carga en lugar de asumir paridad.
• Normalización de URL: no es configurable a través del Gateway API estándar. Si dependías de ella, dependes del plano de datos y tienes que verificarlo implementación por implementación.

Lee los avisos de la herramienta como tu backlog de migración, no como ruido. Todo lo que imprime por stderr es un comportamiento que no pudo trasladar, y cada uno de ellos es un incidente de producción esperando al cambio de DNS.

Ingress y Gateway API, uno al lado del otro

Un ejemplo mínimo pero realista: un hostname, TLS y una ruta repartida entre una API y un front web. Ponerlos uno al lado del otro tiene sentido porque la versión Gateway API es más larga, y esa longitud extra no es ceremonia: es el comportamiento que ingress-nginx te daba implícitamente, ahora escrito.

Antes — un Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  namespace: shop
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-example-com-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Después — un Gateway y dos HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop-gateway
  namespace: shop
spec:
  gatewayClassName: nginx          # must match an installed GatewayClass
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: shop.example.com
      allowedRoutes:
        namespaces:
          from: Same
    - name: https
      protocol: HTTPS
      port: 443
      hostname: shop.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - group: ""              # empty string = core API group
            kind: Secret
            name: shop-example-com-tls
      allowedRoutes:
        namespaces:
          from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: https
  hostnames: [shop.example.com]
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: web-service
          port: 80
---
# ingress-nginx redirected HTTP to HTTPS for you. Gateway API does not.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route-ssl-redirect
  namespace: shop
spec:
  parentRefs:
    - name: shop-gateway
      sectionName: http
  hostnames: [shop.example.com]
  rules:
    - filters:
        - type: RequestRedirect
          requestRedirect:
            scheme: https
            statusCode: 308

Tres cosas en las que fijarse. sectionName ata la ruta a un listener concreto, que es como mantienes separados los comportamientos HTTP y HTTPS. allowedRoutes es la separación de roles que la API Ingress nunca tuvo: un equipo de plataforma es dueño del Gateway y decide qué namespaces pueden engancharse, mientras los equipos de aplicación son dueños de sus HTTPRoute. Y el tercer objeto existe solo para reproducir una redirección que ingress-nginx hacía por defecto — que es un resumen bastante justo de toda la migración.^[gwapi]

Un cambio que puedes deshacer

La propiedad más útil de esta migración es que ambos controladores pueden convivir. Son objetos distintos, observando recursos distintos, detrás de balanceadores distintos. Nada te obliga a un cambio de golpe, así que no lo hagas.

1. Instala el nuevo controlador junto al viejo. GatewayClass propio, namespace propio, su propio Service LoadBalancer y su propia dirección externa. El tráfico sigue yendo a ingress-nginx.
2. Convierte y revisa. Ejecuta ingress2gateway contra un namespace, lee los avisos y corrige a mano las anotaciones que no pudo traducir. No apliques la salida sin leerla.
3. Aplica los objetos Gateway API con los mismos hostnames. Para los usuarios todavía no cambia nada: el nuevo controlador tiene su propia IP y ningún registro DNS apunta a él.
4. Compara los dos bordes directamente con --resolve, petición a petición: códigos de estado, destinos de redirección, cabeceras, y en particular los casos de barra final y regex. Este es el paso que caza los cinco comportamientos anteriores.
5. Mueve el DNS de forma gradual: registro con TTL bajo, política ponderada, o primero un hostname no crítico. Mantén ingress-nginx sirviendo hasta que el nuevo borde haya aguantado tráfico real durante un pico.
6. Desmantela con intención. Elimina el Deployment de ingress-nginx, su Service, su IngressClass y su ValidatingWebhookConfiguration. Dejar atrás el webhook de admisión es la forma de acabar con un clúster roto semanas después.

# Install the Standard channel CRDs (server-side apply, as the project documents)
kubectl apply --server-side -f \
  https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.1/standard-install.yaml

# The Gateway must be Programmed before you move any traffic to it
kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.conditions[?(@.type=="Programmed")].status}{"\n"}'

# Every parentRef must be Accepted, and every backendRef ResolvedRefs.
# Nested ranges keep each condition paired with its own status.
kubectl get httproute shop-route -n shop -o jsonpath='{range .status.parents[*]}{.controllerName}{"\t"}{range .conditions[*]}{.type}={.status}{" "}{end}{"\n"}{end}'

# Compare old and new on the same request, before DNS moves.
# A cloud load balancer publishes either .ip or .hostname - AWS uses .hostname,
# so --connect-to is used instead of --resolve: it accepts both.
OLD=$(kubectl get svc -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}{.status.loadBalancer.ingress[0].hostname}')
NEW=$(kubectl get gateway shop-gateway -n shop \
  -o jsonpath='{.status.addresses[0].value}')
for edge in "$OLD" "$NEW"; do
  curl -sS -o /dev/null -w "$edge  %{http_code}  %{redirect_url}\n" \
    --connect-to "shop.example.com:443:$edge:443" https://shop.example.com/api
done

Fíjate en la condición Programmed del segundo comando. Un Gateway que existe no es un Gateway que está sirviendo; las condiciones de estado son el contrato, y comprobarlas sale más barato que descubrir la diferencia durante el cambio de DNS.

ingress-nginx, NGINX Ingress y NGINX Gateway Fabric

Tres proyectos distintos, nombres parecidos y una fuente real de malas decisiones justo durante esta migración. Hay quien migra de ingress-nginx a «NGINX Ingress» creyendo que ha cambiado algo, y se lleva la sorpresa después — o descarta NGINX por completo dando por hecho que los tres murieron a la vez.

El propio proyecto Kubernetes tuvo que dejarlo por escrito: ambos usan NGINX como plano de datos, pero por lo demás no tienen relación. Migrar del controlador comunitario al de F5 es una migración real, con su propio trabajo de traducción de anotaciones; no es un cambio de nombre.^[gotchas]

Qué haría yo esta semana

Si no has empezado: ejecuta hoy los cuatro comandos de detección, porque el recuento de anotaciones es el único número que te dice si esto es una tarde o un trimestre. Si la respuesta es «una tarde», hazlo esta semana y deja de cargar con el riesgo. Si la respuesta es «un trimestre», el movimiento útil sigue siendo instalar ya un segundo controlador en paralelo y migrar un hostname de poco riesgo, porque la primera migración es donde descubres cuáles de tus suposiciones eran en realidad comportamientos de ingress-nginx.

La lección de fondo ya la he escrito antes en arquitecturas cloud aburridas: los componentes que más probabilidades tienen de hacerte daño son aquellos en los que nadie piensa, precisamente porque llevan años funcionando. Un controlador de Ingress mantenido por una o dos personas voluntarias, delante de la mitad del mundo cloud native, era una concentración de riesgo mucho antes de archivarse. Merece la pena auditar qué más en tu stack tiene esa forma — y preguntarse, como en cuándo no usar Kubernetes, si la plataforma está compensando la superficie operativa que te cuesta.

Preguntas frecuentes

¿Es seguro seguir con ingress-nginx de momento?

Funciona, y va a seguir funcionando. Pero no recibirá nunca otro parche de seguridad, y conviene ver qué fue en realidad la versión final: controller-v1.15.1 era el arreglo de CVE-2026-4342, una inyección de configuración que llegaba a ejecución de código en el controlador y a la divulgación de Secrets de todo el clúster, publicada el mismo día que el aviso y cinco días antes de que el repositorio pasara a solo lectura. Fue el sexto fallo de ese tipo en siete semanas. El siguiente no tendrá arreglo. Si tienes que mantenerlo unas semanas más, como mínimo restringe quién puede crear objetos Ingress, quita al controlador el acceso a Secrets de todo el clúster si tu instalación se lo concede, y no expongas el webhook de admisión.

¿También está obsoleta la API Ingress de Kubernetes?

No, y esta es la lectura equivocada más habitual. La API Ingress es de disponibilidad general, con las garantías de estabilidad normales de GA, y el proyecto Kubernetes ha declarado que no tiene planes de eliminarla. Está congelada: sin más desarrollo. Lo retirado fue solo el controlador NGINX comunitario, no la API que implementa.

¿Cuál es la diferencia entre ingress-nginx y nginx-ingress?

Son proyectos distintos de organizaciones distintas. kubernetes/ingress-nginx lo mantenía la comunidad Kubernetes y está archivado. nginx/kubernetes-ingress es el NGINX Ingress Controller de F5 y está en desarrollo activo. En palabras del propio proyecto Kubernetes: ambos usan NGINX como plano de datos, pero por lo demás no tienen relación. Pasar de uno a otro es una migración real, no un cambio de nombre.

¿Puede ingress2gateway migrar mi clúster automáticamente?

En parte. La versión 1.0 cubre más de treinta anotaciones de ingress-nginx, frente a tres antes, y es el punto de partida correcto. Pero configuration-snippet no tiene equivalente y no está soportada, proxy-body-size no tiene equivalente en Gateway API, los timeouts de proxy se mapean solo con mejor esfuerzo, y la normalización de URL no es expresable en absoluto. Lee todo lo que imprime por stderr: esa salida es tu trabajo manual restante.

¿Migro a Gateway API o simplemente cambio de controlador de Ingress?

Cambiar de controlador es más rápido y conserva tus objetos actuales, pero aterrizas en una API congelada y aun así tienes que reexpresar cada anotación en un dialecto nuevo, así que probablemente lo vuelvas a hacer. Gateway API es una reescritura mayor, pero es donde está ocurriendo el desarrollo y te da separación de roles entre el equipo de plataforma, dueño del Gateway, y los equipos de aplicación, dueños de sus rutas. Los parques grandes de Ingress sencillos favorecen cambiar de controlador; los bordes compartidos entre varios equipos favorecen Gateway API.

¿Qué implementación de Gateway API debería elegir?

Elige a partir de los informes de conformidad publicados, no de las páginas de marketing. El proyecto Gateway API lista, versión a versión, exactamente cuántas funciones extendidas supera cada implementación para HTTPRoute, GRPCRoute y TLSRoute. Consulta el informe de la versión que vas a ejecutar de verdad, confirma que la implementación soporta las funciones concretas en las que se han traducido tus anotaciones, y confirma que está soportada en tu plataforma.

¿Necesito actualizar Kubernetes antes de instalar Gateway API?

El proyecto no publica una versión mínima fija de Kubernetes; su política declarada es dar soporte a las cinco versiones menores más recientes, así que contrasta esa política con tu clúster en vez de fiarte de un número leído en un blog. Instala los CRD del canal Standard del parche actual — la v1.6.1, del 16 de julio de 2026 — usando server-side apply, que es como lo documenta el proyecto. Si instalas el canal Experimental, sus CRD son claramente demasiado grandes para un kubectl apply del lado cliente, y los tipos experimentales llevan ahora un prefijo X en un grupo de API aparte precisamente para que no construyas producción sobre ellos por accidente.

La misma disciplina aplica a la criptografía de debajo: en SSH y TLS post-cuánticos tienes qué verificar en las conexiones de las que dependen estos sistemas.

Fuentes

Cada afirmación de arriba es rastreable a alguna de estas. Solo fuentes primarias y oficiales: entradas y documentación del proyecto Kubernetes, estado de los repositorios, avisos de seguridad y la especificación de Gateway API.

1. Kubernetes blog — Ingress NGINX Retirement: What You Need to Know (11 Nov 2025)
2. Kubernetes blog — Ingress NGINX: Statement from the Steering and Security Response Committees (29 Jan 2026)
3. Kubernetes blog — Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know (27 Feb 2026)
4. GitHub — kubernetes/ingress-nginx (public archive, read-only since 24 Mar 2026)
5. GitHub — ingress-nginx controller-v1.15.1, the final release (19 Mar 2026)
6. Kubernetes Security Response Committee — [Security Advisory] Multiple issues in ingress-nginx (2 Feb 2026)
7. kubernetes/kubernetes#136678 — CVE-2026-24512, configuration injection via the Ingress path field
8. kubernetes/kubernetes#137560 — CVE-2026-3288, configuration injection via the rewrite-target annotation
9. kubernetes/kubernetes#137893 — CVE-2026-4342, comment-based configuration injection (fixed by the final release)
10. Kubernetes blog — Ingress-nginx CVE-2025-1974: What You Need to Know (24 Mar 2025)
11. Kubernetes documentation — Ingress (the API is generally available and frozen)
12. Kubernetes documentation — Ingress Controllers
13. Gateway API — API overview and channel status
14. Kubernetes blog — Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard (3 Aug 2026)
15. GitHub — Gateway API v1.6.0 release notes
16. GitHub — Gateway API v1.6.1, the current patch release (16 July 2026)
17. Gateway API — v1.6 conformance reports by implementation
18. GitHub — kubernetes-sigs/ingress2gateway
19. Kubernetes blog — Announcing Ingress2Gateway 1.0: Your Path to Gateway API (20 Mar 2026)
20. GitHub — nginx/kubernetes-ingress, the F5 NGINX Ingress Controller (a different project)
21. GitHub — nginx/nginx-gateway-fabric, F5's Gateway API implementation
22. Gateway API — versioning, release channels and graduation criteria