Introducción a Gateway API de Kubernetes

En este post vamos a explorar el nuevo (o no tan nuevo) Gateway API en Kubernetes.

Table of Contents

¿Qué es Gateway API en Kubernetes?

Gateway API es un proyecto oficial de Kubernetes que se centra en el enrutamiento L4 y L7 en Kubernetes. Su objetivo es representar la próxima generación de API para Ingress, Balanceo de Carga y Service Mesh en Kubernetes. Podríamos describirlo como una especie de “Ingress v2”.

Este API alcanzó la fase GA en octubre de 2023, y el proyecto sigue avanzando rápidamente con más de 170 colaboradores trabajando en su desarrollo.

🔗 Presentación en KubeCon 2023 por Rob Scott & Nick Young

¿Por qué Kubernetes necesitaba un “Ingress v2”?

En los últimos años, las limitaciones y desventajas de la API de Ingress original se hicieron evidentes, lo que llevó a la comunidad a desarrollar alternativas más avanzadas como Istio’s VirtualService API o Contour’s IngressRoute API. Esto generó la necesidad de un nuevo estándar.

Algunos de los problemas del Ingress API incluyen:

Diseño basado en el “mínimo común denominador”

Se diseñó para garantizar consistencia entre los clústeres de Kubernetes, sin importar la implementación de red.
Solo se incluyeron funcionalidades esenciales para que cualquier controlador pudiera soportarlo.
Funcionalidades clave como splitting de tráfico, manipulación de headers, releases canary o configuraciones avanzadas de TLS no podían implementarse en la API estándar.
Dependencia excesiva en Annotations, lo que llevó a implementaciones divergentes entre controladores.

Un solo recurso para todo

Ingress encapsula rutas, configuración TLS y más en un solo recurso.
Dificulta la separación de responsabilidades entre desarrolladores e ingenieros de infraestructura.
No hay una división clara de roles entre operadores de clústeres, desarrolladores de aplicaciones y administradores de redes.
Recursos sobrecargados y difícil de escalar.

Especificaciones vagas y extensibilidad limitada

Al estar dentro del core de Kubernetes, depende de los ciclos de lanzamiento de Kubernetes.
Esto provocó que los controladores tuvieran que bypassear las limitaciones mediante anotaciones personalizadas.
Aparecieron múltiples implementaciones alternativas como Istio’s VirtualService y Contour’s IngressRoute, fragmentando el ecosistema.

Falta de soporte para casos de uso modernos

Cuando se creó Ingress, conceptos como shifting de tráfico, transformaciones L7, mTLS o políticas avanzadas de reintento no estaban contemplados.
Ingress es altamente dependiente de HTTP, dejando fuera protocolos como TCP, gRPC o TLS passthrough.

Uno de los principales motivos para crear Gateway API fue la falta de portabilidad real en Ingress, debido a su API minimalista, dependencia de anotaciones y comportamientos específicos de los controladores.

Gateway API (o “Ingress v2”)

Gateway API fue desarrollado para solucionar todas estas limitaciones a largo plazo, introduciendo:

Recursos bien definidos y jerarquizados, con separación de responsabilidades.
Extensibilidad explícita mediante versionado y release channels.
Soporte para Mesh y Multi-Cluster con la misma API.

Recursos jerarquizados

Los tres tipos principales de objetos en Gateway API son:

🔗 Presentación en KubeCon 2023 por Rob Scott & Nick Young

GatewayClass

Equivalente a los antiguos Ingress Controllers.
Define comportamientos y configuraciones comunes para los Gateways.
Es un recurso a nivel de clúster.
Se necesita al menos un GatewayClass para que los Gateways funcionen.

Gateway

Define cómo enrutar el tráfico entrante (interno o externo al clúster) hacia los Servicios.
Depende de un GatewayClass, que determina el balanceador de carga o proxy subyacente.
Cada Gateway tiene Listeners, que definen cómo manejar el tráfico.

Routes

Especifica reglas de enrutamiento dependiendo del protocolo (HTTPRoute, TCPRoute, etc.).
La relación entre Gateway y Routes puede ser uno a uno, uno a muchos o muchos a uno.

Roles y personas en Gateway API

Gateway API redefine los roles en Kubernetes, estableciendo una separación de responsabilidades más clara.

Proveedor de infraestructura
Administra GatewayClass y GatewayController, configurando la infraestructura de red compartida.
Operador de plataforma
Configura recursos Gateway en base al GatewayClass definido y establece políticas de red.
Desarrollador de aplicaciones
Administra Route resources (ej: HTTPRoute, TCPRoute) para dirigir el tráfico a sus servicios.

Implementaciones de Gateway Controllers

Tal como ocurre con Ingress, Gateway API tiene múltiples controladores. Algunos de los más destacados son:

Istio: Soporta HTTPRoute, GRPCRoute y TLSRoute con funcionalidades extendidas.
Cilium: Gran cobertura en features de Gateway y Mesh, aunque faltan algunas de Istio.
Traefik y NGINX: Implementaciones parciales con soporte para funcionalidades básicas.
Kong: Soporte parcial para HTTPRoute y sin compatibilidad con GRPCRoute o TLSRoute extendidos.

Si buscas la implementación más completa de Gateway API v1.2, Istio y Cilium son las opciones más robustas.

🔗 Lista de controladores de Kubernetes Gateway API

Soporte de Service Mesh

En la documentación se menciona la iniciativa GAMMA (Gateway API for Mesh Management and Administration), un grupo que trabaja en la integración del API con Service Meshes.

Desde la versión v1.1.0, Gateway API soporta Service Mesh en el Standard Channel.
Un cambio clave es que en entornos de Mesh, las rutas (ej: HTTPRoute) se asocian directamente a los Servicios, sin necesidad de usar Gateways ni GatewayClasses.

Más detalles en la documentación oficial:

🔗 Overview — Kubernetes Gateway API

Implementación de Release Channels (sin Beta)

A diferencia de otras API en Kubernetes, Gateway API no tiene fase Beta. En su lugar, usa Release Channels, donde todas las nuevas funciones comienzan en el canal Experimental y luego pueden graduarse al canal Standard, o ser descartadas.

Cada versión se identifica con un “bundle version”, por ejemplo v1.0.0, e incluye:

Tipos de API (bindings en Go)
CRDs (definiciones en Kubernetes)
Version Indicators, visibles con:

kubectl describe crd gateways.gateway.networking.k8s.io | grep channel kubectl describe crd gateways.gateway.networking.k8s.io | grep bundle-version

Confusión entre API Gateway y Gateway API

Un API Gateway es un concepto general que engloba herramientas para exponer servicios backend con capacidades de enrutamiento (ej: balanceo de carga, autenticación, rate limiting).

Gateway API, en cambio, es una API nativa de Kubernetes con recursos como GatewayClass, Gateway y Routes.

Ejemplo:

Apache APISIX es un API Gateway, pero no una implementación directa de Gateway API en Kubernetes.
Sin embargo, APISIX soporta Gateway API, lo que permite integrarlo como un controlador de Gateway API en Kubernetes.

Próximos pasos

En el próximo post veremos ejemplos técnicos y configuraciones detalladas para trabajar con Gateway API en la práctica.