Gateway API Kubernetes: La Evolución del Ingress 2026

Gateway API Kubernetes es la evolución moderna del Ingress, un estándar más potente, flexible y orientado a roles para gestionar el tráfico que entra en tu clúster. Diseñado por la comunidad para superar las limitaciones del Ingress clásico, permite dividir tráfico, enrutar por cabeceras y separar responsabilidades entre equipos de forma nativa. En esta guía instalarás Gateway API, desplegarás un Gateway y crearás rutas HTTP para exponer tus aplicaciones.

¿Qué es Gateway API Kubernetes y por qué sustituye al Ingress?

Gateway API Kubernetes es un conjunto de recursos oficiales que define cómo se gestiona el tráfico de entrada al clúster de forma más expresiva que el Ingress tradicional. El Ingress, pese a su éxito, se quedó corto: para funciones avanzadas obligaba a usar anotaciones específicas de cada controlador, lo que rompía la portabilidad. Gateway API resuelve ese problema con una especificación rica y estándar que todos los controladores implementan por igual.

Adoptar Gateway API en tu clúster aporta ventajas concretas frente al Ingress:

• Más expresivo: división de tráfico por pesos, enrutado por cabeceras y métodos, sin anotaciones propietarias.
• Orientado a roles: separa la responsabilidad de la infraestructura de la de las aplicaciones.
• Portable: la misma configuración funciona en distintos controladores compatibles.
• Extensible: soporta no solo HTTP, sino también TCP, TLS y otros protocolos.

Si vienes del Ingress clásico, como el que vimos en Ingress NGINX en Kubernetes, Gateway API Kubernetes es el siguiente paso natural: cubre los mismos casos y añade mucho más, con un diseño pensado para durar.

Los recursos de Gateway API Kubernetes

Entender los recursos de Gateway API Kubernetes es clave, porque su diseño orientado a roles es lo que lo distingue. Cada recurso lo gestiona típicamente una persona o equipo distinto, reflejando cómo funcionan las organizaciones reales.

• GatewayClass: define el tipo de controlador que implementa la puerta de enlace; lo gestiona el proveedor de infraestructura.
• Gateway: representa la puerta de entrada real (con sus puertos y protocolos); lo gestiona el operador del clúster.
• HTTPRoute: las reglas de enrutado que dirigen el tráfico a los servicios; las gestiona el equipo de la aplicación.

Esta separación es una de las grandes innovaciones de Gateway API Kubernetes. El operador del clúster define un Gateway seguro una sola vez, y los equipos de desarrollo adjuntan sus rutas sin necesidad de tocar la configuración de infraestructura ni pedir permisos elevados. Cada uno trabaja en su capa, con sus propios permisos, reduciendo fricciones y riesgos.

Requisitos previos

Para seguir esta guía de Gateway API Kubernetes necesitas un entorno básico operativo y elegir una implementación, ya que Gateway API es una especificación que distintos controladores implementan.

• Un clúster de Kubernetes 1.25 o superior.
• kubectl configurado con acceso de administrador.
• Una implementación compatible: NGINX Gateway Fabric, Envoy Gateway, Istio o Cilium, entre otras.
• Conexión a Internet para descargar los CRDs y el controlador.

Si ya usas una malla de servicios como la de Istio en Kubernetes, esta ya incluye una implementación de Gateway API, por lo que tendrías buena parte del camino hecho. En esta guía usaremos una implementación independiente para centrarnos en los conceptos.

Instalar Gateway API Kubernetes

El primer paso para usar Gateway API Kubernetes es instalar sus definiciones de recursos personalizados (CRDs), que no vienen de serie en el clúster. Los aplicamos directamente desde el repositorio oficial del proyecto.

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

Con los CRDs instalados, el clúster ya entiende los recursos de Gateway API, pero necesita un controlador que los haga funcionar. Instalamos una implementación; en este ejemplo, NGINX Gateway Fabric, una opción ligera y oficial del proyecto NGINX.

kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.5.0/deploy/default/deploy.yaml
kubectl get pods -n nginx-gateway

Verifica que el pod del controlador está en estado Running. En ese momento, tu clúster está listo para procesar recursos de Gateway API Kubernetes. Comprueba también que la GatewayClass correspondiente se ha registrado.

kubectl get gatewayclass

Deberías ver una GatewayClass con estado aceptado. Con esto, la base de tu Gateway API Kubernetes está desplegada y podemos crear la puerta de enlace.

Crear un Gateway y rutas HTTP

Ahora definimos el Gateway, que representa la puerta de entrada al clúster. Este recurso declara en qué puerto escucha y qué protocolo usa, y referencia la GatewayClass que instalamos.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: mi-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      port: 80
      protocol: HTTP

Con el Gateway creado, definimos una HTTPRoute que dirige el tráfico entrante hacia un servicio concreto de nuestra aplicación. Esta ruta enlaza con el Gateway y define las reglas de enrutado.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mi-app-route
spec:
  parentRefs:
    - name: mi-gateway
  hostnames:
    - "app.tudominio.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: mi-app
          port: 80

Aplica ambos recursos y el tráfico dirigido a tu dominio llegará a tu servicio a través de Gateway API Kubernetes. Comprueba el estado del Gateway para confirmar que tiene una dirección asignada.

kubectl get gateway mi-gateway
kubectl get httproute mi-app-route

Cuando el Gateway muestre una dirección y la ruta aparezca aceptada, tu aplicación estará expuesta. Acabas de sustituir el Ingress por una solución mucho más potente y clara.

División de tráfico con Gateway API Kubernetes

Una de las funciones más potentes de Gateway API Kubernetes, que el Ingress no ofrecía de forma estándar, es la división de tráfico por pesos. Esto permite despliegues canary de manera nativa: envías un porcentaje del tráfico a una versión nueva y el resto a la estable, todo en la propia HTTPRoute.

  rules:
    - backendRefs:
        - name: mi-app-v1
          port: 80
          weight: 90
        - name: mi-app-v2
          port: 80
          weight: 10

Con esta configuración, el 90 % del tráfico va a la versión estable y el 10 % a la nueva, sin herramientas externas ni anotaciones propietarias. Ajustar el reparto es cambiar los pesos y volver a aplicar. Esta capacidad, combinada con la observabilidad de tu clúster, hace de Gateway API Kubernetes una base excelente para estrategias de despliegue progresivo seguras y controladas.

Casos de uso reales de Gateway API Kubernetes

Para apreciar el valor práctico de esta especificación, veamos escenarios donde Gateway API Kubernetes resuelve problemas que el Ingress abordaba con dificultad o con parches propietarios:

• Plataformas multiequipo: el equipo de infraestructura define una puerta de enlace segura y varios equipos adjuntan sus rutas sin pisarse.
• Despliegues progresivos: lanzas versiones nuevas al 5 % de los usuarios y aumentas el porcentaje según las métricas.
• Enrutado avanzado: diriges el tráfico según cabeceras, método HTTP o parámetros, sin trucos específicos del controlador.
• Multiprotocolo: gestionas no solo HTTP, sino también TCP y TLS desde una misma especificación coherente.

En organizaciones grandes, la separación de responsabilidades que ofrece Gateway API Kubernetes es especialmente valiosa. Elimina los cuellos de botella en los que cada cambio de enrutado tenía que pasar por el equipo de infraestructura, permitiendo que los desarrolladores gestionen sus propias rutas de forma autónoma y segura. Esa agilidad, sin renunciar al control, es justo lo que las plataformas modernas necesitan para escalar sin fricciones.

Elegir una implementación de Gateway API Kubernetes

Como Gateway API es una especificación y no un producto concreto, una decisión importante es qué implementación usar, ya que cada una tiene sus fortalezas. Todas cumplen el estándar, así que tu configuración es en buena medida portable entre ellas, pero conviene conocer sus diferencias.

NGINX Gateway Fabric, que usamos en esta guía, es una opción sólida y familiar para quien ya conoce NGINX. Envoy Gateway destaca por su rendimiento y su enfoque cloud native. Si ya ejecutas una malla de servicios, tanto Istio como Cilium incluyen su propia implementación, lo que te evita desplegar un componente adicional y unifica la gestión del tráfico interno y externo. La buena noticia es que, gracias a la portabilidad del estándar, no quedas atrapado: puedes empezar con una implementación y migrar a otra más adelante con cambios mínimos, algo impensable con las anotaciones propietarias del Ingress. Esta libertad es, precisamente, una de las razones de más peso para adoptar Gateway API Kubernetes hoy, porque protege tu inversión frente a cambios futuros en el ecosistema. Tómate un tiempo para evaluar cuál encaja mejor con tu clúster antes de comprometerte a fondo.

Buenas prácticas y solución de problemas

• Elige bien la implementación: NGINX, Envoy, Istio o Cilium tienen matices; escoge según tus necesidades.
• Usa HTTPS siempre: configura listeners TLS y automatiza los certificados con Cert-Manager.
• Aprovecha los roles: separa Gateways gestionados por operadores de las rutas gestionadas por los equipos.
• Migra de forma gradual: convive con el Ingress durante la transición y migra servicio a servicio.

Si una ruta no funciona, revisa que el Gateway la acepta y que los nombres y puertos de los servicios son correctos; la mayoría de problemas de Gateway API Kubernetes están en esas referencias. Para gestionar los certificados, apóyate en Cert-Manager en Kubernetes. Encuentra más guías en nuestra categoría de tutoriales de Kubernetes.

Conclusión

Con Gateway API Kubernetes has adoptado el futuro de la gestión de tráfico en Kubernetes: un estándar potente, portable y orientado a roles que supera las limitaciones del Ingress. Hemos instalado los CRDs y un controlador, creado un Gateway y rutas HTTP, y explorado la división de tráfico nativa. A partir de aquí, añade listeners HTTPS, aprovecha el modelo de roles para separar responsabilidades y migra tus servicios de forma gradual hacia esta nueva base.

Como recorrido recomendado, empieza desplegando la especificación y una aplicación de prueba para ver el flujo completo, desde el Gateway hasta la HTTPRoute, sin la presión de un servicio en producción. Cuando te sientas cómodo, añade un listener HTTPS con certificados automáticos y experimenta con la división de tráfico para entender de primera mano lo sencillo que resulta un despliegue canary. El paso final es planificar la migración de tus Ingress existentes, uno a uno, conviviendo ambos sistemas durante la transición para no interrumpir el servicio. Recorrido con calma, este camino te sitúa en la vanguardia del enrutado en Kubernetes y te prepara para un ecosistema en el que el Ingress irá cediendo protagonismo. Adoptar hoy este estándar es invertir en una base sólida y con futuro, sobre la que tu plataforma podrá crecer durante años sin quedarse anclada en tecnología en vías de quedar obsoleta.

Preguntas frecuentes sobre Gateway API Kubernetes

¿Debo migrar ya del Ingress a Gateway API?

El Ingress sigue soportado, así que no hay prisa, pero Gateway API es el futuro y recibe todo el desarrollo nuevo. Lo recomendable es empezar a usarlo en servicios nuevos y migrar los existentes de forma gradual.

¿Necesito instalar un controlador aparte?

Sí. Gateway API es una especificación con sus CRDs, pero necesita una implementación que la ejecute, como NGINX Gateway Fabric, Envoy Gateway, Istio o Cilium. Elige la que mejor encaje con tu clúster.

¿Puedo hacer despliegues canary?

Sí, y de forma nativa. La división de tráfico por pesos en la HTTPRoute permite enviar un porcentaje del tráfico a una versión nueva sin herramientas externas ni anotaciones propietarias.

¿Gateway API es gratis?

Sí, Gateway API es un proyecto oficial de Kubernetes y de código abierto. Las implementaciones también suelen ser gratuitas; solo asumes los recursos que consumen en tu clúster.

Recursos y documentación oficial

• Sitio oficial de Gateway API
• Gateway API en GitHub
• Gateway API en la documentación de Kubernetes
• NGINX Gateway Fabric
• Guías oficiales de Gateway API