Balanceo de cargas HTTP(S) para API Gateway

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

La integración de la compatibilidad de balanceo de cargas  HTTP(S) de Google Cloud para API Gateway permite que tus backends sin servidores aprovechen todas las funciones de Cloud Load Balancing. Si combinas API Gateway y el balanceo de cargas de HTTP(S) mediante 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
  • Aprovecha Cloud CDN para mejorar el tiempo de respuesta de la puerta de enlace

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 figura, se muestra cómo se pueden usar los NEG sin servidores en el modelo de Cloud Load Balancing:

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

Como se ilustra antes, 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 puertas de enlace equivalentes en términos de funciones. Por ejemplo, todos los NEG deben tener la misma configuración de API implementada en cada puerta de enlace en regiones diferentes. 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 las solicitudes.

Limitaciones en NEG sin servidores y API Gateway

Se deben tener en cuenta algunas limitaciones cuando se usan NEG sin servidores a fin de integrar Cloud Load Balancing para API Gateway. En particular, ten en cuenta lo siguiente:

  • 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 aún no es compatible con la configuración de control de Ingress. 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 relacionadas con los NEG sin servidores y los servicios de backend en general, consulta Limitaciones.

Limitaciones en los NEG sin servidores en las opciones de configuración del servicio 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 el diseño del 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, los NEG sin servidores de App Engine solo se pueden combinar con los NEG sin servidores de App Engine, etcétera.
  • Un servicio de backend solo puede contener un NEG sin servidores por región.

Cuando se define una configuración de servicio de backend que se 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 los puertos
  • Solo se admiten protocolos de HTTP y HTTPS.
  • No se admiten los valores especificados en los campos relacionados con utilization o connection.

Los campos IAP, cdnPolicy y securityPolicy en 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 el servicio de API Gateway.

Próximos pasos