Balanceo de cargas para API Gateway

La integración de la compatibilidad con el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones clásico para API Gateway permite que tus backends sin servidores aprovechen todas las funciones que proporciona Cloud Load Balancing. Si combinas API Gateway con un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico a través de un grupo de extremos de red sin servidores (NEG sin servidores), puedes hacer lo siguiente:

  • Alojar puertas de enlace con dominios de marca personalizados
  • Configurar TLS para puertas de enlace mediante certificados emitidos por una autoridad certificada preferida
  • Crear un punto de entrada común para el enrutamiento de una puerta de enlace a varios backends
  • Implementar puertas de enlace en varias regiones geográficas para una alta disponibilidad sin administrar las URL de cada región
  • Proteger las puertas de enlace con Cloud Armor
  • Mejorar el tiempo de respuesta de la puerta de enlace aprovechando Cloud CDN

Usa un NEG sin servidores para API Gateway

Un grupo de extremos de red (NEG) especifica un grupo de extremos de backend para un balanceador de cargas. Un NEG sin servidores es un backend que apunta a un backend sin servidores alojado en Google, como Cloud Run, App Engine o API Gateway. Un backend de NEG sin servidores para API Gateway puede representar lo siguiente:

  • Una instancia de API Gateway
  • Un grupo de puertas de enlace configuradas con la misma configuración de API

En la siguiente imagen, se muestra cómo se pueden usar los NEG sin servidores en el modelo de balanceo de cargas de Cloud:

diagrama de NEG sin servidores como backend para puertas de enlace multirregionales

Como se ilustró en un ejemplo anterior, varios NEG sin servidores pueden administrar un servicio de backend. Cada NEG sin servidores puede contener una sola instancia de API Gateway o usar una máscara de URL para apuntar a varias puertas de enlace. Debido a que todos los NEG que actúan como un servicio de backend se usan para el balanceo de cargas, deben representar implementaciones de puerta de enlace funcionalmente equivalentes. Por ejemplo, todos los NEG deben tener la misma configuración de API implementada en cada puerta de enlace en diferentes regiones. Si un servicio de backend contiene varios NEG, el balanceador de cargas balanceará el tráfico entre estos NEG y, al mismo tiempo, minimizará la latencia de la solicitud.

Limitaciones en NEG sin servidores y API Gateway

Se deben tener en cuenta algunas limitaciones cuando se usan NEG sin servidores para integrar Cloud Load Balancing en API Gateway. En particular:

  • Los NEG sin servidores no pueden tener ningún extremo de red, como direcciones IP o puertos, conectados.
  • Los NEG sin servidores solo pueden apuntar a las instancias de API Gateway que residen en la misma región donde se crea el NEG.
  • Los NEG sin servidores solo pueden apuntar a las instancias de API Gateway creadas en el mismo proyecto que el balanceador de cargas mediante el backend de NEG sin servidores.
  • API Gateway no admite la configuración de control de entrada. Como resultado, no se puede inhabilitar el acceso a API Gateway a través de la URL de puerta de enlace generada por el servicio y garantizar que el balanceador de cargas controle todo el tráfico.

Para obtener más información sobre las restricciones relativas a NEG sin servidores y a los servicios de backend en general, consulta Limitaciones.

Limitaciones en los NEG sin servidores en las configuraciones de servicios de backend

Un servicio de backend define cómo Cloud Load Balancing distribuye el tráfico. La configuración del servicio de backend contiene un conjunto de valores, como el protocolo que se usa para conectarse a backends, varios parámetros de configuración de distribución y sesión, verificaciones de estado y tiempos de espera. En el caso de los NEG sin servidores que se usan como servicio de backend para API Gateway, esta configuración proporciona un control detallado sobre el comportamiento del balanceador de cargas.

La definición de recursos de un servicio de backend tiene las siguientes implicaciones para tu diseño de balanceo de cargas:

  • Los NEG sin servidores no se pueden usar con otros tipos de NEG en el mismo servicio de backend. Por ejemplo, no puedes enrutar a un clúster de GKE y una instancia de API Gateway desde el mismo servicio de backend.
  • Todos los NEG sin servidores combinados en un servicio de backend deben usar el mismo tipo de backend. Esto significa que los NEG sin servidores de API Gateway solo se pueden combinar con otros NEG sin servidores de API Gateway, y los NEG sin servidores de App Engine solo se pueden combinar con los NEG sin servidores de App Engine.
  • Un servicio de backend solo puede contener un NEG sin servidores por región.

Cuando defines una configuración de servicio de backend que enruta a un NEG sin servidores, se aplican las siguientes limitaciones de campo:

  • No se puede especificar balancingMode.
  • El campo healthCheck debe estar vacío y no se puede especificar.
  • No se pueden especificar puertos
  • Solo se admiten protocolos HTTP y HTTPS.
  • No se admiten los valores especificados en los campos relacionados con utilization o connection.

Los campos IAP, cdnPolicy y securityPolicy de la configuración del servicio de backend son válidos para los NEG sin servidores. Estos campos se pueden usar para configurar Identity-Aware Proxy, Cloud CDN y Cloud Armor, respectivamente, con tu servicio de API Gateway.

Próximos pasos