Ingress o Gateway API: no es cambiar YAML, es cambiar responsabilidades

Ingress hizo sencillo exponer HTTP; Gateway API separa infraestructura y aplicaciones cuando una sola puerta ya no basta.

Durante años, exponer una aplicacion en Kubernetes se explicaba con una palabra: Ingress. Un objeto, unas reglas de host y ruta, un controlador detras y el trafico empezaba a entrar. Para un equipo pequeno esa sencillez sigue teniendo valor. El problema llega cuando la puerta deja de pertenecer a una sola aplicacion y pasa a ser parte de una plataforma.

En un cluster compartido, alguien opera los balanceadores, certificados, politicas y direcciones publicas. Otros equipos solo deberian declarar que rutas necesita su servicio. Con Ingress, esa separacion suele terminar repartida entre anotaciones especificas del controlador, convenciones internas y permisos dificiles de razonar.

Gateway API nace alrededor de esa frontera. No vende otra palabra para el mismo YAML: define recursos distintos para la infraestructura que publica una puerta y para las rutas que las aplicaciones pueden adjuntar a ella. Esa separacion hace visible una conversacion que ya existia en cualquier plataforma madura.

Cuando no necesitas moverte

Si tienes pocas aplicaciones HTTP, un solo equipo opera el cluster y tu controlador Ingress cubre bien las necesidades, la migracion no crea valor automaticamente. Un sistema aburrido que se entiende es mejor que una arquitectura moderna que nadie sabe depurar.

Gateway API empieza a merecer atencion cuando aparecen multiples equipos, varios protocolos, ownership separado o la necesidad de estandarizar capacidades que antes vivian como anotaciones. Tambien es una buena lectura para quien quiera entender por que una plataforma no debe obligar a cada aplicacion a conocer los detalles del balanceador que hay debajo.

Que miraria en un laboratorio

La prueba interesante no es servir una pagina de bienvenida. Es crear un Gateway administrado por una capa de plataforma y adjuntar rutas desde namespaces de aplicaciones, observando que permisos permiten o rechazan esa relacion. En ese momento se ve la diferencia: no estas probando solo trafico; estas probando ownership.

Comparar Ingress y Gateway API con calma evita una discusion pobre de “viejo contra nuevo”. La pregunta real es cuanto ha crecido tu problema y cuantas responsabilidades necesitas distinguir para operarlo sin miedo.

Fuente: el proyecto mantiene conceptos, especificacion y guias de adopcion en la documentacion oficial de Kubernetes Gateway API.

Conversacion

Se el primero en comentar