Descripción general de los grupos de extremos de red sin servidores

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 servicio de Cloud Run, App Engine o Cloud Functions.

Un NEG sin servidores puede representar lo siguiente:

  • Un servicio de Cloud Run o un grupo de servicios que comparten el mismo patrón de URL
  • Una función de Cloud Functions o un grupo de funciones que comparten el mismo patrón de URL
  • Una app de App Engine (estándar o flexible), un servicio específico dentro de una app o, incluso, una versión específica de una app

Cuando el balanceo de cargas de HTTP(S) está habilitado para apps sin servidores, puedes hacer lo siguiente:

  • Configurar la app sin servidores para entregar desde una dirección IP IPv4 o IPv6 dedicada que no se comparta con otros servicios
  • Mapear una sola URL a varias aplicaciones sin servidores idénticas a nivel funcional en diferentes regiones, lo que permite enrutar las solicitudes a la región más cercana al usuario. Esto es compatible solo con Cloud Run (completamente administrado) y Cloud Functions.
  • Volver a usar los mismos certificados SSL y claves privadas que usas para Compute Engine, Google Kubernetes Engine y Cloud Storage. Esto quita la necesidad de administrar certificados separados para las apps sin servidores

La configuración del balanceo de cargas de HTTP(S) también permite que las apps sin servidores se integren a los servicios de Cloud existentes. Puede hacer lo siguiente:

  • Compartir el espacio de URL con otras tecnologías de Google Cloud. Mediante el uso de varios servicios de backend, un solo balanceador de cargas de HTTP(S) externo puede enviar tráfico a Cloud Run (completamente administrado), App Engine, Cloud Functions, Compute Engine, Google Kubernetes Engine y Cloud Storage según el host o la ruta de acceso de la URL de solicitud.
  • Proteger el servicio con Google Cloud Armor, un producto de seguridad WAF o contra DSD disponible para todos los servicios a los que se accede a través de un balanceador de cargas de HTTP(S) externo. Ten en cuenta que hay algunas limitaciones asociadas con esta capacidad, en especial para Cloud Run (completamente administrado) y App Engine.
  • Habilitar el servicio para optimizar la entrega con Cloud CDN. Con Cloud CDN, puedes almacenar contenido en caché cerca de los usuarios. Cloud CDN proporciona capacidades como la invalidación de caché y las URL firmadas de Cloud CDN.
  • Usar la infraestructura perimetral de Google para establecer las conexiones de HTTP(S) del usuario más cerca de este, lo que disminuye la latencia.

En el resto de este documento, se analiza cómo usar NEG sin servidores con el balanceo de cargas de HTTP(S). No puedes usar NEG sin servidores con otros tipos de balanceadores de cargas.

Para obtener más información sobre otros tipos de NEG, consulta lo siguiente:

Tipos de extremos

Los NEG sin servidores no tienen extremos de red, como puertos o direcciones IP. Solo pueden apuntar a un servicio existente de Cloud Run (completamente administrado), App Engine o Cloud Functions que resida en la misma región que el NEG.

Cuando creas un NEG sin servidores, especificas el nombre de dominio completamente calificado (FQDN) del servicio de Cloud Run (completamente administrado), App Engine o Cloud Functions.. El extremo es de tipo SERVERLESS. Otros tipos de extremos no son compatibles con un NEG sin servidores.

Un NEG sin servidores no puede tener más de un extremo. Debido a que solo se permite un extremo en cada NEG sin servidores, el balanceador de cargas funciona solo como frontend y envía el tráfico al extremo sin servidores especificado. Sin embargo, si el servicio de backend contiene varios NEG sin servidores, el balanceador de cargas balancea el tráfico entre estos NEG, lo que minimiza la latencia de la solicitud.

Nivel de red

Puedes usar un NEG sin servidores en un balanceador de cargas con niveles de servicio de red Estándar o Premium. El nivel Premium solo es necesario si deseas configurar NEG sin servidores en varias regiones.

Componentes del balanceo de cargas

Así es como un NEG sin servidores se ajusta al modelo de balanceo de cargas de HTTP(S).

Balanceo de cargas de HTTPS simple (haz clic para agrandar)
Balanceo de cargas de HTTP(S) para apps sin servidores

Regla de reenvío

La regla de reenvío es parte de la configuración de frontend y contiene una dirección IP externa, la versión de IP (IPv4 o IPv6), un protocolo HTTP o HTTPS (incluye HTTP/2) y un número de puerto (80 o 443).

Proxy de destino

Los NEG sin servidores solo se pueden usar con proxies de destino HTTP y HTTPS. Los servicios que usan NEG sin servidores no se pueden usar con proxies de destino TCP o SSL.

Mapa de URL

La selección de reenvío para un balanceador de cargas de HTTP(S) externo se basa en un mapa de URL. Con un mapa de URL, los proxies HTTP(S) de destino determinan el servicio de backend que se usará cuando se verifique el nombre de host de la solicitud y la ruta de acceso en el mapa de URL. Los balanceadores de cargas pueden tener varios servicios de backend a los que se hace referencia desde el mapa de URL. Cada servicio de backend se puede asociar con un tipo de backend diferente. Por ejemplo, puedes tener un servicio de backend para un NEG sin servidores y otro servicio de backend para grupos de instancias de Compute Engine.

Servicio de backend

Los NEG sin servidores se pueden usar como backends para servicios de backend en un balanceador de cargas. Un servicio de backend puede estar respaldado por varios NEG sin servidores, pero cada NEG sin servidores solo puede apuntar al FQDN para un único servicio de Cloud Run (completamente administrado), App Engine o Cloud Functions o a una máscara de URL que apunta a varios servicios que entregan en el mismo dominio.

Una máscara de URL es una plantilla de esquema de URL que indica al backend de NEG sin servidores cómo mapear la solicitud del usuario al servicio correcto. Las máscaras de URL son útiles si usas un dominio personalizado para la aplicación y tienes varios servicios de Cloud Run (completamente administrado), Cloud Functions o App Engine que entregan en el mismo dominio. En esos casos, en lugar de crear un NEG sin servidores independiente para cada servicio de Cloud Run (completamente administrado), App Engine o Cloud Functions, puedes crear el NEG con una máscara de URL genérica para el dominio personalizado (por ejemplo, example.com/<service> ) y permitir que el NEG extraiga el nombre del servicio de la URL de la solicitud. Para obtener más información y ejemplos, consulta Máscaras de URL.

Hay restricciones adicionales que se deben tener en cuenta cuando se agrega un NEG sin servidores como backend. Para obtener más información, consulta Limitaciones.

Máscaras de URL

Las máscaras de URL son una función opcional que facilita la configuración de NEG sin servidores cuando la aplicación consta de varios servicios de Cloud Run (completamente administrado), Cloud Functions o App Engine. Un backend de NEG sin servidores puede apuntar a un solo servicio de Cloud Run (completamente administrado) (o App Engine o Cloud Functions) o a una máscara de URL que apunte a varios servicios.

Una máscara de URL es una plantilla del esquema de URL. El NEG sin servidores usará esta plantilla (por ejemplo, example.com/<service>) para extraer el nombre del servicio de la URL de la solicitud entrante y mapear la solicitud al servicio correspondiente.

Las máscaras de URL son útiles si la app sin servidores está mapeada a un dominio personalizado en lugar de la dirección predeterminada que proporciona Google Cloud. Con un dominio personalizado como example.com, podrías tener varios servicios de Cloud Run (completamente administrado), Cloud Functions o App Engine implementados en diferentes subdominios o rutas de acceso en el mismo dominio. En esos casos, en lugar de crear un backend de NEG sin servidores independiente para cada servicio de Cloud Run (completamente administrado), App Engine o Cloud Functions, puedes crear un solo NEG sin servidores con una máscara de URL genérica para el dominio personalizado (por ejemplo, example.com/<service>) y permitir que el NEG extraiga el nombre del servicio de la URL de la solicitud.

En la siguiente ilustración, se muestra un balanceador de cargas de HTTP(S) externo con un solo servicio de backend y NEG sin servidores que usa una máscara de URL para mapear solicitudes de usuarios a diferentes servicios.

Distribución del tráfico en apps sin servidores (haz clic para ampliar)
Usa una máscara de URL para distribuir el tráfico a diferentes servicios

Las máscaras de URL funcionan mejor cuando los servicios de la aplicación usan un esquema de URL predecible. La ventaja de usar una máscara de URL en lugar de un mapa de URL es que no necesitas crear NEG sin servidores separados para los servicios login y search. Tampoco necesitas modificar la configuración del balanceador de cargas cada vez que agregues un servicio nuevo a la aplicación.

Si deseas aprender a construir y configurar una máscara de URL para un NEG sin servidores, consulta Configura NEG sin servidores.

Limitaciones

  • Un NEG sin servidores no puede tener ningún extremo de red, como una dirección IP o un puerto.
  • Los NEG sin servidores solo pueden apuntar a los servicios de Cloud Run (completamente administrado), App Engine o Cloud Functions que residen en la misma región donde se crea el NEG.
  • Los balanceadores de cargas que usan backends de NEG sin servidores deben crearse en el mismo proyecto que los servicios de Cloud Run (completamente administrado), App Engine o Cloud Functions a los que apunta el NEG.
  • Cloud Monitoring no es compatible con backends de NEG sin servidores. Los servicios de backend con otros tipos de backends no se ven afectados.
  • Un balanceador de cargas de HTTP(S) externo configurado con un NEG sin servidores no puede detectar si el recurso subyacente sin servidores, como un servicio de App Engine, Cloud Functions o Cloud Run (completamente administrado), funciona como se espera. Esto significa que si el servicio muestra errores en una región, pero la infraestructura general de Cloud Run (completamente administrado), Cloud Functions o App Engine en esa región funciona con normalidad, el balanceador de cargas de HTTP(S) externo no dirigirá el tráfico a otras regiones de forma automática. Asegúrate de probar de forma exhaustiva las versiones nuevas de los servicios antes de enrutar el tráfico de usuarios a ellos.

Limitaciones asociadas con los servicios de backend que tienen un backend de NEG sin servidores

  • Un servicio de backend solo puede contener un NEG sin servidores por región. Si deseas combinar varios NEG sin servidores en un solo servicio de backend, todos los NEG deben representar implementaciones equivalentes en diferentes regiones de forma funcional. Por ejemplo, los NEG pueden apuntar al mismo servicio de Cloud Run (completamente administrado), App Engine o Cloud Functions implementado en diferentes regiones.
  • No puedes modificar el tiempo de espera del servicio de backend predeterminado de 30 segundos de un servicio de backend de NEG sin servidores. Si intentas modificar la configuración del servicio de backend para aumentar el tiempo de espera (mediante la configuración de la propiedad resource.timeoutSec), se produce el siguiente error: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
  • Todos los NEG sin servidores combinados en un servicio de backend también deben usar el mismo tipo de backend. Esto significa que los NEG sin servidores de Cloud Run (completamente administrado) solo se pueden combinar con otros NEG sin servidores de Cloud Run (completamente administrado), los NEG sin servidores de App Engine solo se pueden combinar con los NEG sin servidores de App Engine, etcétera.
  • No puedes mezclar NEG sin servidores con otros tipos de NEG (NEG zonales o de Internet) en el mismo servicio de backend. Por ejemplo, esto quiere decir que no puedes enrutar a un clúster de GKE y un servicio de Cloud Run (completamente administrado) desde el mismo servicio de backend.
  • Cuando configuras servicios de backend que enrutan a NEG sin servidores, ciertos campos están restringidos:
    • No puedes especificar un modo de balanceo. Es decir, los valores RATE, UTILIZATION y CONNECTION no tienen efecto en la distribución de tráfico del balanceador de cargas.
    • Las verificaciones de estado no son compatibles con backends sin servidores. Por lo tanto, los servicios de backend que contienen backends de NEG sin servidores no se pueden configurar con verificaciones de estado.
  • No puedes usar el comando gcloud compute backend-services edit para modificar un servicio de backend con un backend de NEG sin servidores. Como solución alternativa, usa el comando gcloud compute backend-services update en su lugar.

Es posible que se apliquen limitaciones adicionales según la plataforma de computación sin servidores que uses.

Limitaciones con Cloud Run (completamente administrado)

  • Identity-Aware Proxy (IAP) no funciona con Cloud Run (completamente administrado).
  • No puedes inhabilitar las URL que Google Cloud asigna de forma automática a los servicios de Cloud Run (completamente administrado). Los usuarios que ya tienen la URL predeterminada del servicio de Cloud Run (completamente administrado) pueden omitir el balanceador de cargas y dirigirse a la URL del servicio. Esto significa que, aunque puedes configurar las políticas de seguridad de Google Cloud Armor a través del balanceador de cargas, los usuarios con la URL predeterminada pueden eludir estas políticas.

Limitaciones con Cloud Functions

  • IAP no funciona con Cloud Functions.
  • No puedes inhabilitar las URL que Google Cloud asigna de forma automática a las funciones de Cloud Functions. Sin embargo, puedes usar la configuración de entrada internal-and-gclb para permitir solo el tráfico interno y el tráfico enviado a una IP pública expuesta por el balanceador de cargas de HTTP(S) externo. El tráfico enviado a cloudfunctions.net o a cualquier otro dominio personalizado configurado a través de Cloud Functions está bloqueado. Esto evita que los usuarios eludan los controles de acceso (como las políticas de seguridad de Google Cloud Armor) configurados a través del balanceador de cargas de HTTP(S) externo.

Limitaciones con App Engine

  • App Engine no admite el balanceo de cargas multirregión. Esto se debe a que App Engine requiere 1 región por proyecto.
  • Solo se permite una política de IAP en la ruta de la solicitud. Por ejemplo, si ya configuraste una política de IAP en el servicio de backend, no debes establecer otra en la app de App Engine.
  • Te recomendamos usar controles de entrada para que la app solo reciba solicitudes enviadas desde el balanceador de cargas (y la VPC, si la usas). De lo contrario, los usuarios pueden usar la URL de App Engine de tu app para omitir el balanceador de cargas, las políticas de seguridad de Google Cloud Armor, los certificados SSL y las claves privadas que se pasan a través del balanceador de cargas.

Precios

Para ver la información de precios de los balanceadores de cargas de HTTP(S) externos con NEG sin servidores, consulta Precios de red.

Próximos pasos