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

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

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, Cloud Functions o API Gateway.

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.
  • Una API Gateway que proporciona acceso a tus servicios a través de una API de REST coherente en todos los servicios, sin importar la implementación de estos. Esta función se encuentra en vista previa.

Casos de uso

Los NEG sin servidores son compatibles con los siguientes balanceadores de cargas:

Cuando el balanceador de cargas 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 dedicada que no se comparta con otros servicios
  • Asignar una sola URL a varias funciones o servicios sin servidores que entregan en el mismo dominio. En este documento, consulta Máscaras de URL.
  • Compartir el espacio de URL con otras plataformas de procesamiento de Google Cloud. Mediante el uso de varios servicios de backend, un solo balanceador de cargas 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.
  • 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.

Balanceador de cargas HTTP(S) externo global y balanceador de cargas HTTP(S) externo global (clásico)

La configuración de un balanceador de cargas HTTP(S) externo global o un balanceador de cargas HTTP(S) externo global (clásico) permite que tus apps sin servidores se integren a los servicios existentes en la nube. También puedes realizar las siguientes acciones:

  • 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.

Para obtener información sobre cómo configurar un balanceador de cargas con un backend de computación sin servidores, consulta la siguiente documentación:

La integración del balanceo de cargas de HTTP(S) con API Gateway permite que tus backends sin servidores aprovechen todas las funciones que proporciona Cloud Load Balancing. Para obtener más información, consulta Balanceo de cargas de HTTP(S) para la API de la puerta de enlace. Si deseas configurar el balanceo de cargas de HTTP(S) a fin de enrutar el tráfico a una API de la puerta de enlace, consulta Comienza a usar el balanceo de cargas de HTTP(S) para la API de la puerta de enlace. Esta función se encuentra en Vista previa.

Balanceador de cargas HTTP(S) regional externo

El uso de un balanceador de cargas HTTP(S) regional externo te permite ejecutar cargas de trabajo con requisitos reglamentarios o de cumplimiento en los backends de Cloud Run. Por ejemplo, si necesitas que la configuración de red y la finalización del tráfico de tu aplicación residan en una región específica, un balanceador de cargas HTTP(S) regional externo suele ser la opción preferida para cumplir con los controles jurisdiccionales necesarios.

Si deseas obtener información sobre cómo configurar un balanceador de cargas HTTP(S) regional externo con un backend de computación sin servidores, consulta Configura un balanceador de cargas HTTP(S) regional externo con Cloud Run.

Balanceador de cargas HTTP(S) interno

Cuando el balanceo de cargas HTTP(S) interno se configura con backends (de Cloud Run), puedes hacer lo siguiente:

  • Habilita las funciones avanzadas de administración de tráfico del balanceo de cargas HTTP(S) interno, como la inserción de fallas, las reescrituras de encabezados, los redireccionamientos, la división de tráfico y mucho más para tus servicios de Cloud Run.
  • Migra sin problemas servicios heredados de Compute Engine, GKE o entornos locales a Cloud Run y aprovecha la división del tráfico basada en el peso para cambiar el tráfico de forma gradual a Cloud Run sin tiempo de inactividad.
  • Protege tus servicios de Cloud Run con los Controles del servicio de VPC.
  • Establece un punto de entrada interno único que aplique la política para los servicios que se ejecutan en Cloud Run, Compute Engine y GKE.

Si deseas obtener información sobre cómo configurar un balanceador de cargas HTTP(S) interno con un backend de computación sin servidores, consulta Configura un balanceador de cargas HTTP(S) interno con Cloud Run.

En el resto de esta página, se analiza cómo usar NEG sin servidores con los balanceadores de cargas HTTP(S).

Para obtener más información sobre otros tipos de NEG, consulta Descripción general de los grupos de extremos de red.

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, API Gateway o Cloud Functions que resida en la misma región que el NEG.

Cuando creas un NEG sin servidores, debes especificar el nombre de dominio completamente calificado (FQDN) del servicio de Cloud Run, App Engine, API Gateway 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. El extremo apunta a una aplicación sin servidores o a una máscara de URL. El balanceador de cargas funciona como frontend para la aplicación de computación sin servidores y actúa como proxy para el tráfico al extremo especificado. Sin embargo, si el servicio de backend contiene varios NEG sin servidores en diferentes regiones, el balanceador de cargas envía tráfico al NEG en la región más cercana para minimizar la latencia de la solicitud.

Nivel de red

Para los balanceadores de cargas HTTP(S) externos globales, 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.

Los balanceadores de cargas HTTP(S) regionales externos siempre son nivel Estándar.

Los balanceadores de cargas HTTP(S) internos siempre son nivel Premium.

Componentes del balanceo de cargas

Un balanceador de cargas con un backend de NEG sin servidores requiere una configuración especial solo para el servicio de backend. La configuración de frontend es la misma que la de cualquier otro balanceador de cargas de Google Cloud basado en proxy. Además, los balanceadores de cargas HTTP(S) internos requieren una subred de solo proxy para ejecutar los proxies de Envoy en tu nombre.

En los siguientes diagramas, se muestra un ejemplo de implementación de NEG sin servidores.

HTTP(S) externo

En este diagrama, se muestra cómo un NEG sin servidores se ajusta a una arquitectura de balanceador de cargas HTTP(S) externo global.

Balanceo de cargas HTTP(S) externo global para apps sin servidores
Balanceo de cargas HTTP(S) externo global para apps sin servidores

En este diagrama, se muestra cómo un NEG sin servidores se ajusta a una arquitectura de balanceador de cargas HTTP(S) regional externo.

Balanceo de cargas  HTTP(S) regional externo para apps sin servidores
Balanceo de cargas HTTP(S) regional externo para apps sin servidores

HTTP(S) interno

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

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

Componentes de frontend

No se requiere ninguna configuración especial de frontend para el balanceo de cargas con backends de NEG sin servidores. Las reglas de reenvío se usan para enrutar el tráfico por dirección IP, puerto y protocolo a un proxy de destino. Luego, el proxy de destino finaliza las conexiones de los clientes.

Los balanceadores de cargas HTTP(S) usan los mapas de URL para configurar el enrutamiento basado en URL de las solicitudes a los servicios de backend correspondientes.

Para obtener más detalles sobre cada uno de estos componentes, consulta las secciones de arquitectura de las descripciones generales de los balanceadores de cargas específicos:

Servicio de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Los balanceadores de cargas usan la información en el servicio de backend para dirigir el tráfico entrante a uno o más backends conectados. Los NEG sin servidores se pueden usar como backends para ciertos balanceadores de cargas.

Un servicio de backend global (que usan los balanceadores de cargas HTTP(S) externos globales) puede tener varios NEG sin servidores conectados a él, pero solo un NEG sin servidores por región. Un servicio de backend regional (que usan los balanceadores de cargas HTTP(S) internos y regionales externos) solo puede tener un NEG sin servidores conectado a él.

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 sin servidores y tienes varios servicios 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

Un backend de NEG sin servidores puede apuntar a un solo servicio de Cloud Run (o App Engine o Cloud Functions, si corresponde) 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 asignar la solicitud al servicio correspondiente.

Las máscaras de URL son una función opcional que facilita la configuración de NEG sin servidores cuando la aplicación sin servidores consta de varios servicios de Cloud Run, Cloud Functions o App Engine. Los NEG sin servidores que se usan con balanceadores de cargas HTTP(S) internos solo pueden usar una máscara de URL que apunte a servicios de Cloud Run.

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 aprender a construir y configurar una máscara de URL para un NEG sin servidores, consulta los siguientes vínculos:

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 las aplicaciones sin servidores que residen en la misma región en la que se crea el NEG.
  • Para un balanceador de cargas que usa un backend de NEG sin servidores, el NEG sin servidores debe crearse en el mismo proyecto que los servicios de respaldo de Cloud Run, App Engine, API Gateway o Cloud Functions a los que apunta el NEG. Es posible que veas solicitudes con errores si conectas un servicio que no está en el mismo proyecto que el NEG sin servidores.
  • Un balanceador de cargas configurado con un NEG sin servidores no puede detectar si la app o el servicio subyacentes sin servidores funcionan como se espera. Esto significa que, incluso si tu servicio muestra errores, el balanceador de cargas seguirá dirigiendo el tráfico hacia él. Asegúrate de probar de forma exhaustiva las versiones nuevas de los servicios antes de enrutar el tráfico de usuarios a ellos.

Limitaciones con los servicios de backend

Las siguientes limitaciones se aplican a los servicios de backend que tienen un backend de NEG sin servidores:

  • Un servicio de backend global 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.
  • Un servicio de backend regional solo puede tener un NEG sin servidores conectado a él.
  • El servicio de backend debe crearse en el mismo proyecto que el NEG sin servidores y el servicio de respaldo de Cloud Run, App Engine, API Gateway o Cloud Functions. Si configuras una implementación de VPC compartida con referencia del servicio entre proyectos, los componentes de frontend del balanceador de cargas (dirección IP, regla de reenvío, proxy de destino y mapa de URL) se pueden crear en un proyecto diferente.
  • 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.

Se aplican limitaciones adicionales según el tipo de balanceador de cargas y el backend sin servidores.

Limitaciones con el balanceo de cargas HTTP(S) interno

  • Los NEG sin servidores que se usan con balanceadores de cargas HTTP(S) internos solo pueden apuntar a servicios de Cloud Run.
  • No puedes usar la consola de Google Cloud para configurar un balanceador de cargas HTTP(S) interno con un backend de NEG sin servidores.
  • Debe haber al menos una VM en la red de VPC para que puedas configurar un balanceador de cargas HTTP(S) interno con un backend sin servidores.

Limitaciones con balanceadores de cargas HTTP(S) regionales externos

  • Los NEG sin servidores que se usan con balanceadores de cargas HTTP(S) regionales externos solo pueden apuntar a servicios de Cloud Run.
  • No puedes usar la consola de Google Cloud para configurar un balanceador de cargas HTTP(S) regional externo con un backend de NEG sin servidores.
  • Debe haber al menos una VM en la red de VPC para que puedas configurar un balanceador de cargas HTTP(S) regional externo con un backend sin servidores.

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.

Limitaciones con API Gateway

Para obtener más información, consulta Limitaciones en los NEG sin servidores y API Gateway.

Precios

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

¿Qué sigue?