Skip to main content
HashnodeBlog de CloudAcademyBlog de CloudAcademy

Command Palette

Search for a command to run...

Adiós Ingress NGINX en EKS: Guía Práctica de Migración a Kubernetes Gateway API

Updated
•7 min read
Adiós Ingress NGINX en EKS: Guía Práctica de Migración a Kubernetes Gateway API
M
Matias Martinez

Adiós Ingress NGINX en EKS: Guía Práctica de Migración a Kubernetes Gateway API

Palabras clave SEO: Ingress NGINX retirement, Kubernetes Gateway API, EKS migración, AWS Load Balancer Controller, HTTPRoute, ingress2gateway

El fin de una era: Ingress NGINX se retira en marzo 2026

Si tenés Kubernetes en producción, probablemente usás Ingress NGINX. Y si es así, tenés que leer esto.

La comunidad de Kubernetes anunció el retiro oficial del controlador Ingress NGINX en marzo de 2026. Esto significa no más releases, no más bug fixes, no más parches de seguridad. El proyecto está en modo de solo mantenimiento mínimo y se considera EOL (End of Life).

No es un cambio menor. Ingress NGINX es uno de los controladores de ingress más usados del ecosistema, especialmente en Amazon EKS. Pero la buena noticia es que su sucesor — Kubernetes Gateway API — es significativamente mejor, y AWS ya tiene soporte GA a través del AWS Load Balancer Controller.

En este artículo te explico por qué Gateway API es superior, y cómo migrar paso a paso en tu clúster EKS.

¿Por qué Gateway API es mejor que Ingress?

La API de Ingress original fue diseñada para casos simples: enrutar tráfico HTTP/HTTPS. Con el tiempo, los equipos empezaron a meter toda la configuración en anotaciones, resultando en YAML como este:

# La forma vieja y dolorosa
annotations:
  alb.ingress.kubernetes.io/target-group-attributes: |
    deregistration_delay.timeout_seconds=30,
    stickiness.enabled=true,
    stickiness.type=lb_cookie
  alb.ingress.kubernetes.io/healthcheck-path: /health
  alb.ingress.kubernetes.io/scheme: internet-facing

Sin validación, sin IDE support, errores que explotan en runtime. Un desastre.

Gateway API resuelve esto con tres mejoras clave:

1. Modelo orientado a roles

Gateway API separa responsabilidades claramente:

Rol Recurso Quién lo gestiona
Proveedor de infraestructura GatewayClass Equipo de plataforma / AWS
Operador del clúster Gateway DevOps / SRE
Desarrollador de la app HTTPRoute Dev teams

Esto hace que el acceso sea más seguro y el modelo multi-tenant más manejable.

2. CRDs tipadas con validación

En vez de anotaciones como strings, usás CRDs con schema validation:

# La forma nueva con Gateway API
apiVersion: gateway.k8s.aws/v1beta1
kind: TargetGroupConfiguration
spec:
  targetGroupAttributes:
    - key: deregistration_delay.timeout_seconds
      value: "30"
    - key: stickiness.enabled
      value: "true"

Los errores se detectan en kubectl apply, no en producción.

3. Soporte para más protocolos

Ingress solo soporta HTTP/HTTPS. Gateway API soporta también:

  • TCPRoute — para bases de datos, gRPC, etc.
  • TLSRoute — terminación TLS a nivel TCP
  • UDPRoute — para casos de uso como DNS o gaming

AWS Load Balancer Controller: soporte GA para Gateway API

En marzo 2026, AWS anunció el soporte en disponibilidad general (GA) para Kubernetes Gateway API en el AWS Load Balancer Controller. Esto cubre:

  • ALB (Application Load Balancer) → tráfico HTTP/HTTPS layer 7
  • NLB (Network Load Balancer) → tráfico TCP/UDP layer 4
  • VPC Lattice → tráfico east-west entre servicios

Es la solución nativa recomendada para EKS.

Guía de migración paso a paso

Prerrequisitos

  • Clúster EKS con Kubernetes 1.29 o posterior
  • kubectl configurado
  • AWS Load Balancer Controller v2.13.0+
  • Permisos IAM apropiados para provisionar ALBs/NLBs

Paso 1: Verificar si usás Ingress NGINX

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

Si devuelve resultados, tenés trabajo por hacer.

Paso 2: Instalar las CRDs de Gateway API

kubectl apply -k \
  "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.1.0"

Verificá que se instalaron:

kubectl get crd | grep gateway

Deberías ver: gateways.gateway.networking.k8s.io, httproutes.gateway.networking.k8s.io, etc.

Paso 3: Crear el GatewayClass

El GatewayClass le dice a Kubernetes qué controlador va a gestionar los Gateways:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: aws-alb
spec:
  controllerName: ingress.k8s.aws/alb

kubectl apply -f gatewayclass.yaml

Paso 4: Crear el Gateway

El Gateway representa el balanceador de carga real (el ALB en AWS):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
  annotations:
    alb.ingress.k8s.aws/scheme: internet-facing
    alb.ingress.k8s.aws/target-type: ip
spec:
  gatewayClassName: aws-alb
  listeners:
  - name: http
    port: 80
    protocol: HTTP
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: my-tls-cert

Verificá que el ALB se provisione:

kubectl get gateway my-gateway -n default
# ADDRESS debería mostrar el DNS del ALB cuando esté listo

Paso 5: Migrar los Ingress a HTTPRoutes

Antes tenías un Ingress así:

# Ingress NGINX - la forma vieja
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.midominio.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 3000

El equivalente en Gateway API:

# HTTPRoute - la forma nueva
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "app.midominio.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /web
    backendRefs:
    - name: web-service
      port: 3000

Paso 6: Usar ingress2gateway para automatizar la conversión

Para clústeres con muchos Ingress, usá la herramienta oficial:

# Instalar ingress2gateway
go install sigs.k8s.io/ingress2gateway@latest

# Convertir todos los Ingress NGINX del namespace default
ingress2gateway print \
  --providers=ingress-nginx \
  --namespace=default

Revisá la salida, ajustá lo necesario y aplicá.

Paso 7: Estrategia de migración sin downtime

No apagues Ingress NGINX de golpe. La estrategia recomendada es correr ambos en paralelo:

  1. Desplegá el Gateway y los HTTPRoutes
  2. El ALB nuevo tendrá su propio DNS
  3. Testeá en staging apuntando al DNS nuevo
  4. En producción, hacé el cambio de DNS con TTL bajo (60s)
  5. Monitoreá por 24-48hs
  6. Recién entonces desinstalá Ingress NGINX
# Verificar estado de HTTPRoutes
kubectl get httproute -A

# Ver si están Accepted y Programmed
kubectl describe httproute my-app-route

Consideraciones adicionales

cert-manager

Si usás cert-manager para TLS, tiene soporte nativo para Gateway API desde v1.12. Solo actualizá tu Issuer o ClusterIssuer y usá certificateRefs en el listener del Gateway.

Anotaciones sin equivalente directo

Algunas anotaciones muy específicas de Ingress NGINX (como nginx.ingress.kubernetes.io/lua-resty-waf) no tienen equivalente en Gateway API. En esos casos, necesitás evaluar si el AWS Load Balancer Controller (con WAF nativo via AWS WAF) o Envoy Gateway cubren el caso de uso.

Traffic splitting para canary deployments

Una de las features más potentes de Gateway API que Ingress no soporta nativamente:

rules:
- backendRefs:
  - name: my-app-stable
    port: 80
    weight: 90
  - name: my-app-canary
    port: 80
    weight: 10

Con Ingress necesitabas anotaciones específicas de cada controlador. Con Gateway API es estándar.

Resumen

Feature Ingress NGINX Gateway API (AWS LBC)
Estado ⚠️ EOL marzo 2026 ✅ GA, activamente desarrollado
Validación de config ❌ Strings en anotaciones ✅ CRDs tipadas
Modelo de roles ❌ Todo mezclado ✅ Infraestructura / Operador / Dev
Traffic splitting ⚠️ Anotaciones propietarias ✅ Nativo en HTTPRoute
Soporte TCP/UDP ❌ Solo HTTP/HTTPS ✅ TCPRoute, UDPRoute
Integración AWS ⚠️ Vía anotaciones ✅ Nativa con ALB/NLB/VPC Lattice

La migración no es opcional, y tampoco tiene que ser traumática. Con la herramienta ingress2gateway y una estrategia de migración progresiva, podés hacerlo con zero downtime.

¿Tenés preguntas sobre la migración en tu stack específico? Dejame tu caso en los comentarios.

Tags: Kubernetes, EKS, AWS, DevOps, Gateway API, Ingress, Migración

197 views

More from this blog

B

Blog de CloudAcademy

80 posts