Xepelin, una de las empresas fintech más grandes de América Latina, fue fundada en Chile en 2019 y ahora también opera en México. Xepelin se enfoca en proporcionar soluciones financieras personalizadas diseñadas para impulsar el crecimiento sin los procesos burocráticos tradicionales.
En Xepelin, hemos estado ejecutando kgateway con Kubernetes Gateway API en producción en múltiples clusters de Kubernetes, abarcando ~500 namespaces y cientos de recursos de rutas. Nuestra plataforma integra Kubernetes con Prometheus, OpenTelemetry, CloudWatch, Datadog y otros componentes para soportar un ambiente de alto tráfico y altamente observable.
Contexto
Xepelin funciona en AWS utilizando Kubernetes con EKS. Operamos múltiples ambientes y manejamos una cantidad significativa de tráfico interno y externo. Con el tiempo, la capa de tráfico se volvió más compleja, tanto operacionalmente como en términos de costos. Nuestros objetivos principales eran:
- Simplificar la arquitectura de tráfico
- Mejorar la observabilidad
- Reducir los costos de infraestructura
Arquitectura de tráfico heredada en Xepelin basada en AWS API Gateway, Lambda authorizers y Network Load Balancers por cada servicio, lo que llevó a complejidad operacional y altos costos de infraestructura.
Al operar de una forma en que AWS API Gateway controla todo el tráfico entrante a los clusters de EKS a través de Network Load Balancers (NLBs), comenzamos a enfrentar varios problemas:
- Un gran número de NLBs, lo que generaba altos costos de infraestructura.
- Gestión fragmentada del tráfico, donde los manifiestos de Kubernetes manejaban la configuración del Service (tipo LoadBalancer), mientras que las rutas de AWS API Gateway se creaban y modificaban por separado usando Terraform o la Consola de AWS. Esta división de responsabilidades resultó en un flujo de trabajo desarticulado y aumentó la complejidad operacional al gestionar cambios de tráfico de extremo a extremo.
- Observabilidad fragmentada a lo largo del camino del tráfico, lo que hacía imposible tener métricas centralizadas y visibilidad de extremo a extremo en la cadena API Gateway → NLB → Kubernetes Service. Como resultado, diagnosticar problemas como errores 503 esporádicos era lento y requería investigación manual en múltiples sistemas.
Nuestro modelo inicial dependía en gran medida de Services de Kubernetes de tipo LoadBalancer, con AWS API Gateway enrutando el tráfico directamente a los NLBs creados por esos servicios. Esto resultó en un gran número de Network Load Balancers y costos operacionales en constante aumento.
En ese momento, teníamos el AWS Load Balancer Controller instalado en cada cluster. Si bien esto facilitaba la creación de nuevos load balancers, también contribuyó significativamente a la proliferación de infraestructura.
¿Por qué kgateway?
Migrar de una arquitectura centrada en AWS API Gateway a una solución nativa de Kubernetes no era solo un cambio de herramientas. Representaba un cambio fundamental en cómo exponemos, operamos y observamos nuestras APIs. Por esto, elegir el gateway para el tráfico norte-sur fue una decisión crítica.
La arquitectura existente había estado en su lugar durante años y no escalaba bien. Por lo tanto, cualquier migración tenía que cumplir con un requisito fundamental: necesitaba ser lo más transparente posible tanto para los equipos como para los flujos de tráfico existentes.
Con eso en mente, nos enfocamos en los siguientes aspectos.
Migración transparente y de baja fricción
Uno de los principales desafíos era replicar el comportamiento que ya existía en AWS API Gateway, especialmente el Lambda Authorizer.
Este autorizador recibía cada solicitud, realizaba varias validaciones e interactuaba con servicios de AWS como Secrets Manager.
Con kgateway, pudimos replicar este comportamiento gracias a su estrecha integración con Envoy y su soporte para autorización externa.
Soporte completo y nativo con Kubernetes Gateway API
El soporte completo y nativo para Kubernetes Gateway API era un requisito clave para nosotros.
Queríamos que Gateway API fuera la forma principal de modelar el tráfico norte-sur, no una capa opcional. Kgateway se destacó porque Gateway API está en el núcleo de su diseño, lo que lo convirtió en una opción natural para cómo gestionamos el enrutamiento y el comportamiento del tráfico en producción.
Construido sobre Envoy
Kgateway está construido sobre Envoy, uno de los proxies más utilizados y potentes en el ecosistema cloud-native. Envoy proporciona:
- Métricas detalladas por proxy y por ruta (counters, gauges, histograms)
- Visibilidad detallada de request rates, latencia, errores y comportamientos de upstream/downstream
- Flexibilidad avanzada en timeouts, retries, circuit breaking y más
Historia y madurez: Nacido como Gloo
BAntes de llamarse kgateway, el proyecto era conocido como Gloo y fue desarrollado por Solo.io. Este fue un factor importante para nosotros porque:
- Ha sido probado en cientos de despliegues de producción
- No es experimental, sino un proyecto muy maduro y estable
- Ha procesado miles de millones de solicitudes para grandes empresas en todo el mundo
Este historial fue una ventaja importante sobre alternativas más nuevas o menos adoptadas.
Observabilidad avanzada con integración nativa de OpenTelemetry
Métricas
- Control plane: El control plane de kgateway expone métricas de Prometheus que brindan visibilidad completa sobre cómo se comportan la sincronización y la reconciliación.
- Data plane: Cada pod de Envoy expone métricas detalladas de Prometheus que describen el comportamiento del tráfico real. Esto permite que las métricas sean consumidas directamente por nuestro stack de observabilidad existente o a través de un OpenTelemetry Collector, integrándose completamente con nuestra infraestructura de monitoreo.
Access logs
Los access logs de Envoy relacionados al data plane son muy fáciles de exponer usando recursos gestionados por el propio controlador de kgateway. También proporciona exportadores nativos a colectores de OpenTelemetry.
Trazas
Kgateway incluye exportadores de trazas nativos que pueden enviar trazas directamente a colectores de OpenTelemetry.
Sincronización rápida y retroalimentación casi inmediata
Un aspecto que resultó ser más importante de lo esperado fue la velocidad de sincronización entre los recursos de Kubernetes y el data plane de kgateway.
Con kgateway, los cambios en los recursos HTTPRoute se reflejan en Envoy casi instantáneamente, típicamente en segundos según nuestra experiencia. Esto contrasta marcadamente con nuestra configuración anterior de AWS API Gateway, donde los cambios eran más lentos, involucraban múltiples pasos de despliegue y a menudo requerían coordinación manual entre equipos.
La baja latencia entre los cambios de HTTPRoute en el control plane y su aplicación en el data plane fue un factor clave para elegir kgateway. También se ajusta muy naturalmente con un modelo GitOps, donde los cambios en manifiestos se reflejan rápidamente en el tráfico en vivo.
Enfoque en tráfico norte-sur con un camino hacia este-oeste
El objetivo principal de esta migración era arreglar el enrutamiento de tráfico norte-sur, específicamente:
- Reducir costos al disminuir el número de NLBs
- Obtener observabilidad real y detallada
- Aplicar políticas de seguridad externas
Más allá de eso, queríamos una arquitectura que pudiera evolucionar hacia un service mesh capaz de manejar tráfico este-oeste. Kgateway encajó bien porque:
- Usa Envoy como su plano de datos
- Se integra limpiamente con Gateway API
- Puede actuar como un ingress para un futuro service mesh
- Funciona particularmente bien como ingress para Istio Ambient Mode, donde Envoy actúa como un waypoint proxy para aplicar políticas L7 sin sidecars
Comparación con otras herramientas
También evaluamos Kong y Traefik antes de decidir usar kgateway:
Cómo Xepelin usa kgateway
Hoy, kgateway es el núcleo de nuestra capa de tráfico en Xepelin. Lo usamos consistentemente en ambientes de producción, desarrollo y pruebas, lo que nos permite mantener el mismo modelo operacional a lo largo de todo el ciclo de vida del servicio.
Cuando el tráfico llega a la plataforma, ya sea a través de un Application Load Balancer para tráfico público o un Network Load Balancer para tráfico interno, ambos flujos pasan a través de los proxies Envoy en el data plane de kgateway. Desde allí, todo el enrutamiento se maneja de forma declarativa dentro de Kubernetes.
Las aplicaciones se gestionan a través de una plataforma interna para desarrolladores (IDP) que centraliza la incorporación y el gobierno. Esta IDP es responsable de crear recursos HTTPRoute y vincularlos a los objetos Gateway apropiados según el ambiente y el tipo de tráfico. Para los equipos de desarrollo, el proceso es simple, consistente y de autoservicio, mientras que la complejidad del gateway está completamente abstraída por la plataforma.
La velocidad de sincronización es otra ventaja clave. Desde el momento en que se crea o actualiza un HTTPRoute, generalmente toma solo unos segundos para que la ruta se active. Este ciclo de retroalimentación rápido mejoró significativamente nuestro ciclo de vida del servicio, reduciendo los tiempos de espera y haciendo los despliegues más predecibles.
Más allá del enrutamiento básico, confiamos en las extensiones de kgateway para controlar el comportamiento avanzado. Usando BackendPolicies como BackendConfigPolicy, ajustamos parámetros específicos de Envoy incluyendo keep-alives upstream, timeouts de backend y manejo de conexiones. También aplicamos rate limiting nativo, lo que nos permite proteger servicios y estandarizar límites sin depender de sistemas externos.
Desde el punto de vista de seguridad, podemos integrar nuestro propio servicio de autenticación externa personalizado con kgateway. Este servicio desarrollado internamente puede habilitarse y configurarse por gateway o por ruta. Esto nos permitió replicar y evolucionar el modelo de Lambda Authorizer que usamos anteriormente, manteniendo la lógica de autorización desacoplada del gateway y completamente nativa de Kubernetes.
En general, este modelo basado en una IDP interna, Gateway API, kgateway y autenticación externa personalizada nos brindó una capa de tráfico que es predecible, rápida de operar y fácil de escalar.
Kgateway no solo reemplazó la arquitectura anterior, se convirtió en un componente central de la plataforma sobre el que continuamos construyendo.
Arquitectura de tráfico actual usando kgateway y Kubernetes Gateway API, con ingress centralizado, gateways compartidos y enrutamiento declarativo gestionado completamente dentro de Kubernetes.
Cómo usamos la telemetría de kgateway
Actualmente usamos la telemetría de kgateway en dos capas distintas. Por un lado, tenemos los access logs relacionados a cada gateway. Por el otro, consumimos métricas tanto del control plane como del data plane, con la mayor parte del enfoque en el data plane.
Métricas
En la práctica, las métricas en las que más confiamos son las expuestas por Envoy en el data plane, ya que proporcionan una imagen clara y precisa de cómo se está comportando el tráfico en realidad.
Monitoreamos principalmente:
- Request counts
- Latencias
- Throughput
- Errores y timeouts
- Códigos de respuesta y flags de Envoy
Lo que hace que estas métricas sean especialmente valiosas es su nivel de granularidad. Podemos desglosarlas por servicio backend, recurso de Gateway API, ambiente e incluso etiquetas personalizadas. Esto es sencillo de lograr gracias a la integración nativa de OpenTelemetry de kgateway, que nos permite enriquecer la telemetría sin atarnos a un proveedor de observabilidad específico.
En producción, enviamos estas métricas a Datadog. En ambientes de desarrollo y pruebas, las enviamos a Prometheus y las visualizamos en Grafana. El modelo permanece igual, solo cambia el backend.
Dashboards de Datadog construidos a partir de métricas de Envoy y kgateway, proporcionando visibilidad detallada de tasas de solicitudes, latencias, errores y comportamiento del tráfico por servicio.
A través de nuestros dashboards de Grafana, podemos profundizar fácilmente en los códigos de respuesta e investigar respuestas no-200 con más detalle cuando sea necesario.
Logs de acceso de Envoy por solicitud desde kgateway, incluyendo códigos de estado HTTP, rutas de solicitud, servicios upstream y duración de extremo a extremo de la solicitud.
Logs: entendiendo solicitudes individuales
En paralelo, confiamos mucho en los access logs de Envoy para obtener visibilidad detallada a nivel de solicitud individual. Actualmente, estos logs se envían a Amazon CloudWatch, con la opción de enrutarlos a Loki en el futuro.
Los access logs son críticos cuando algo no se ve bien. Las métricas te dicen que algo está mal; los logs te dicen exactamente qué pasó. Más de una vez, los códigos de respuesta y flags de Envoy encontrados en los access logs nos ayudaron a determinar si un problema se originó en el backend, el gateway o en algún lugar intermedio.
Métricas y logs juntos
En las operaciones del día a día, el valor real proviene de usar métricas y logs juntos. Las métricas nos ayudan a detectar problemas rápidamente, mientras que los logs nos permiten entenderlos en profundidad. Tener este nivel de visibilidad en la capa de tráfico fue una mejora importante sobre nuestra arquitectura anterior y ahora es una parte fundamental de cómo operamos kgateway en producción.
Impacto en costos y operaciones
Uno de los impactos más claros de adoptar kgateway fue tanto en costos como en sobrecarga operacional.
Antes de la migración, nuestro modelo era esencialmente una aplicación, un Network Load Balancer. A medida que la plataforma creció, el número de NLBs creció con ella, eventualmente volviéndose costosos y difíciles de gestionar.
Después de consolidar el tráfico a través de kgateway, redujimos el número de NLBs aproximadamente en un 96%. En lugar de aprovisionar un load balancer por servicio, ahora enrutamos múltiples aplicaciones a través de un pequeño conjunto de puntos de entrada compartidos.
Este cambio tuvo un impacto inmediato en los costos de infraestructura, pero la mayor victoria fue la simplicidad operacional. Con muchos menos NLBs:
- Hay menos infraestructura que mantener
- Menos componentes pueden fallar en el camino del tráfico
- La red por ambiente es significativamente más simple
- Los equipos pasan menos tiempo lidiando con problemas relacionados con load balancers
En la práctica, kgateway nos ayudó a dejar de mantener grandes cantidades de infraestructura repetitiva y enfocarnos más en mejorar la plataforma en sí misma. Si bien los ahorros de costos fueron importantes, la reducción en el esfuerzo operacional y la complejidad fue igual de valiosa.
Desafíos y lecciones aprendidas
Adoptar kgateway fue muy positivo en general, pero también vino con lecciones importantes que ahora consideramos esenciales para una operación estable.
Cada backend es diferente
Cada aplicación, vista por Envoy como un upstream, mantiene su propio pool de conexiones. No hay una única configuración que funcione para todo. Definir BackendPolicies bien ajustadas por servicio, incluyendo keep-alives, timeouts y reintentos, fue crítico para lograr conexiones estables y evitar errores intermitentes.
Gateway API requiere un cambio de mentalidad.
Viniendo de modelos tradicionales de Ingress y load balancers, toma tiempo ajustarse a la forma de modelar el tráfico de Gateway API. Conceptos como Gateways, HTTPRoutes y delegación a nivel de namespace no son complejos, pero son diferentes. Una vez que el modelo hace clic, las cosas comienzan a tener mucho más sentido.
La comunidad ayudó mucho
Durante la adopción, tuvimos muchas preguntas tanto sobre diseño como implementación. Nuestra experiencia con la comunidad de kgateway fue extremadamente positiva: las respuestas fueron claras y rápidas, ayudándonos a avanzar sin quedarnos atascados.
El tráfico norte-sur todavía requiere ajustes cuidadosos
Aunque kgateway abstrae gran parte de la complejidad, los timeouts y keep-alives aún necesitan estar alineados entre ALBs, NLBs, Envoy y backends. Cuando estas configuraciones están desalineadas, pueden aparecer problemas difíciles de depurar a menos que haya telemetría sólida en su lugar.
Sin telemetría, esto sería imposible de operar
Tener métricas y logs desde el primer día fue crítico. En múltiples ocasiones, la telemetría de Envoy fue lo que nos permitió identificar si un problema residía en el gateway, el backend o fuera del cluster.
La autenticación externa es flexible, pero no trivial
Mover la autorización fuera del gateway fue la decisión correcta, pero requiere un diseño cuidadoso en torno a latencia, timeouts y resiliencia. La autorización permanece como parte del camino crítico de la solicitud y debe tratarse como tal.
En general, kgateway resolvió muchos problemas estructurales para nosotros, pero como cualquier componente central de la plataforma, funciona mejor cuando se opera con prácticas claras y buena disciplina operacional. Estas lecciones ahora están integradas en cómo diseñamos y ejecutamos la capa de tráfico en Xepelin.
Conclusión
Estamos muy contentos con todas las características que exploramos con kgateway, incluyendo autorización externa integrada, integración nativa de OpenTelemetry y enrutamiento de alto rendimiento. También estamos probando la integración del waypoint proxy con Istio ambient mesh en una fase de prueba de concepto, y hasta ahora nos ha ayudado a validar nuestra futura arquitectura de service mesh.
