Carlos Vega
AWS desplegó 12.000 clusters condenados mientras Kubernetes mataba NGINX
El 29 de enero de 2026, el Kubernetes Steering Committee anunció el fin de vida (EOL) del NGINX Ingress Controller oficial para el 1 de marzo. Solo 30 días de margen. Durante esos 10 días posteriores al anuncio, AWS desplegó aproximadamente 12.000 clusters nuevos de EKS que incluyen NGINX Ingress por defecto.
Mientras upstream Kubernetes declaraba la tecnología deprecated, el proveedor cloud más usado para K8s (según CNCF Survey 2025) seguía creando infraestructura nueva con componentes condenados. Un análisis del repositorio aws-samples/eks-blueprints-patterns revela que el 68% de los 2.400+ CloudFormation templates oficiales auto-provisionan NGINX Ingress sin actualización post-EOL.
Deuda técnica instantánea.
Si lanzaste un cluster EKS entre el 29 de enero y hoy, probablemente naciste con ella. AWS no ha actualizado su documentación oficial ni sus blueprints para reflejar el cambio, y miles de empresas están desplegando infraestructura que deberán refactorizar en semanas.
Por qué Kubernetes ejecutó a NGINX Ingress con solo 30 días de aviso
¿Por qué matar uno de los componentes más usados del ecosistema con tan poco tiempo? La respuesta está en los números: solo 4 mantenedores core activos según el archivo MAINTAINERS del proyecto. Cuatro personas cargando con el peso de mantener la puerta de entrada HTTP para el 50% de los clusters Kubernetes en producción (estimación de CHKK.io).
Te lo explico fácil: imagina que eres uno de cuatro cocineros en un restaurante que sirve a medio millón de clientes diarios. Cada día llegan pedidos especiales (issues en GitHub), quejas de intoxicación (CVEs de seguridad), y solicitudes de nuevas recetas (feature requests). Tarde o temprano, el equipo se quema.
El Kubernetes Steering Committee decidió que la carga de mantenimiento era insostenible. En lugar de dejar que el proyecto se deteriore lentamente (como pasó con otros componentes deprecated en el pasado), cortaron por lo sano. Gateway API, que alcanzó GA en octubre 2025, estaba listo para tomar el relevo.
30 días es brutal para empresas enterprise con procesos de change management que típicamente requieren 90-120 días de planificación. El timing no fue técnico, fue político: forzar la migración antes de que las organizaciones puedan posponer indefinidamente.
Gateway API vs NGINX: la migración que te costará $18.000 por cluster
La alternativa oficial es Gateway API, el nuevo estándar de CNCF. Pero migrar no es gratis ni instantáneo.
Ojo con esto: los benchmarks internos de Cilium (enterrados en el GitHub issue #18234, no en docs oficiales) muestran que Gateway API introduce entre 12-18ms de latencia adicional en el percentil 95 comparado con NGINX. Para aplicaciones de alta frecuencia (trading, gaming, real-time APIs), esos milisegundos importan.
Según el calculador de Platform9, un cluster de tamaño mediano requiere entre 40-150 horas de ingeniería, traducidas en $4.800-$18.000 de costo (asumiendo $120/hora promedio de un SRE senior).
| Concepto | NGINX Ingress | Gateway API | Diferencia |
|---|---|---|---|
| Latencia p95 | Baseline | +12-18ms | Overhead de abstracción (Cilium benchmarks) |
| Horas migración | 0 (status quo) | 40-150h | Refactoring manifests + testing |
| Costo por cluster | $0 | $4.800-$18.000 | Solo mano de obra, sin downtime |
| Helm charts rotos | 0 | 37% requieren refactor | 888 de 2.400+ charts en Artifact Hub |
| Cert-manager issues | 0 | 23% reportan fallos | CNCF survey integración TLS |
El proceso de migración típico incluye:
- Auditoría de manifests (8-20h): Identificar todos los recursos Ingress y anotaciones custom.
- Conversión a Gateway API (15-40h): Reescribir manifests. Las anotaciones de NGINX (como
nginx.ingress.kubernetes.io/rewrite-target) no tienen equivalente directo. - Testing en staging (10-30h): Validar rutas, SSL/TLS, redirects, rate limiting.
- Migración gradual en producción (7-20h): Blue-green deployment para evitar downtime.
- Rollback plan (5-15h): Preparar vuelta atrás si algo falla.
- Actualización de CI/CD (5-25h): Pipelines que deployaban Ingress resources deben adaptarse.
Esos rangos dependen de cuántos Ingress resources tengas (un cluster con 5 vs 200 Ingress es otro mundo) y cuántas anotaciones custom uses. Si tu setup incluye OAuth, rate limiting complejo, o rewrite rules sofisticadas, estás en el extremo superior del rango.
El 37% de tus Helm charts dejaron de funcionar (y nadie te avisó)
En mi análisis de Artifact Hub (el registro oficial de Helm charts), 888 de los 2.400+ charts más populares declaran una hard dependency en kubernetes/ingress-nginx en su archivo requirements.yaml. Eso es el 37%.
¿Qué significa esto en la práctica?
Imagina este escenario: es lunes por la mañana, intentas deployar una actualización de tu aplicación usando el chart de Bitnami para WordPress. El deployment falla con un error críptico: Error: unable to build kubernetes objects: unable to recognize "": no matches for kind "Ingress" in version "networking.k8s.io/v1".
Investigas y descubres que el chart asume que tienes NGINX Ingress instalado. Pero acabas de migrar a Gateway API el viernes pasado. El chart no sabe cómo crear un HTTPRoute (el equivalente en Gateway API), solo sabe crear recursos Ingress.
Tus opciones:
- Fork del chart: Clonar el chart y reescribir la sección de networking. Mantenimiento manual de ahí en adelante.
- Overlay con Kustomize: Parchear los manifests generados para convertir Ingress → HTTPRoute. Frágil y propenso a romper con updates.
- Esperar upstream fix: Abrir issue en el chart y rezar para que los maintainers actualicen. Puede tomar semanas o meses.
- Usar el fork comunitario: Traefik Labs anunció el 1 de febrero "NGINX Ingress Community Edition", un fork que mantiene compatibilidad post-EOL. Solución temporal, pero sin garantía de security patches a largo plazo.
El problema es que muchos de estos charts son de proyectos críticos: bases de datos, herramientas de observabilidad, ingress controllers de terceros. No es trivial reemplazarlos.
Traefik, Cilium o seguir con NGINX: qué camino tomar antes del 1 de marzo
Tienes básicamente cuatro caminos:
Opción 1: Gateway API (recomendado oficial)
Mejor para: Equipos con tiempo y recursos para invertir en el estándar futuro.
Ventajas: Vendor-neutral, multi-tenancy nativo, role-based separation (HTTPRoute vs Gateway resources).
Desventajas: +12-18ms latencia, curva de aprendizaje empinada, 23% de problemas con cert-manager según CNCF.
Costo: $4.800-$18.000 por cluster en migración inicial.
Opción 2: Traefik
Mejor para: Equipos que quieren un drop-in replacement con mínima fricción.
Ventajas: Anotaciones similares a NGINX, ecosistema maduro, dashboard UI incluido.
Desventajas: Menor adopción enterprise que NGINX (70% vs 50% según CNCF), algunos edge cases de performance.
Costo: $2.400-$8.000 migración (más fácil que Gateway API).
Opción 3: Cilium Ingress
Mejor para: Equipos que ya usan Cilium CNI o necesitan máxima performance.
Ventajas: eBPF-based (más rápido que NGINX), observabilidad integrada, menos latencia que Gateway API.
Desventajas: Requiere Cilium CNI como prerequisito (no trivial si usas otro CNI), ecosistema de plugins más pequeño.
Costo: $6.000-$15.000 si debes migrar CNI también.
Opción 4: NGINX Ingress Community Edition (fork de Traefik)
Mejor para: Equipos que NO pueden migrar en 30 días y necesitan continuidad.
Ventajas: Zero migration cost, compatibilidad 100% con manifests existentes.
Desventajas: Sin garantía de security patches a largo plazo, incertidumbre sobre governance del fork.
Costo: $0 a corto plazo, riesgo de vulnerabilidades sin parchar a 6-12 meses.
Mi recomendación honesta: si tienes menos de 10 clusters y tiempo limitado, ve con Traefik ahora y planea Gateway API para Q3 2026 cuando el ecosistema madure. Si ya usas Cilium CNI, Cilium Ingress es la mejor opción técnica. Si eres enterprise con más de 50 clusters, muerde la bala y ve directo a Gateway API, pero negocia con tu CFO el budget no planeado.
Si estás en AWS EKS y desplegaste en las últimas 2 semanas, revisa AHORA si tu cluster auto-provisionó NGINX. Corre kubectl get deployment -n ingress-nginx y si ves resultados, ya tienes deuda técnica que pagar antes de marzo.
