Gateway API de Kubernetes

 (romaglushko.com)
4 puntos por GN⁺ 4 시간 전 | 2 comentarios | Compartir por WhatsApp
  • En noviembre de 2025, Kubernetes anunció la deprecation en marzo de 2026 de NGINX Ingress Controller, que se usaba en más del 40% de todos los clústeres; esta decisión se convirtió en un punto de inflexión que posicionó a Gateway API como sucesora de la API de Ingress
  • Gateway API abarca una gama amplia de funciones necesarias para gestionar el tráfico entrante, ofrece mayor expresividad que la API de Ingress y define con más claridad la separación de responsabilidades entre equipos
  • Entre las limitaciones de la API de Ingress están su alcance de API reducido, extensibilidad rígida, ausencia de aplicación de políticas, límites de propiedad ambiguos y falta de soporte seguro para cross-namespace
  • Gateway API ofrece un modelo de recursos separado con GatewayClass, Gateway, Listener y Route, además de mecanismos de seguridad y extensión como ReferenceGrant y Policy attachment
  • Los CVE repetidos de NGINX Ingress Controller se originan en defectos estructurales y, a largo plazo, la migración a Gateway API es la única solución de fondo

Evolución de Ingress

  • En el Kubernetes inicial de 2014, el recurso Service era el medio básico para exponer aplicaciones
    • ClusterIP solo proporcionaba un nombre DNS interno del clúster, sin acceso externo
    • NodePort abría un puerto específico en todos los nodos para recibir tráfico externo; si la IP del nodo quedaba expuesta, podía habilitar acceso desde fuera
    • LoadBalancer aprovisionaba un balanceador de carga externo con IP pública para enrutar tráfico
    • ExternalName proporcionaba un alias dentro del clúster para un servicio externo mediante un registro CNAME
  • De los cuatro, solo NodePort y LoadBalancer podían exponer servicios directamente al exterior
    • NodePort es un primitivo básico, pero demasiado de bajo nivel: hay que implementar manualmente el balanceo de carga externo entre nodos y el enrutamiento basado en paths
  • LoadBalancer agrega un balanceador L4 (TCP/UDP) sobre NodePort y lo aprovisiona automáticamente; esto queda a cargo del Cloud Controller Manager
    • Sin embargo, como hay que administrar múltiples IP públicas y balanceadores, aumentan los costos y no existe un punto central para gestionar el tráfico
  • En lugar de un balanceador por cada Service, la arquitectura donde un único Service de LoadBalancer recibe todo el tráfico y lo envía a un Deployment de reverse proxy como NGINX para enrutar según path y hostname fue el punto de partida de la API de Ingress y del Ingress Controller

Ingress Controller

  • En 2015, el equipo de Kubernetes introdujo la API de Ingress como un medio para definir reglas que enrutan tráfico HTTP(S) externo hacia Services internos

  • La API de Ingress está compuesta por dos recursos, IngressClass e Ingress, y solo define una interfaz común; para el funcionamiento real es necesario instalar un Ingress Controller

  • IngressClass

    • Recurso cluster-wide que especifica qué controlador procesará un conjunto determinado de recursos Ingress
    • Permite operar en paralelo varios Ingress Controller dentro del mismo clúster; cada controlador observa solo los recursos seleccionados por su IngressClass
    • El controlador necesita permisos de ClusterRole para leer y usar IngressClass

  • Recurso Ingress

    • Ingress es el recurso principal de la API de Ingress y combina varios elementos
      • Define el enrutamiento a Services internos mediante reglas de coincidencia por path (exact/prefix) y por host
      • Define la configuración TLS del tráfico entrante
    • Cuando se crea el recurso, el Ingress Controller lo detecta, actualiza su propia configuración y aplica las reglas de enrutamiento

  • Problemas de la API de Ingress

    • En entornos reales de operación aparecen los siguientes problemas: alcance de API muy limitado, extensibilidad rígida, ausencia de aplicación de políticas, límites de propiedad ambiguos y falta de soporte seguro para cross-namespace

  • Alcance de API muy limitado

    • La API de Ingress no es tanto simple como simplista (simplistic) y solo cubre lo mínimo necesario para configurar tráfico de ingreso
    • No admite directamente las siguientes funciones que suelen requerirse en NGINX
      • request timeout, CORS, límites de max body size, sesiones sticky cookie, división de tráfico canary, rate limiting, enrutamiento basado en header, query o cookie, y modificación de headers
    • Por eso, los custom annotation se volvieron el método estándar para pasar configuración adicional, y algunos controladores como Traefik usan sus propios CRD
    • Si se usan varios Ingress Controller al mismo tiempo, como no existe una forma unificada de configuración, las annotation varían según el controlador y se reduce la portabilidad
    • Ingress solo maneja enrutamiento HTTP(S), mientras que gRPC (L7), TCP y UDP (L4) se resuelven con custom annotation según cada implementación

  • Extensibilidad rígida

    • Los custom annotation no son más que pares clave-valor en texto, por lo que configuraciones complejas deben serializarse como cadenas y eso implica falta de expresividad

  • Ausencia de aplicación de políticas

    • Los equipos de aplicaciones pueden agregar annotation arbitrarias a los recursos Ingress; por ejemplo, podrían desactivar el rate limiting que el equipo de plataforma espera en todas las rutas
    • Como la propia API de Ingress no tiene un mecanismo para imponer comportamiento global, depende de motores de políticas externos como Kyverno u OPA Gatekeeper

  • Límites de propiedad ambiguos

    • El recurso Ingress mezcla varias configuraciones
      • Las reglas de enrutamiento suelen pertenecer al equipo de aplicaciones
      • La configuración de hostname y puerto pertenece al equipo de plataforma, que administra DNS, balanceadores y redes
      • La configuración TLS pertenece al equipo de plataforma, responsable del aprovisionamiento de certificados
      • Los custom annotation pueden pertenecer a cualquiera de los dos equipos
    • En sistemas complejos desplegados con un umbrella Helm chart, Ingress suele ubicarse en el subchart de la aplicación, pero el equipo de plataforma también necesita actualizar o imponer parte de la configuración
    • Desde la perspectiva del principio de responsabilidad única, Ingress tiene más de un motivo de cambio, por lo que conviene separarlo en recursos más enfocados
    Publicidad

  • Falta de soporte seguro para cross-namespace

    • El recurso Ingress no puede referenciar Services ni TLS secret fuera de su propio namespace; en rules[].backend.service ni siquiera existe un campo para indicar namespace
    • Como alternativa, se puede crear un Service de ExternalName en el mismo namespace para apuntar al nombre DNS interno del clúster del Service objetivo
    • Sin embargo, este método incorpora precisamente un problema correspondiente a un confused deputy attack

Gateway API

  • Gateway API es la siguiente generación de la API de Ingress y supera esas limitaciones mediante lo siguiente
    • Cubre un conjunto mucho más amplio de funciones necesarias para gestionar tráfico entrante y aumenta la expresividad
    • Refleja patrones comunes de propiedad de recursos y aclara la separación de responsabilidades entre equipos
    • Incluye un mecanismo de extensión definido llamado policies y referencias flexibles entre objetos cross-namespace

GatewayClass

  • De forma similar a IngressClass, define un conjunto de Gateway propiedad de un despliegue específico de controlador Gateway; en la práctica tiene el mismo significado y estructura que IngressClass
  • Puede referenciar un custom resource con configuración adicional específica de la implementación
    • Incluye la forma de exponer el proxy Gateway, configuraciones predeterminadas de bootstrap y ejecución, el modo de rollout y escalado del despliegue, y otras opciones propias del controlador

Gateway

  • El recurso Gateway representa un edge gateway aprovisionado dinámicamente, una abstracción de infraestructura que recibe tráfico entrante y lo enruta al servicio backend adecuado

    • En el diseño de Ingress, el Ingress Controller cumplía este papel, por lo que puede verse como una instancia de Gateway aprovisionada estáticamente

  • Cada Gateway referencia un GatewayClass para indicar qué controlador lo aprovisionará y administrará; el componente de configuración más importante es la lista de listeners

  • Listeners

    • Define la forma en que un Gateway acepta tráfico entrante; cada listener es un punto de entrada independiente descrito por una combinación de puerto, protocolo y hostname
    • Se puede configurar la terminación TLS; en el mundo de Ingress, esta información existía dentro del recurso Ingress
    • Es la unidad más granular a la que una Route puede adjuntarse en un Gateway

  • ListenerSet

    • Los listeners son buenos para centralizar la configuración de puntos de entrada, pero no son adecuados cuando se necesitan cientos
    • El caso principal es un listener HTTPS con configuración de hostname y TLS por servicio en lugar de un único certificado TLS wildcard, lo que puede generar tantos listeners como microservicios
    • Al modelarlo con un solo Gateway surgen dos problemas
      • Un Gateway solo admite un máximo de 64 listeners
      • Si varios equipos administran listeners y TLS, el Gateway se convierte en un cuello de botella de coordinación
    • Para distribuir esto y hacerlo multi-tenant, se usa el recurso ListenerSet

  • Listeners y Routes permitidos

    • Tras separar los conceptos de Gateway y Route, surge un nuevo problema: controlar qué tenant puede adjuntar una Route a qué listener
    • Los listeners son infraestructura compartida y tienen propósitos distintos; por ejemplo, no es apropiado adjuntar una HTTPRoute al listener tls-passthrough-db, que es un canal passthrough hacia una base de datos, ni tampoco adjuntar una Route desde un namespace distinto de db
    • Como las Routes se agregan de forma autogestionada, se usa el mecanismo allowedRoutes para evitar configuraciones erróneas
    • allowedRoutes establece una relación de confianza entre un Gateway o ListenerSet y las Routes de determinados namespaces y tipos de route

Routes

  • Un listener recibe tráfico, pero no sabe cómo procesarlo después; de eso se encargan los recursos Route, que son la clave de la flexibilidad de Gateway API

  • Existen cinco recursos Route para manejar distintos protocolos

    • HTTPRoute: enrutamiento de tráfico HTTP mejorado y ampliado
    • GRPCRoute: enrutamiento con reconocimiento de gRPC
    • TLSRoute: enrutamiento basado en TLS SNI
    • TCPRoute y UDPRoute: envían directamente el tráfico TCP/UDP del puerto del listener al backend
    Publicidad

  • Todos los recursos Route (conocidos en conjunto como xRoutes) tienen una estructura envolvente similar

    • parentRefs es una referencia tipada a objetos del recurso padre que aloja la Route, normalmente un Gateway, ListenerSet o un Service de service mesh; con las opciones sectionName y port se puede señalar un listener específico
    • rules incluye reglas, filtros y configuración de enrutamiento específicos del protocolo; cada rule se compone de matches, filters opcionales y backendRefs opcionales; si un filtro maneja por completo la solicitud, backendRefs puede omitirse
    • Si el protocolo lo permite, el campo hostnames habilita enrutamiento por host a nivel de Route

  • HTTPRoute

    • Define reglas de enrutamiento para tráfico HTTP(S) de nivel L7

    • Coincidencia de tráfico

      • Admite enrutamiento por path y host similar a Ingress, además de reglas de coincidencia por header, query y método
      • Ejemplo: un lanzamiento canary solo para clientes internos puede enrutar hacia un deployment de prueba mediante coincidencia basada en headers
      • El data plane aplica la regla más específica, por lo que el orden en que se definan las reglas no importa

    • Reescritura de URL

      • Se pueden reescribir partes de la URL de la solicitud antes de llegar al backend usando filtros

    • Modificaciones de headers

      • Proporciona el filtro HeaderModifier para agregar, eliminar o modificar headers de request y response
      • También ofrece un filtro dedicado CORS para configurar Cross-Origin Resource Sharing; conceptualmente es un caso especial de modificación de headers de respuesta, pero se expone como un tipo de filtro separado

    • Redirecciones

      • En lugar de enviar al backend, puede devolver una respuesta de redirección al cliente; admite redirecciones 3xx basadas en path y redirección de HTTP a HTTPS

    • Control de tráfico

      • Permite dividir tráfico entre servicios backend con weights, útil para despliegues blue-green y pruebas A/B
      • El traffic mirroring envía una copia del tráfico de producción a un backend adicional y se configura con el filtro RequestMirror; la solicitud original sigue hacia el backend principal
      • El mirroring es un componente clave del tap-and-compare testing para comparar resultados entre versiones antiguas y nuevas durante refactorizaciones o migraciones

    • Sticky Sessions

      • Admite persistencia de sesión, configurando cookies o headers como marcadores de sesión para enrutar de forma consistente las solicitudes del mismo cliente a la misma instancia backend

    • Autenticación externa

      • Soporta un filtro experimental de autenticación externa basado en gRPC o HTTP; el Gateway envía los headers de la solicitud a un servicio de autenticación externo antes de reenviarla al backend, y el cuerpo de la solicitud solo se envía si se habilita explícitamente
      • En el caso de gRPC, el servicio de autenticación externa debe implementar la API protobuf ext_authz de Envoy
      • En el caso de HTTP, si la autenticación es exitosa debe devolver 200; cualquier otro estado se trata como fallo de autenticación

    • Reintentos y timeouts

      • Se pueden configurar reintentos para rutas específicas, y BackendTrafficPolicy ofrece un presupuesto global de reintentos para evitar retry storms

  • GRPCRoute

    • Como gRPC se basa en HTTP/2, también podría manejarse con HTTPRoute, pero hay razones para modelarlo como un recurso separado
      • Se separan opciones que no tienen sentido para gRPC, como la reescritura de URL, para que cada recurso evolucione de manera independiente según su protocolo
      • Las respuestas gRPC devuelven HTTP 200, pero expresan errores de aplicación mediante los headers grpc-status y grpc-message, algo importante para reintentos y métricas correctos
      • Definir reglas con terminología de alto nivel propia de gRPC mejora la experiencia de uso
    • El path matcher de HTTPRoute se reemplaza por un method matcher; internamente sigue haciendo match sobre el path, pero se expone en formato service/method
    • Puede manejar headers de request y response, pero no decodifica el payload de gRPC, por lo que no puede enrutar según campos específicos de protobuf
    • Soporta algunos filtros de HTTPRoute, como traffic mirroring, weighted load balancing y modificación de headers

  • TCPRoute y UDPRoute

    • Reenvían de forma simple el tráfico que llega al puerto del listener hacia el servicio backend; actualmente no admiten matchers ni filtros
    • Ambos tipos soportan weighted load balancing entre múltiples backends

  • TLSRoute

    • Enruta tráfico TLS cifrado al backend basándose en el SNI proporcionado durante el handshake TLS
    • Se usa principalmente para TLS passthrough: el Gateway revisa el SNI, selecciona el backend y luego reenvía la conexión cifrada sin terminar TLS; el backend se encarga de la terminación TLS
    • Algunas implementaciones como Envoy Gateway o kgateway también admiten terminación TLS en el edge, pero eso es una capacidad extendida
    • La Route debe especificar un hostname, que debe coincidir con el valor de SNI y cruzarse con el hostname del listener del Gateway; no admite matchers ni filtros, pero sí weighted load balancing

  • Extensiones de filtros de Route

    • HTTPRoute y GRPCRoute incluyen un mecanismo para extender filtros personalizados y el procesamiento de request/response mediante el filtro extensionRef, que apunta a otro recurso con una referencia tipada a objetos
    • Ejemplo: Envoy Gateway ofrece un CRD HTTPRouteFilter que devuelve una respuesta directamente sin necesidad de un servicio backend

  • Objetivos de backend

    • De forma predeterminada, admite como objetivos de backend Service estándar (lo más común) y ServiceImport para multiclúster
    • Como se especifican mediante una typed object reference, es posible extenderlos con custom resources específicas de cada implementación
    • Ejemplo: Envoy Gateway admite un custom resource Backend que apunta a upstreams externos como FQDN, IP y sockets UNIX
    Publicidad

  • ReferenceGrant

    • Gateway API trata las referencias cross-namespace como un concepto de primera clase dentro de su diseño estándar, pero existen riesgos de seguridad
    • Caso de confused deputy attack: si un atacante compromete un namespace, puede filtrar acceso a servicios protegidos con permisos para crear Ingress, Service y EndpointSlice
      • Un Ingress nuevo apunta a un Service nuevo del namespace comprometido
      • Ese Service no tiene selector, por lo que no coincide con ningún deployment y permite proporcionar manualmente un EndpointSlice
      • El atacante falsifica un EndpointSlice para incluir las IP de pods backend protegidos de otro namespace, y mediante alineación de puertos crea una segunda vía de entrada a la API protegida
      • También puede lograrse el mismo resultado con un Service de tipo ExternalName
    • Para mitigar esto se introdujo el recurso ReferenceGrant, un mecanismo de confianza bidireccional donde un namespace define qué namespaces pueden referenciar sus recursos
    • El Gateway Controller toma en cuenta ReferenceGrant al hacer referencias cross-namespace a objetivos de backend y secrets TLS, dificultando los confused deputy attacks
    • Aun así, ReferenceGrant solo garantiza la legitimidad de la referencia y no interviene en lo que ocurre después de enrutar el tráfico; se puede complementar bloqueando el acceso al puerto de la API protegida con NetworkPolicies

Policies

  • El policy attachment es un potente patrón de extensión que aplica comportamiento y efectos de forma jerárquica a uno o más componentes de Gateway API sin modificar el recurso original
  • La autenticación es un caso representativo
    • Si se aplica autenticación a todo el Gateway (o ListenerSet), afecta de forma jerárquica a todas las Routes adjuntas actuales y futuras, y al mismo tiempo permite excepciones a nivel Route, como rutas públicas
    • La autenticación puede ser controlada por un equipo distinto al que administra Gateway y Route, por lo que está diseñada para evitar modificar directamente esos recursos
    • Aunque existen estándares como OAuth 2 y OIDC, la configuración de autenticación depende mucho de cada implementación, por lo que es difícil una abstracción que funcione en todas
  • Ejemplo: con el recurso SecurityPolicy de Envoy Gateway se configura la validación de tokens JWT; las policies son una forma moderna y expresiva de reemplazar la configuración basada en annotations de la era de Ingress
  • Solo hay dos Policies integradas
    • BackendTLSPolicy: indica que el Gateway debe conectarse por TLS al backend upstream
    • BackendTrafficPolicy: define el retry budget para un backend específico; si se supera la cuota global de reintentos, devuelve 503, actuando como un circuit breaker para evitar retry storms

Ownership

  • Los recursos de Gateway API dentro del clúster suelen pertenecer a dos equipos
    • El Platform team define GatewayClass, Gateway, ListenerSet y la configuración de LoadBalancer y TLS, y también puede administrar Policies globales que se aplican a parte o a todo el Gateway
    • El Application/Service team se enfoca principalmente en sus propios recursos Route y, cuando hace falta, aplica Policies a nivel Route
  • Como ofrece mucha flexibilidad, también es posible construir distintos modelos de ownership, por ejemplo que el platform team reúna y administre las Routes en un solo namespace

Arquitectura típica

  • Gateway API no asume en gran medida una arquitectura de implementación específica, pero el enfoque más común es la separación entre control plane y data plane
  • El Gateway Controller actúa como un operador de Kubernetes que cumple el rol de control plane: observa los recursos de Gateway API y los CRD, compone la configuración deseada del data plane y requiere permisos ampliados para leer y modificar recursos
  • El data plane de Gateway es el proxy que maneja el tráfico según la configuración; comúnmente se usan Envoy Proxy, NGINX y Traefik, y según la implementación puede aprovisionarse un proxy por Gateway o uno compartido
  • La separación entre control plane y data plane es una decisión de diseño favorable para evitar las fallas de seguridad fundamentales observadas en NGINX Ingress Controller

Migración desde Ingress

  • Hay cuatro opciones para responder a la deprecación de NGINX Ingress Controller, consideradas en orden de menor invasividad

  • No hacer nada

    • No es lo ideal, pero en algunos casos puede ser viable; en un homelab puede haber pocos incentivos para moverse

    • En entornos empresariales es difícil aceptarlo debido a marcos regulatorios, de seguridad y compliance que esperan operar software mantenido y parchado

      • ISO 27001: espera gestión de vulnerabilidades, parches y seguimiento de EOL
      • SOC 2 Type II: espera escaneo de vulnerabilidades, gestión de parches y SLA de remediación
      • HIPAA Security Rule: exige incluir software legacy y sin parches dentro del análisis de riesgos
      • PCI DSS v4.0.1: exige identificar componentes sin soporte y contar con un plan de remediación, además de fijar plazos para vulnerabilidades graves
      • FedRAMP: espera reemplazar software sin soporte por alternativas mantenidas y define plazos de remediación según la severidad

    • En la mayoría de estos marcos, el software EOL se vuelve un problema real cuando se divulgan nuevas vulnerabilidades

    • Análisis de CVE

      • Situación de los CVE de NGINX Ingress Controller en los últimos 5 años
        • 20 vulnerabilidades en total
        • 4 High en 2021 relacionadas con filtración de secrets
        • 1 High en 2022 relacionada con filtración de credenciales del controlador
        • 3 High entre 2023 y 2024
        • 6 en 2025, incluyendo 1 Critical (IngressNightmare) y 4 High relacionadas con inyección de configuración de NGINX
        • 6 en 2026, incluyendo 3 High relacionadas con inyección de configuración de NGINX
      • Los CVE de 2021 y 2022 se debieron principalmente a configuraciones NGINX proporcionadas por usuarios y no saneadas dentro de annotations, lo que causó inyección de configuración, exposición de información y filtración de secrets; Kubernetes añadió validación
      • Los CVE de 2023 y 2024 fueron principalmente bypasses de esa validación de annotations
      • IngressNightmare (CVE-2025-1974) empeora la situación: antes se requerían permisos para crear o modificar recursos Ingress, pero con solo acceso de red al admission controller ya es posible ejecutar código remotamente en el contexto del controlador ingress-nginx mediante un bug similar de inyección de configuración, y luego exfiltrar los Secrets a los que el controlador tenga acceso
      • El lote de 2026 también mantiene el patrón de inyección de configuración mediante annotations, paths y comments
      • Estas vulnerabilidades apuntan repetidamente a la misma debilidad de diseño
        • El controlador es muy flexible y expone una amplia gama de funciones de NGINX, lo que dificulta una validación perfecta y hace que la inyección de configuración reaparezca
        • El controlador ejecuta el control plane y el data plane en el mismo pod y comparte el sistema de archivos, ampliando el alcance del impacto en caso de incidente
        • El controlador suele tener acceso a Secrets de todo el clúster, por lo que una inyección de configuración exitosa puede derivar en exfiltración de secrets a escala de clúster
      • Debido a estos problemas estructurales, es esperable que aparezcan más CVE en el futuro; permanecer con el controlador original sin un plan de migración es una decisión riesgosa
      Publicidad

  • Usar un fork del controlador NGINX

    • La ruta más simple es cambiar a un fork mantenido
      • El fork de Chainguard aparentemente no proporciona imágenes compiladas, y eso parece formar parte de su oferta comercial
    • Puede reducir el riesgo de exposición a nuevos CVE y permitir mantener el sistema sin grandes cambios, pero es una solución de corto plazo
    • Chainguard no busca seguir desarrollando el controlador como un proyecto de largo plazo, sino ofrecer remediación best-effort de CVE para dar tiempo a los usuarios a migrar

  • Usar otro Ingress Controller

    • Como el recurso Ingress en sí no está deprecado, también es válido cambiarse a otro Ingress Controller que siga manteniéndose; entre los más representativos están HAProxy, Istio y Traefik
    • Se requiere migrar las annotations en todo el sistema, y la dificultad varía según el nivel de dependencia de funciones específicas de NGINX
    • A futuro más proyectos migrarán a Gateway API y el peso de Ingress irá disminuyendo, pero por un tiempo Ingress seguirá siendo una opción perfectamente válida

  • Migrar a Gateway API

    • La única opción de largo plazo es pasar de la API de Ingress a Gateway API
      • Instalar los CRD y la implementación de Gateway API
      • Configurar GatewayClass, Gateway y, si hace falta, recursos Policy
      • Migrar los recursos Ingress existentes a Route
    • El CLI ingress2gateway creado por el equipo de Kubernetes ofrece conversión automática en modalidad best-effort, pero luego hay que volver a revisar manualmente las custom annotations
    • Hay que migrar con precisión elementos como timeout, límite de carga de archivos y límite de tamaño del body; si algo se omite o se mapea mal, puede romper silenciosamente supuestos de la aplicación
    • La transición de tráfico desde el LoadBalancer del Ingress Controller hacia el LoadBalancer del nuevo proxy Gateway debe planearse con cuidado, y no tiene por qué ser un big-bang
      • Es posible mantener temporalmente el Ingress Controller como punto de entrada público y enviar solo una parte del tráfico al data plane de Gateway API para probar con tráfico real antes de una transición gradual

Qué Gateway elegir

  • Una vez tomada la decisión de migrar, la primera gran pregunta es qué implementación de Gateway API usar

  • La definición de este artículo para un caso genérico de API Gateway: una gateway escalable para tráfico público North-South desplegada en un entorno totalmente controlado, con patrones comunes de autenticación y rate limiting flexible como base

  • Además del API Gateway, también existen LLM Gateway y Agent Gateway, pero esta sección se enfoca en el API Gateway clásico

  • Conformance de Gateway API

    • El equipo de Kubernetes preparó pruebas de conformance estándar para verificar la exactitud con la que una implementación maneja los protocolos centrales; se enfocan sobre todo en el comportamiento funcional y no incluyen aspectos no funcionales como confiabilidad, rendimiento, escalabilidad o complejidad operativa
    • Conviene preferir implementaciones conformant, y si en el sitio oficial no aparecen resultados, se recomienda pedir a los maintainers el reporte de conformance

  • Benchmarks públicos

    • Además de las pruebas oficiales, existen benchmarks públicos que cubren confiabilidad y rendimiento; John Howard, colaborador de Istio y empleado de Solo.io, creó benchmarks para las principales implementaciones, y Solo.io es la empresa matriz de kgateway
    • Incluyen casos de prueba útiles como route attachment, propagación, escala y rendimiento general en manejo de tráfico; aunque pueden estar sesgados hacia ciertos escenarios por basarse en su experiencia, sirven como una perspectiva adicional para evaluar

  • OSS vs propietario

    • Hoy existen muchas implementaciones OSS de Gateway API sólidas y listas para producción, así que vale la pena considerarlas seriamente al evaluar; para muchas organizaciones, OSS es el punto de partida por defecto
    • Funciones como OAuth2 y OIDC, que antes justificaban comprar soluciones comerciales, ya se volvieron commodity, y los controladores OSS también las ofrecen de base
    • Con OSS se puede evaluar la calidad directamente antes de comprometerse, mientras que con opciones comerciales hay que confiar en el vendor desde temprano

  • Recomendaciones

    • Agrupadas según el data plane

      • Basados en Envoy Proxy: Envoy Gateway, Istio, Cilium, kgateway, etc.
      • Basados en NGINX: NGINX Gateway Fabric, Kong
      • Otros proxies: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Controlador open source de Gateway API basado en Envoy Proxy y desarrollado por el equipo de Envoy Proxy; al mapear las funciones de Envoy de la forma más directa posible hacia Gateway API, tiene menos abstracciones específicas de producto que Istio y por eso es más fácil de entender
      • No soporta la API de Ingress, y puede ampliar sus funciones con Envoy AI Gateway para capacidades de gateway de LLM, gateway de MCP e Inference Pools
      • Es ligero y sencillo de desplegar y operar, con enfoque en API Gateway (North-South), y entre sus funciones soportadas están
        • patrones de seguridad como external authentication, validación de JWT, authorization basada en claims de JWT, OIDC, IP allowlisting, autenticación con static API key e inyección de credenciales
        • política flexible de global rate limit con configuración global y a nivel de route, shadow mode y ajustes de request cost
        • límites de conexión, ancho de banda y tamaño de archivo, routing con conciencia de availability zone, multicluster básico basado en ServiceImport, compresión de respuesta con Brotli, gzip y zstd, direct response y response override
        Publicidad
      • También tiene gran extensibilidad: se pueden escribir servicios gRPC para modificar solicitudes, respuestas y configuración xDS, y crear plugins con Lua o lenguajes compilables a WASM como Go y Rust
      • Incluye un recurso custom Backend para recursos externos por FQDN o IP, y para apuntar a sockets UNIX de sidecar
      • Actualmente figura como partially conformant por algunas pruebas omitidas, pero funcionalmente cumple casi todos los puntos, e integra proyectos CNCF como KEDA y KNative
      • Si solo necesitas un API Gateway con muchas capacidades, es una buena opción

    • Istio

      • Service mesh basado en Envoy Proxy y proyecto CNCF Graduated, listado como conformant en las pruebas de Gateway API
      • Es un paquete que incluye Ingress Controller, controlador de Gateway API y service mesh, y mediante integración con agentgateway puede ofrecer funciones de gateway para LLM, MCP y A2A
      • Soporta multicluster avanzado con herramientas como Admiral, tiene un amplio perfil de despliegue, una gran comunidad y abundante material como libros de O'Reilly; además, el cifrado pod-to-pod basado en mTLS es útil en entornos gubernamentales y FedRAMP
      • Como desventajas, en modo sidecar consume muchos recursos y tiene muchos conceptos propios, por lo que la curva de aprendizaje es pronunciada
      • Ofrece una configuración más ligera con ambient mode, pero en casos avanzados de L7 puede no ser tan funcional como sidecar; si se necesitan políticas más fuertes y mayor control L7, puede considerarse usar Envoy Gateway junto con el ingress gateway y el waypoint proxy
      • Es la mejor opción cuando lo principal es el service mesh y Gateway API es secundario; si solo necesitas un API gateway, puede sentirse algo insuficiente

    • kgateway

      • Gateway open source CNCF Sandbox basado en el proyecto Gloo, con soporte para Envoy Proxy y agentgateway como data plane (para funciones de AI gateway), y con posibilidad de usar instancias propias de data plane administradas externamente
      • Tiene conformance completa de Gateway API, y es casi el único que cumple todos los puntos
      • En el data plane de Envoy expone validación de JWT, OAuth2/OIDC, external authentication y control de acceso por IP, además de global rate limiting de Envoy y procesamiento de solicitudes y respuestas basado en ext_proc, aunque parece no exponer plugins Lua o WASM ni edición directa de raw xDS
      • Con un potente motor de transformation basado en plantillas MiniJinja, permite definir de forma declarativa transformaciones de headers, body de respuesta y status en el recurso TrafficPolicy
      • Puede integrarse con Istio como edge proxy, pero no actúa como service mesh por sí mismo; soporta routes jerárquicas, donde una Route delega el procesamiento de tráfico a otra Route, y cuenta con un CRD custom AwsLambda para invocar AWS Lambda directamente
      • Aunque el vendor afirma tener un despliegue amplio, no hay mucho feedback independiente, así que desde la perspectiva de la comunidad pública todavía parece un proyecto en crecimiento

  • Traefik

    • Popular reverse proxy de código abierto escrito en Go; soporta tanto Ingress API como Gateway API, y es especialmente popular en la comunidad homelab por su excelente documentación, base de código ordenada, configuración simple y despliegue sencillo

    • Soporta las funciones principales de Gateway API y algunas adicionales, pero todavía no soporta ListenerSet ni traffic mirroring a través de Gateway API (aunque el mirroring sí es posible con un backend TraefikService personalizado)

    • Su modelo de extensión se basa en middleware: conecta Routes a Middleware CRD mediante filtros ExtensionRef, y sus middlewares integrados ofrecen ForwardAuth (delegación de autenticación externa, similar a Envoy ext_authz), allowlisting de IP y CORS, límites de conexión, retry y circuit breaker, compresión, páginas de error personalizadas, entre otros

    • Con el middleware de Plugin se pueden conectar plugins personalizados de YAEGI y WASM (principalmente para modificar solicitudes y respuestas), pero la validación de JWT, OIDC y OAuth2 Client Credentials solo se ofrece como plugins de pago

    • El Middleware CRD ofrece rate limiting distribuido básico (buckets por IP, host y header), pero la configuración no es muy flexible y, al adjuntarse mediante ExtensionRef en vez de policy attachment, se dificulta la jerarquización, como aplicar reglas globales y luego sobrescribirlas a nivel de ruta

    • No hay una separación clara entre control plane y data plane, por lo que su arquitectura se parece más a NGINX Ingress: el mismo pod observa recursos y procesa tráfico; no aprovisiona dinámicamente un proxy por Gateway, sino que un solo deployment administra todos los Gateway del namespace observado, lo que puede generar un punto único de falla, menor aislamiento y problemas de resiliencia a gran escala

    • Al elegirlo, se recomienda hacer pruebas de carga con el tráfico esperado; en particular, he escuchado quejas sobre el rendimiento de Traefik, así que conviene tener más cuidado

    • NGINX Gateway Fabric

      • Implementación oficial de Gateway API de F5 basada en NGINX (NGF); tiene una conformance sólida y, en versiones recientes, añadió soporte para Gateway API 1.5 y para CORS y modificación de headers de request/response mediante filtros estándar de HTTPRoute
      • Algunas funciones, como autenticación JWT y OIDC, session persistence basada en cookies y actualización de upstreams sin recargar NGINX, siguen dependiendo de NGINX Plus, aunque estos son requisitos comunes en API Gateway
      • Con SnippetsPolicy y SnippetsFilter personalizados, se puede inyectar configuración NGINX personalizada en varios niveles de la configuración generada, lo que facilita migrar desde NGINX Ingress sin reescribir la enorme cantidad de configuraciones personalizadas existentes
      • Soporta rate limiting con una RateLimitPolicy personalizada, pero es local rate limiting, por lo que el estado vive en el data plane de NGINX; si se operan múltiples réplicas de NGF, el límite efectivo cambia según la cantidad de instancias, lo que dificulta imponer límites estrictos por usuario
      • NGINX en sí ofrece escape hatches de extensión como scripting ligero con JavaScript y Lua, auth_request para delegar autenticación externa (similar a Envoy ext_authz y Traefik ForwardAuth) y módulos C personalizados; sin embargo, no soporta modificación de solicitudes/respuestas basada en servicios externos al estilo ext_proc
      • En NGF 2.0 se rediseñó la arquitectura para separar control plane y data plane y soportar múltiples recursos Gateway; antes, la arquitectura era una preocupación importante

    • Cilium Service Mesh

      • Muchos clústeres usan Cilium como CNI, y su service mesh sidecar-less basado en eBPF incluye una implementación de Gateway API basada en Envoy Proxy, lo que permite reducir componentes y adelgazar el stack tecnológico
      • Sin embargo, se enfoca principalmente en la conformance de Gateway API, y funciones útiles de Envoy fuera de Gateway API no se exponen como configuración de primera clase; por ejemplo, no hay soporte de primera clase para extensiones y plugins de Envoy, allowlisting de IP, validación de JWT, autorización basada en claims ni OIDC
      • A menos que tengas la certeza de que las funciones actuales de Gateway API de Cilium son suficientes, no lo recomiendo como API Gateway de propósito general frente a opciones más completas como Envoy Gateway, kgateway o Istio

    • Kong

      • API Gateway popular basado en NGINX; Kong Operator soporta tanto Ingress como Gateway API
      • La principal preocupación es su estrategia OSS: parece haber dejado de publicar imágenes Docker precompiladas para nuevas versiones open source del Gateway, y las imágenes OSS parecen haberse detenido alrededor de la línea de releases 3.10, por lo que podría ser necesario compilar, parchear, endurecer y mantener todo por cuenta propia
      • Existe especulación pública de que esta medida se relaciona con reducir la pérdida de clientes enterprise, aunque no puede tomarse como un hecho confirmado; aun así, la dirección del OSS se siente menos predecible
      • Por eso, no lo recomiendo a menos que vayas a comprar una licencia enterprise o estés preparado para asumir tú mismo el empaquetado y mantenimiento de OSS

Summary

  • Sigue la evolución de los patrones de ingress de Kubernetes desde sus inicios hasta la era de Gateway API, y profundiza en el propio protocolo Gateway API
  • GAMMA (extensión de las ideas de Gateway API hacia service mesh) e Inference Extension (definición y optimización de workloads de inferencia en Kubernetes) quedan excluidos intencionalmente del alcance, ya que son temas que requieren un análisis profundo por separado
  • También revisa las implementaciones disponibles de Gateway API y los criterios para elegir entre ellas

Lecturas relacionadas

2 comentarios

 
click 1 시간 전

Recuerdo que el año pasado intenté usar NGF, pero como no había forma de crear autenticación basada en el header Authorization, terminé yéndome con envoy.
Prefiero nginx antes que envoy, así que si llega a tener soporte completo para Gateway API, creo que la próxima vez probaré NGF.
 
hmmhmmhm 2 시간 전

Parece que Envoy va a ganar aún más protagonismo.