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 una de las siguientes opciones:

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

Cuando el balanceo de cargas de HTTP(S) externo 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. Mediante la ejecución de aplicaciones en diferentes regiones, las solicitudes se pueden enrutar a la región más cercana al usuario. Mapear una sola URL a varias aplicaciones sin servidores idénticas a nivel funcional solo es compatible con Cloud Run y Cloud Functions.
  • Volver a usar los mismos certificados SSL y claves privadas que usas para Compute Engine, Google Kubernetes Engine y Cloud Storage. Volver a usar los mismos certificados quita la necesidad de administrar certificados separados para las apps sin servidores.

La configuración del balanceo de cargas de HTTP(S) externo también permite que las apps sin servidores se integren a los servicios de Cloud existentes. Puedes realizar 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 varios tipos de backend. El balanceador de cargas selecciona el servicio de backend correcto según el host o la ruta de acceso de la URL de la 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. Hay algunas limitaciones asociadas con esta capacidad, en especial para Cloud Run y App Engine.
  • Habilitar el servicio para optimizar la entrega con Cloud CDN. Cloud CDN almacena en caché el contenido 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.

Los grupos de extremos de red (NEG) sin servidores son compatibles con los balanceadores de cargas de HTTP(S) externos globales. No puedes usar NEG sin servidores con balanceadores de cargas de HTTP(S) regionales externos ni con ningún otro tipo de balanceador 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, 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, 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

En este diagrama, se muestra cómo un NEG sin servidores se ajusta al modelo de balanceo de cargas de HTTP(S).

Balanceo de cargas 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. Cada regla de reenvío tiene 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 en un balanceador de cargas. Un servicio de backend puede tener varios NEG sin servidores. Cada NEG sin servidores puede apuntar a cualquiera de las siguientes opciones:

  • El FQDN para una única función o servicio
  • Una máscara de URL que apunta a varias funciones o 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, Cloud Functions o App Engine que entregan en el mismo dominio. En lugar de crear un NEG sin servidores independiente para cada función o servicio, puedes crear el NEG con una máscara de URL genérica para el dominio personalizado. Para obtener más información y ejemplos, consulta Máscaras de URL.

Para conocer las restricciones adicionales cuando se agrega un NEG sin servidores como backend, consulta Limitaciones.

Máscaras de URL

Las máscaras de URL opcionales facilitan la configuración de NEG sin servidores cuando la aplicación tiene varios servicios de Cloud Run, Cloud Functions o App Engine. Un backend de NEG sin servidores puede apuntar a un solo servicio de Cloud Run (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 usa esta plantilla para 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 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, puedes crear un solo NEG sin servidores con una máscara de URL genérica para el dominio personalizado (por ejemplo, example.com/<service>). El NEG extrae 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 agregas un servicio nuevo a la aplicación.

Si deseas obtener información sobre cómo crear y configurar una máscara de URL para un NEG sin servidores, consulta Configura un balanceador de cargas de HTTP(S) con un NEG sin servidores.

Limitaciones

  • No puedes usar NEG sin servidores como backends para balanceadores de cargas HTTP(S) regionales externos.
  • 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, 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, App Engine o Cloud Functions a los que apunta el NEG.
  • Un balanceador de cargas de HTTP(S) externo configurado con un NEG sin servidores no puede detectar si el servicio subyacente funciona como se espera. Esto significa que si tu servicio muestra errores en una región, pero la infraestructura general en esa región funciona con normalidad, tu balanceador de cargas de HTTP(S) externo no puede dirigir el tráfico de manera automática a otras regiones. 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 puede tener un NEG sin servidores por región. Para 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, App Engine o Cloud Functions implementado en diferentes regiones.
  • La configuración de tiempo de espera del servicio de backend no se aplica a los servicios de backend con backends de NEG sin servidores. Intentar modificar la propiedad resource.timeoutSec del servicio de backend da como resultado el siguiente error: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Para los servicios de backend con backends de NEG sin servidores, el tiempo de espera predeterminado es de 60 minutos. Este tiempo de espera no se puede configurar. Si tu aplicación necesita conexiones de larga duración, configura tus clientes para que reintenten las solicitudes en caso de falla.
  • 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 solo se pueden combinar con otros NEG sin servidores de Cloud Run, 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, no puedes enrutar a un clúster de GKE y un servicio de Cloud Run 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

  • El balanceo de cargas de HTTP(S) externo con NEG sin servidores no es compatible con Cloud Run for Anthos.

Limitaciones con Cloud Functions

  • IAP no funciona con Cloud Functions.

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.

¿Qué sigue?