Kubernetes Gateway API
Gateway API es el nuevo estándar para gestión de tráfico en Kubernetes. Reemplaza a NGINX Ingress con mejor diseño, más flexibilidad y soporte para L4/L7.
Hoy hablamos sobre Kubernetes Gateway API, el reemplazo para NGINX Ingress Controller.
NGINX Ingress Controller es un Ingress controller. Un ingress controller es un load balancer que se utiliza en los orquestadores de contenedores (como Kubernetes), permitiéndonos gestionar el tráfico externo hacia los contenedores de nuestro clúster. En resumen, es un reverse proxy en el que podemos configurar diferentes reglas para dirigir el tráfico de entrada hacia nuestros contenedores.
El pasado 11 de noviembre de 2025, el grupo de trabajo Kubernetes SIG Network y el comité Security Response anunciaron que el proyecto NGINX Ingress Controller no se mantendrá a partir de marzo de 2026. Su recomendación es migrar a Gateway API o a otro Ingress Controller (puedes consultar una lista aquí: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).
Kubernetes Gateway API
Es un proyecto oficial de Kubernetes para gestionar el tráfico de red en las capas L4 y L7. Proporciona un diseño genérico y basado en roles.
Capa L4: Su objetivo es garantizar la transferencia de datos de extremo a extremo entre dispositivos, gestionando la confiabilidad, el control de flujo y la multiplexación.
Capa L7: Es la capa de aplicación. Siendo la capa superior del modelo OSI, interactúa directamente con el software del usuario, proporcionando servicios para aplicaciones como el correo electrónico o la navegación web.
El proyecto lo mantiene el grupo de trabajo SIG-Network (Network Special Interest Group), siendo sus principales objetivos los de mejorar y proporcionar estándares a nivel de red (networking).
Nos permite configurar y gestionar el tráfico de red en todas las direcciones:
Norte / Sur: Tráfico desde el exterior hacia el clúster (y viceversa).
Este / Oeste: Tráfico entre contenedores dentro del clúster.
Es fácil confundir API Gateway y Gateway API, la primera es una herramienta que agrupa y unifica diferentes APIs en una única API. De esta manera es posible gestionar y configurar las diferentes APIs en un único punto. Algunos servicios como Azure API Management o Amazon API Gateway.
Gateway API es una interfaz definida utilizando recursos de Kubernetes y su diseño se ha basado en los siguientes principios:
Basada en roles
Portable
Expresiva
Extensible
El diseño orientado a roles (role-oriented) separa las responsabilidades entre diferentes personas para mejorar la usabilidad, flexibilidad y control en entornos de infraestructura compartida.
GatewayClass
Este es un recurso a nivel de clúster que define una plantilla para instanciar Gateways, cada GatewayClass utiliza un proveedor diferente (Traefik, Istio, Cilium, entre otros)
Nos permite desacoplar la implementación de la utilización, pudiendo definir diferentes GatewayClasses dependiendo de los requisitos de nuestra aplicación.
En definitiva, describe los posibles Gateways disponibles en el clúster para que puedan ser utilizados por el usuario.
Un ejemplo típico sería separar las aplicaciones internas de las aplicaciones externas, o utilizar diferentes implementaciones (como Traefik o Istio).
kind: GatewayClass
metadata:
name: internet
spec:
controllerName: “example.net/gateway-controller”
parametersRef:
group: example.net
kind: Config
name: internet-gateway-config
---
apiVersion: example.net/v1alpha1
kind: Config
metadata:
name: internet-gateway-config
spec:
ip-address-pool: internet-vipsGateway
Nos permite definir cómo vamos a gestionar el tráfico de nuestra red: endpoints, hostnames, filtrados, etc.
Cuando un usuario crea un Gateway en Kubernetes, la capa de infraestructura puede crear recursos de load balancer a través del controlador asociado al GatewayClass.
Un Gateway se define a partir de los siguientes elementos:
GatewayClassName: Define el nombre del GatewayClass a ser utilizado.
Listener: Define los nombres de host (hostnames), puertos (ports), protocolos (ej. http o https), TLS (Transport Layer Security), y rutas que pueden ser utilizadas.
Address: Define las direcciones IP requeridas para el Gateway.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gateway
spec:
gatewayClassName: internet
listeners:
- name: default
hostname: “*.my-custom-domain.com”
port: 80
protocol: HTTPDependiendo del GatewayClass desplegado, la creación de un Gateway puede implicar la ejecución de algunas acciones para crear diferentes elementos en la infraestructura para poder recibir y redirigir el tráfico de red:
Uso de las APIs del proveedor cloud para crear un nuevo Load Balancer.
Actualizar la configuración de un Load Balancer existente.
Configurar el SDN (Software-Defined Networking) para actualizar la configuración existente.
HTTPRoute
Define la ruta de una petición HTTP desde un Gateway listener hasta un elemento del clúster (API Object, p. ej., a un Service - SVC).
Se define a partir de los siguientes elementos:
ParentRefs: Define qué Gateways van a estar asociados a este elemento. Se utiliza el Namespace de donde se ha creado el Gateway y el nombre del Gateway.
Hostnames (opcional): Define el nombre o nombres del host (no se pueden utilizar IPs, se pueden utilizar comodines como *) que serán enrutados en la definición cuando el valor de la cabecera Host de la petición coincida.
Rules: Permite definir una lista de reglas para enrutar la petición hacia los servicios definidos cuando esta coincida con la expresión definida:
Matches: Define las condiciones que debe cumplir la petición para poder hacer uso del HTTPRoute; el match se hará efectivo si solo una de las condiciones se cumple.
Filters: Se utiliza para añadir información adicional (p. ej., headers).
BackendRefs (opcional): Si no se define, la respuesta a la petición recibirá un código de error 404. Permite definir el objeto de Kubernetes que recibirá la petición (p. ej., Service).
Timeouts (opcional / experimental a la hora de escribir el artículo): En caso de no especificarse, los timeouts serán los definidos en la implementación. Permite definir dos timeouts:
Request: El tiempo máximo que tiene el Gateway API para enviar una respuesta al cliente que ha iniciado la petición.
BackendRequest: Es el tiempo máximo que tiene el Gateway para enviar la petición al backend.
Name (opcional): Permite especificar un nombre a la regla definida.
sessionPersistence (opcional / experimental a la hora de escribir el artículo): Define y configurar el tipo de persistencia a utilizar.
retry (opcional / experimental a la hora de escribir el artículo): Define la política de reintentos para la petición.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: bar-route
spec:
parentRefs:
- name: gateway
hostnames:
- “bar.example.com”
rules:
- matches:
- headers:
- type: Exact
name: env
value: canary
backendRefs:
- name: bar-svc-canary
port: 8080
- backendRefs:
- name: bar-svc
port: 8080
GRPCRoute
Al igual que HTTPRoute, GRPCRoute permite definir la ruta de una petición gRPC desde un Gateway listener hasta un elemento del clúster (API Object, p. ej., a un Service - SVC).
Las implementaciones que soporten gRPC fuerzan que los dominios entre HTTPRoutes y gRPCRoutes sean únicos.
Se recomienda utilizar hostnames diferentes para el trafico HTTP y gRPC. En el caso que sea necesario utilizar el mismo hostname, se deberá realizar el tipo HTTPRoute para gestionar ambos.
Se define a partir de los siguientes elementos:
ParentRefs: Define qué Gateways van a estar asociados a este elemento. Se utiliza el Namespace de donde se ha creado el Gateway y el nombre del Gateway.
Hostnames (opcional): Define el nombre o nombres del host (no se pueden utilizar IPs, se pueden utilizar comodines como *) que serán enrutados en la definición cuando el valor de la cabecera Host de la petición coincida.
Rules: Permite definir una lista de reglas para enrutar la petición hacia los servicios definidos cuando esta coincida con la expresión definida:
Matches: Define las condiciones que debe cumplir la petición para poder hacer uso del HTTPRoute; el match se hará efectivo si solo una de las condiciones se cumple.
Filters: Se utiliza para añadir información adicional (p. ej., headers).
BackendRefs (opcional): Si no se define, la respuesta a la petición recibirá un código de error 404. Permite definir el objeto de Kubernetes que recibirá la petición (p. ej., Service).
Timeouts (opcional / experimental a la hora de escribir el artículo): En caso de no especificarse, los timeouts serán los definidos en la implementación. Permite definir dos timeouts:
Request: El tiempo máximo que tiene el Gateway API para enviar una respuesta al cliente que ha iniciado la petición.
BackendRequest: Es el tiempo máximo que tiene el Gateway para enviar la petición al backend.
Name (opcional / experimental a la hora de escribir el artículo): Permite especificar un nombre a la regla definida.
sessionPersistence (opcional / experimental a la hora de escribir el artículo): Define y configurar el tipo de persistencia a utilizar.
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: foo-route
spec:
parentRefs:
- name: gateway
hostnames:
- “foo.example.com”
rules:
- matches:
- method:
service: com.example
method: “*”
backendRefs:
- name: foo-svc
port: 50051Policies
BackendTLSPolicy
Nos permite cifrar el tráfico entre el Gateway y el backend al cual se redirige el tráfico.
BackendTrafficPolicy
Experimental a la hora de escribir el artículo
Esta extensión nos permite configurar la política de reintentos de una conexión en caso de que la petición falle.
Para poder hacer uso de ella necesitamos especificar:
TargetRefs: Permite definir los objetos de Kubernetes que recibirá la petición (p. ej., Service).
RetryConstraint: Permite configurar una política de reintentos Budget retries, la cual permite no saturar el backend cuando este no puede atender todas las peticiones.
SessionPersistence: Permite configurar la persistencia de la sesión para el target o targets definidos. Los posibles valores a configurar son Permanent y Persistence (valor por defecto).
Implementaciones
Gateway API es un estándar creado por el grupo de trabajo SIG-Network (Network Special Interest Group). A partir de este estándar, diferentes proyectos open source y empresas han desarrollado sus implementaciones, gracias al estándar y la compatibilidad podríamos cambiar de proveedor sin necesidad de cambiar ninguno de los recursos creados previamente.
Antes de elegir una implementación es necesario entender el nivel de conformidad para elegir el que mejor se adapte a nuestros requerimientos. Existen 3 niveles:
Conformant: Han superado pruebas completas para al menos una combinación de Ruta y Perfil (ej. Mesh + HTTPRoute o Gateway + TLSRoute), incluyendo extensiones, en una de las dos versiones más nuevas. Deben cubrir al menos un perfil y ruta con todas las pruebas principales.
Partially Conformant: Implementaciones que se están desarrollando y que al menos han obtenido un informe de conformidad positivo en una de las últimas tres versiones.
Stale: Implementaciones que posiblemente no se estén actualizando, se eliminarán en la siguiente versión a no ser que envíen un informe para poder obtener un nivel superior de conformidad.
Puedes consultar una lista de las mismas en el siguiente enlace: https://gateway-api.sigs.k8s.io/implementations/#implementations_1
Comparación NGINX Ingress Controller vs Gateway API
A continuación, puedes ver una tabla comparativa entre el NGINX Ingress Controller (basado en la API Ingress de Kubernetes) y la Gateway API. Esta comparación se basa en aspectos clave como características, ventajas, limitaciones y evolución.
En la tabla puedes comprobar por qué Gateway API representa una evolución más flexible y portable para la gestión de tráfico en clústeres Kubernetes.
Conclusión / Resumen
Gateway API representa la evolución de la gestión de tráfico externo en Kubernetes. Mientras que Ingress NGINX cumplió su propósito durante años, sus limitaciones en extensibilidad y su diseño lo han convertido en una solución obsoleta para las necesidades actuales de las arquitecturas cloud-native, además de que su mantenimiento terminará el próximo mes de marzo de 2026.
La arquitectura basada en roles proporciona una separación clara de responsabilidades entre administradores de infraestructura y desarrolladores. Además, su diseño expresivo y extensible permite configuraciones avanzadas de L4 y L7 que antes requerían anotaciones personalizadas o soluciones alternativas.
¿Quieres ver un ejemplo de funcionamiento con Gateway API? Escribe en comentarios y estaré encantado de prepararlo.
Referencias
https://gateway-api.sigs.k8s.io/
https://kubernetes.io/docs/concepts/services-networking/gateway/