Jorge Turbica / blog · Blog ← Todos los artículos EN · Read in English
Tecnologías

EKS Auto Mode ya sirve la Gateway API sin instalar controlador, pero sin timeouts

EKS Auto Mode crea ALB y NLB desde Gateway y HTTPRoute sin controlador que mantener. Cómo activarlo y qué partes del estándar no soporta.

Desde el 28 de octubre de 2026, un clúster de EKS en Auto Mode entiende Gateway y HTTPRoute sin que instales ningún controlador: declaras la ruta y AWS levanta un Application Load Balancer para L7 o un Network Load Balancer para L4. Es la misma promesa que GKE ofrece desde hace tiempo con su controlador alojado por Google, y llega con una lista de huecos que hay que leer antes de migrar.

Qué cambia

Hasta ahora, en EKS Auto Mode la entrada de tráfico se resolvía con Ingress (ALB) o con Service de tipo LoadBalancer (NLB). Con la Gateway API, Auto Mode trae dos controladores propios que se eligen en la GatewayClass:

  • eks.amazonaws.com/gateway-alb: ALB para HTTPRoute y GRPCRoute.
  • eks.amazonaws.com/gateway-nlb: NLB para TCPRoute y UDPRoute.

Según el anuncio, el soporte incluye enrutado HTTP y gRPC, rutas entre namespaces, reparto de tráfico por pesos, enrutado por cabeceras y descubrimiento de certificados en AWS Certificate Manager. No tiene coste adicional: pagas los balanceadores que se crean, como siempre. Está en todas las regiones donde existe EKS Auto Mode.

Lo más interesante para operar es el reparto de papeles que propone el modelo: plataforma define la GatewayClass, quien opera el clúster define el Gateway (listeners, puertos, TLS) y cada equipo de aplicación publica sus HTTPRoute en su namespace. Con Ingress todo eso acababa mezclado en anotaciones.

Cómo activarlo

La Gateway API no viene encendida: se activa en la configuración de red del clúster con el campo gatewayApi.crds.managed, que además decide quién es dueño de los CRD de la Gateway API, que son globales al clúster:

  • true: AWS instala y actualiza los CRD (en la v1). Si ya tienes CRD en una versión anterior, la operación se rechaza sin tocar nada.
  • false: los CRD siguen siendo tuyos. Es la opción si ya usas Envoy Gateway, Istio u otro controlador.
bash
aws eks update-cluster-config \
  --name $CLUSTER_NAME \
  --kubernetes-network-config '{"elasticLoadBalancing":{"enabled":true,"gatewayApi":{"crds":{"managed":true}}}}'

Después, una GatewayClass que apunte al controlador de ALB, un Gateway con su listener y la ruta hacia tu Service:

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eks-auto-alb
spec:
  controllerName: eks.amazonaws.com/gateway-alb
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: eks-auto-alb
  listeners:
    - name: http
      protocol: HTTP
      port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
    - name: my-gateway
      sectionName: http
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: service-2048
          port: 80

La documentación recomienda crear la GatewayClass antes que el resto, porque tarda un poco en estar lista. El balanceador puede tardar unos minutos; kubectl wait --for=condition=Programmed gateway/my-gateway te dice cuándo está listo. Las subredes tienen que llevar las etiquetas de pública o privada que exige Auto Mode (eksctl ya las pone).

Lo que no hace el ALB

La trampa está en el detalle de la especificación. Auto Mode usa la implementación del AWS Load Balancer Controller y su tabla de compatibilidad deja fuera varias piezas estándar:

  • TLS en el listener: certificateRefs no está soportado. El certificado se configura con el recurso propio LoadBalancerConfiguration (gateway.k8s.aws/v1), no con un Secret como en otras implementaciones.
  • Timeouts y reintentos de HTTPRoute, RequestMirror, ResponseHeaderModifier y CORS: no soportados.
  • Sesiones persistentes y autenticación externa: solo con ListenerRuleConfiguration, que también es la vía para Cognito u OIDC.
  • Backend TLS hacia los pods: no soportado.
  • Redirecciones: un RequestRedirect que solo cambia la ruta con ReplacePrefixMatch provoca un bucle; hay que usar ReplaceFullPath. Y si una regla de redirección es inválida, el controlador deja de crear las reglas siguientes de esa HTTPRoute.

Si vienes de Envoy Gateway o Istio con timeouts y reintentos en las rutas, esos manifiestos no se trasladan tal cual: o los mueves a la aplicación, o mantienes ese controlador. Los dos conviven en el mismo clúster porque cada uno tiene su controllerName.

Frente a GKE

EKS Auto ModeGKE
ControladorGestionado por AWS, se activa por clústerAlojado por Google, activado por defecto (un clúster)
BalanceadoresALB (L7) y NLB (L4)Clases gke-l7-*, globales, regionales e internas
Coste del controladorIncluido; pagas los balanceadoresIncluido en el precio de Standard y Autopilot
CRDGestionados por AWS u opcionalmente por tiLa documentación no lo detalla

La diferencia práctica es que EKS ya no obliga a instalar y actualizar el AWS Load Balancer Controller para tener Gateway API en Auto Mode, que era el trabajo que GKE ahorraba desde el principio. Los Ingress y Service de tipo LoadBalancer que ya tienes siguen funcionando, así que la adopción puede ser ruta a ruta: empieza por un servicio nuevo, valida TLS con LoadBalancerConfiguration y compara el ALB que crea con el que tenías.

Fuentes

Jorge Turbica

Software Engineer y SRE. Escribo sobre los retos reales que me encuentro en producción.

Ver portfolio ↗