Kubernetes 1.32: el fin de los Ingress legacy y el salto a Gateway API

Si todavía estás definiendo tus rutas HTTP con un Ingress clásico y un controller de la vieja escuela, Kubernetes 1.32 trae una señal que no podés ignorar: el proyecto está empujando fuerte para que Gateway API sea el estándar de facto para el tráfico entrante. No es un cambio cosmético ni una feature más: es una reestructuración profunda de cómo se modela el tráfico de red en un clúster, y las features nuevas ya no llegan a la API vieja.

Gateway API es la evolución oficial del proyecto Kubernetes para el ruteo de tráfico (reemplaza a Ingress v1). La mantiene la Gateway API subproject del SIG Network, con soporte de los principales vendors de la industria. Su objetivo es corregir las limitaciones de Ingress: expresar múltiples protocolos, manejar peso entre backends, hacer canary y blue/green sin parches raros, y separar la configuración de la infraestructura (el Gateway) de la configuración de la aplicación (el HTTPRoute). Es la API que deberías usar para cualquier implementación nueva que toque el tráfico de tu clúster.

¿Qué cambió exactamente en Kubernetes 1.32 respecto a Ingress?

En Kubernetes 1.32, la API de Ingress (y su hermana IngressClass) pasó oficialmente a la fase de legacy: ya no recibe features nuevas y el proyecto concentra todo el desarrollo en Gateway API. La versión networking.k8s.io/v1 de Ingress sigue funcionando y no hay fecha de eliminación, pero el mensaje es claro: si arrancás un proyecto hoy con Ingress, estás arrancando con una tecnología congelada.

Los números de adopción lo confirman: la encuesta anual de la comunidad mostró que Gateway API pasó de ser una curiosidad a la opción recomendada por la propia documentación oficial de Kubernetes para exponer servicios. Los vendors de controllers (NGINX, Traefik, Envoy, HAProxy, y también los de cloud) ya implementan el HTTPRoute de Gateway API de forma estable. El directorio de implementaciones del proyecto Gateway API lista soporte GA o beta para la mayoría de los controllers grandes, y el soporte para Ingress legacy se mantiene solo por compatibilidad.

¿Por qué Gateway API reemplaza a Ingress?

Porque Gateway API resuelve problemas que Ingress no puede. El modelo de Ingress (un recurso por host con reglas de path) se queda corto en producción real. Con Ingress necesitás anotaciones propietarias para todo lo que no sea ruteo básico: canary, split de tráfico, headers custom, timeouts, websockets. Cada controller implementa esas anotaciones a su manera, lo que te ata al vendor y hace la migración un dolor. Gateway API estandariza esas capacidades como recursos de primera clase:

• Separación de roles: GatewayClass, Gateway y HTTPRoute. El equipo de plataforma define la infraestructura (listeners, TLS) y el equipo de aplicación define las rutas. Se acabó el "eyectá el YAML de Ingress al cluster y rezá".
• Ruteo avanzado por API, no por anotación. Pesos entre backends, matching por headers, por método HTTP y por query params son recursos declarativos estándar.
• Multi-protocolo. Gateway API no solo se limita a HTTP/HTTPS; soporta TCP, UDP, TLS y gRPC de forma explícita, mientras que Ingress es HTTP-centric.
• Portabilidad real. Un HTTPRoute que escribís hoy corre igual en un controller NGINX que en un Envoy o en la implementación de tu proveedor cloud, sin anotaciones mágicas.
• Extensibilidad controlada. Para casos exóticos, Gateway API ofrece mecanismos de extensión (policies y filters) definidos, en vez del "todo por anotación" de Ingress.

¿Qué implica esto para un developer o un proyecto en producción?

Para el día a día, el impacto se siente en dos frentes: la forma en que diseñás el acceso a tus servicios y el riesgo de quedarte atrás. Si estás por exponer una API nueva o un microservicio, la decisión hoy es Gateway API. No es una apuesta: es la dirección oficial y la de todos los vendors. En un proyecto en producción con Ingress funcionando, la urgencia no es migrar todo ya, pero sí planificar la transición y arrancar con los servicios nuevos.

Un punto concreto a favor de Gateway API: el canary testing. Con Ingress, el canary se hace con anotaciones específicas del controller (por ejemplo, nginx.ingress.kubernetes.io/canary-weight). Con Gateway API, definís dos HTTPRoute y seteás un peso con backendRef.weight. Es declarativo, portable y testeable. Para un equipo que quiere hacer deploy continuo sin feature flags mágicos, es un golazo.

¿Cómo migro de Ingress a Gateway API hoy?

La migración no es un kubectl apply de un archivo, pero tampoco es una remodelación total. El path típico tiene pasos claros y se puede encarar de a poco. La clave está en que HTTPRoute y Ingress son recursos compatibles en un mismo clúster: podés tener servicios viejos con Ingress y servicios nuevos con Gateway+HTTPRoute conviviendo. La transición es incremental y sin downtime obligatorio.

• Verificá si tu controller soporta Gateway API. Andá a la documentación de tu controller (NGINX Ingress Controller, Traefik, Envoy Gateway, HAProxy Ingress, etc.) y buscá la guía de migración. Si tu controller es de la vieja generación, capaz que es hora de evaluar un controller más nuevo como Envoy Gateway, que tiene a Gateway API como ciudadano de primera clase.
• Modelá la infraestructura con Gateway. El primer paso es definir un Gateway que escuche en el puerto 80/443 y maneje el TLS. Este recurso representa el punto de entrada (el load balancer o el proxy), y lo define, en general, el equipo de plataforma.
• Reemplazá cada Ingress por un HTTPRoute. El mapeo conceptual es directo: el host del Ingress se vuelve hostname en el spec.hostnames del HTTPRoute; los paths del Ingress se vuelven reglas de matches; y los backendRefs referencian tu Service, con su port correspondiente. Los tls secrets se configuran en el Gateway.
• Migrá las anotaciones a policy. Las features como rate limiting, retries o timeouts se expresan como recursos Policy (ej: HTTPRouteTimeout, HTTPRouteRetry). Es más verboso al principio, pero es explícito y no depende del proveedor.
• Testeá y rolback. Como conviven ambas APIs, podés crear el HTTPRoute y apuntar una parte del tráfico (o un subdominio) para validar, antes de borrar el Ingress.

¿Cuándo me conviene esperar y cuándo migrar ya?

Si tu clúster actual funciona perfecto con Ingress y no necesitás features avanzadas, no hay una bomba de tiempo. La API de Ingress no se va a romper de repente. Pero el criterio práctico es otro: esperar es innecesario, porque la curva de aprendizaje de Gateway API es corta y el beneficio de portabilidad y features es inmediato. Empezá por el servicio menos crítico, o el que estés por crear, y andá migrando de a poco.

Hay un caso donde migrar ya es decisivo: si necesitás features que Ingress no da (canary por peso, ruteo por headers, gRPC, TCP/UDP), y estás usando anotaciones propietarias para conseguirlas. Ahí, Gateway API te saca del vendor lock-in y te da una solución estándar, documentada y que no va a requerir mantenimiento heroico para la próxima versión de tu controller.

Preguntas frecuentes sobre la migración a Gateway API

¿Ingress se va a eliminar de Kubernetes?

No hay fecha de eliminación oficial de la API networking.k8s.io/v1/Ingress en Kubernetes 1.32 ni en el roadmap público. El proyecto la mantiene en modo legacy: funciona, pero ya no se invierte en features nuevas. Todo el desarrollo del SIG Network está en Gateway API.

¿Gateway API reemplaza a mi Ingress Controller actual?

No exactamente. Gateway API es la API, no el implementador. Necesitás que tu controller soporte la API de Gateway. Los controllers modernos (como NGINX Ingress Controller, Traefik, Envoy Gateway y los de los principales proveedores) ya la soportan de forma estable. Si tu controller es viejo y no la soporta, evaluá migrar el controller a una versión actual.

¿Qué es un GatewayClass y en qué se diferencia de un IngressClass?

Un GatewayClass es el análogo del IngressClass: define el "tipo" de gateway y referencia al controller que lo implementa. La diferencia es que el GatewayClass permite expresar más detalles de configuración y, sobre todo, que define el comportamiento esperado para el Gateway que lo use. Es la capa de abstracción que separa el "qué quiero exponer" del "cómo lo expongo".

¿Puedo tener Ingress y Gateway API al mismo tiempo?

Sí. Las dos APIs viven bien en el mismo clúster y ambas pueden apuntar al mismo controller. Esto permite una migración incremental: servicios viejos con Ingress, nuevos con HTTPRoute. Hay que tener cuidado de no configurar rutas duplicadas para el mismo host, porque el comportamiento depende del controller y del orden de evaluación.

¿Cuál es la feature más útil de Gateway API para un team de plataforma?

La separación de responsabilidades: el equipo de plataforma define y controla el Gateway (y puede restringir qué equipos pueden crear uno), y los equipos de producto crean libremente sus HTTPRoute sin tocar la infraestructura. Es un modelo que escala en organizaciones con muchos servicios y varios equipos, porque habilita un flujo de API-driven con RBAC fino por tipo de recurso.

¿Qué puedo hacer hoy con esto?

Hoy mismo, tres pasos concretos. Primero, levantá la documentación de tu controller actual y verificá en qué estado está su soporte para Gateway API: la mayoría de los controllers mainstream (incluido el NGINX Ingress Controller) tiene guías de migración detalladas. Segundo, si tenés un service sin exponer o uno que quieras mejorar, armá un Gateway y un HTTPRoute de prueba en un namespace aislado; el YAML es directo, y te va a clarificar la cabeza respecto al modelo. Tercero, si dependés de anotaciones de Ingress para canary o ruteo avanzado, buscá la equivalencia en Gateway API y probala: la portabilidad que ganás es grande y la deuda técnica que evitás, mayor.

La ventana para seguir ignorando Gateway API se está cerrando. Kubernetes 1.32 dejó claro que Ingress es la API de ayer; Gateway API es la de hoy y la del futuro cercano. Aprenderla ahora, cuando tu proyecto no está urgido, es más barato que aprenderla en una migración de emergencia el año que viene.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting