Cada vez más cargas de trabajo de APIs se ejecutan en Kubernetes, y los equipos quieren una gestión de APIs completa —seguridad, cuotas y analítica— sin arrastrar un gateway pesado a cada clúster. El Apigee Adapter for Envoy resuelve justo eso: convierte el proxy Envoy que quizá ya ejecutas en tu service mesh en un API gateway gestionado por Apigee, situado junto a tus servicios de backend. En CloudAPPI ayudamos a las organizaciones a adoptar este patrón para llevar la gestión de APIs de Apigee (Google Cloud) a arquitecturas cloud-native basadas en Kubernetes.
Qué es el Apigee Adapter for Envoy
El Apigee Adapter for Envoy es un API gateway gestionado por Apigee que utiliza Envoy —el conocido proxy open source de edge y de servicio para aplicaciones cloud-native— para hacer de proxy del tráfico de APIs. En lugar de desplegar todo el runtime de Apigee en cada ubicación, ejecutas un gateway de huella reducida cerca de tus backends y dejas que se apoye en Apigee para lo esencial: autenticación y autorización de APIs (con API keys y OAuth), gestión de cuotas y analítica de APIs. Puedes ejecutarlo on-premises o en un entorno multicloud, y desplegarlo como servicio en un service mesh de Istio integrado con Apigee hybrid, lo que hace de Kubernetes su hogar natural.
El reto: gestionar APIs dentro de Kubernetes
Desplegar Apigee al completo en una nube privada es posible, pero una instalación completa es necesariamente grande y compleja para soportar funciones intensivas en datos como la gestión de claves, la monetización y la analítica. Replicar eso en cada centro de datos o clúster rara vez es deseable. Al mismo tiempo, llamar a un gateway centralizado y lejano en cada petición añade latencia de red y puede sacar el tráfico de APIs fuera de los límites de seguridad o cumplimiento que la empresa ha aprobado.
La solución: Envoy como gateway, Apigee como cerebro
El adaptador reparte responsabilidades entre un plano de gestión (management plane) y un plano de datos (data plane). Los componentes del plano de gestión se ejecutan en Google Cloud Platform, mientras que los del plano de datos —el proxy Envoy y el Apigee Remote Service— se ejecutan de forma remota, on-premises o en tu proveedor cloud (por ejemplo, dentro de tu clúster de Kubernetes). El flujo de una petición es el siguiente:
- Un consumidor o app cliente llama a un endpoint de API expuesto por el proxy Envoy.
- Envoy pasa el contexto de seguridad (mediante cabeceras HTTP) al Apigee Remote Service, que actúa como punto de decisión de políticas (PDP) e indica a Envoy si permite o deniega la petición.
- Si la llamada se permite, Envoy reenvía la petición al backend.
- El Apigee Remote Service consulta de forma asíncrona el plano de gestión y descarga el proxy, el API product y el resto de configuración que necesita para operar.
Por qué ejecutarlo en un clúster de Kubernetes
Como Envoy ya es el plano de datos de Istio, desplegar el Apigee Adapter for Envoy a través de un service mesh de Istio encaja de forma natural en un clúster de Kubernetes. Las ventajas son concretas: menor latencia para los servicios próximos entre sí, porque la gestión de APIs está junto al backend; acceso al conjunto completo de métricas, cuadros de mando y APIs de Edge Analytics; tráfico de APIs que permanece dentro de los límites aprobados por la empresa por seguridad o cumplimiento; comunicación asíncrona con Apigee, que captura y envía los datos de tráfico sin afectar a la latencia; y resiliencia: si se pierde la conexión a internet, Envoy sigue operando y procesando llamadas, y cuando se restablece la conectividad el adaptador se sincroniza con el plano de gestión de Apigee para descargar la última configuración.
Buenas prácticas para un despliegue en Kubernetes
Ejecuta el Apigee Remote Service y Envoy cerca de tus cargas de trabajo —idealmente en el mismo clúster o namespace que los backends que protegen— para maximizar la ventaja de latencia. Reutiliza los proxies Envoy que ya existen en tu mesh de Istio en lugar de introducir una capa de gateway aparte. Diseña para el modelo asíncrono y tolerante a desconexiones: valida la configuración de products y proxies en Apigee antes de que el Remote Service la descargue. Mantén las API keys y los flujos OAuth centralizados en Apigee para que la política de seguridad sea coherente en todos los clústeres. Y usa Edge Analytics para monitorizar el tráfico de cada clúster y alimentar tus decisiones de capacidad y fiabilidad.
Conclusión
El Apigee Adapter for Envoy te permite llevar una gestión de APIs de nivel empresarial —autenticación, cuotas y analítica— directamente a tu clúster de Kubernetes, sin el peso de un runtime completo de Apigee en cada ubicación. Ganas menor latencia, mejor control de cumplimiento y resiliencia ante caídas de conectividad, manteniendo una única fuente de verdad en Apigee. En CloudAPPI diseñamos e implementamos estas arquitecturas de API gateway sobre Kubernetes; si estás planteándote modernizar tu capa de APIs, nuestro equipo puede ayudarte a hacerlo con garantías.
