Configurar un balanceador de carga de aplicaciones externo global con Cloud Run, App Engine o Cloud Run functions

En esta página se explica cómo crear un balanceador de carga de aplicaciones externo para enrutar solicitudes a back-ends sin servidor. En este caso, el término "sin servidor" hace referencia a los siguientes productos de computación sin servidor:

• App Engine
• Cloud Run Functions
• Cloud Run

La integración de balanceadores de carga de aplicaciones externos con API Gateway permite que tus backends sin servidor aprovechen todas las funciones que ofrece Cloud Load Balancing. Para configurar un balanceador de carga de aplicación externo que enrute el tráfico a una API Gateway, consulta Primeros pasos con un balanceador de carga de aplicación externo para API Gateway. La compatibilidad con el balanceador de carga de aplicaciones externo para API Gateway está en vista previa.

Los NEGs sin servidor te permiten usar Google Cloud aplicaciones sin servidor con balanceadores de carga de aplicaciones externos. Una vez que hayas configurado un balanceador de carga con el backend de NEG sin servidor, las solicitudes al balanceador de carga se dirigirán al backend de la aplicación sin servidor.

Para obtener más información sobre los NEGs sin servidor, consulta la descripción general de NEGs sin servidor.

Antes de empezar

1. Despliega un servicio de App Engine, Cloud Run functions o Cloud Run.
2. Si aún no lo has hecho, instala la CLI de Google Cloud.
3. Configura los permisos.
4. Añade un recurso de certificado SSL.

Desplegar un servicio de App Engine, Cloud Run functions o Cloud Run

En estas instrucciones, se presupone que ya tienes un servicio Cloud Run, Cloud Run functions o App Engine en ejecución.

En el ejemplo de esta página, hemos usado la guía de inicio rápido de Python de Cloud Run para desplegar un servicio de Cloud Run en la región us-central1. En el resto de esta página se explica cómo configurar un balanceador de carga de aplicaciones externo que utilice un backend de NEG sin servidor para enrutar las solicitudes a este servicio.

Si aún no has implementado una aplicación sin servidor o quieres probar una NEG sin servidor con una aplicación de ejemplo, usa una de las siguientes guías de inicio rápido. Puedes crear una aplicación sin servidor en cualquier región, pero debes usar la misma región más adelante para crear el NEG sin servidor y el balanceador de carga.

Cloud Run

Para crear una aplicación Hello World sencilla, empaquétala en una imagen de contenedor y, luego, despliega la imagen de contenedor en Cloud Run. Consulta la guía de inicio rápido: compilación y despliegue.

Si ya has subido un contenedor de muestra a Container Registry, consulta la guía de inicio rápido sobre cómo desplegar un contenedor de ejemplo prediseñado.

Cloud Run Functions

Consulta Cloud Run Functions: guía de inicio rápido de Python.

App Engine

Consulta las siguientes guías de inicio rápido de App Engine para Python 3:

• Entorno estándar
• Entorno flexible

Instalar Google Cloud CLI

Instala Google Cloud CLI. Consulta la descripción general de gcloud para obtener información conceptual y sobre la instalación de la herramienta.

Si no has ejecutado la CLI de gcloud anteriormente, ejecuta primero gcloud init para inicializar tu directorio de gcloud.

Configurar permisos

Para seguir esta guía, debes crear un NEG sin servidor y un balanceador de carga HTTP(S) externo en un proyecto. Debes ser propietario o editor de un proyecto, o bien tener los siguientes roles de gestión de identidades y accesos de Compute Engine:

Reservar una dirección IP externa

Ahora que tus servicios están en funcionamiento, configura una dirección IP externa estática global que tus clientes usan para llegar a tu balanceador de carga.

gcloud compute addresses create EXAMPLE_IP \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

gcloud compute addresses describe EXAMPLE_IP \
    --format="get(address)" \
    --global

Crear un recurso de certificado SSL

Para crear un balanceador de carga HTTPS, debes añadir un recurso de certificado SSL al frontend del balanceador de carga. Crea un recurso de certificado SSL con un certificado SSL gestionado por Google o un certificado SSL autogestionado.

• Certificados gestionados por Google. Te recomendamos que uses certificados gestionados por Google porque Google Cloud obtiene, gestiona y renueva estos certificados automáticamente. Para crear un certificado gestionado por Google, debes tener un dominio y los registros DNS de ese dominio para que se pueda aprovisionar el certificado.

  Además, debe actualizar el registro A de DNS del dominio para que apunte a la dirección IP del balanceador de carga que ha creado en el paso anterior. Si tiene varios dominios en un certificado gestionado por Google, debe actualizar los registros DNS de todos los dominios y subdominios para que apunten a la dirección IP de su balanceador de carga. Para obtener instrucciones detalladas, consulta Usar certificados gestionados por Google.

• Certificados autofirmados. Si no quieres configurar un dominio en este momento, puedes usar un certificado SSL autofirmado para hacer pruebas.

En este ejemplo se da por hecho que ya has creado un recurso de certificado SSL.

Si quieres probar este proceso sin crear un recurso de certificado SSL (o un dominio, como requieren los certificados gestionados por Google), puedes seguir las instrucciones de esta página para configurar un balanceador de carga HTTP.

Crear el balanceador de carga

En el siguiente diagrama, el balanceador de carga usa un backend de NEG sin servidor para dirigir las solicitudes a un servicio de Cloud Run sin servidor. En este ejemplo, hemos usado la guía de inicio rápido de Python de Cloud Run para desplegar un servicio de Cloud Run.

Como las comprobaciones de estado no se admiten en los servicios de backend con backends de NEG sin servidor, no es necesario que cree una regla de firewall que permita las comprobaciones de estado si el balanceador de carga solo tiene backends de NEG sin servidor.

Conectar tu dominio a tu balanceador de carga

Una vez creado el balanceador de carga, anota la dirección IP asociada a él. Por ejemplo, 30.90.80.100. Para dirigir tu dominio a tu balanceador de carga, crea un registro A con tu servicio de registro de dominios. Si has añadido varios dominios a tu certificado SSL, debes añadir un registro A para cada uno de ellos, todos apuntando a la dirección IP del balanceador de carga. Por ejemplo, para crear registros A de www.example.com y example.com, usa lo siguiente:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

Si usas Cloud DNS como proveedor de DNS, consulta el artículo sobre cómo añadir, modificar y eliminar registros.

Probar el balanceador de carga

Ahora que has configurado el balanceador de carga, puedes empezar a enviar tráfico a la dirección IP del balanceador de carga. Si has configurado un dominio, también puedes enviar tráfico al nombre de dominio. Sin embargo, la propagación de DNS puede tardar en completarse, por lo que puedes empezar usando la dirección IP para hacer pruebas.

1. En la Google Cloud consola, ve a la página Balanceo de carga.

   Ir a Balanceo de carga

2. Haz clic en el balanceador de carga que acabas de crear.

3. Anota la dirección IP del balanceador de carga.

4. En el caso de un balanceador de carga HTTP, puedes probarlo con un navegador web. Para ello, ve a http://IP_ADDRESS. Sustituye IP_ADDRESS por la dirección IP del balanceador de carga. Se te debería dirigir a la página principal del servicio helloworld.
   

5. En el caso de un balanceador de carga HTTPS, puedes probarlo con un navegador web. Para ello, ve a https://IP_ADDRESS. Sustituye IP_ADDRESS por la dirección IP del balanceador de carga. Se te debería dirigir a la página principal del servicio helloworld.
   Si no funciona y usas un certificado gestionado por Google, confirma que el estado de tu recurso de certificado es ACTIVE. Para obtener más información, consulta el estado del recurso de certificado SSL gestionado por Google.
   Si has usado un certificado autofirmado para hacer pruebas, tu navegador mostrará una advertencia. Debes indicar explícitamente a tu navegador que acepte un certificado autofirmado. Haz clic en la advertencia para ver la página.

Opciones de configuración adicionales

En esta sección se amplía el ejemplo de configuración para ofrecer opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes llevarlas a cabo en el orden que quieras.

Configurar el balanceo de carga multirregional

En el ejemplo descrito anteriormente en esta página, solo tenemos un servicio Cloud Run que actúa como backend en la región us-central1. Como el NEG sin servidor solo puede apuntar a un endpoint a la vez, no se realiza el balanceo de carga en varias regiones. El balanceador de carga de aplicación externo solo actúa como frontend y proxy del tráfico al endpoint de la aplicación helloworld especificado. Sin embargo, puede que quieras servir tu aplicación de Cloud Run desde más de una región para mejorar la latencia de los usuarios finales.

Si un servicio de backend tiene varios NEGs sin servidor asociados, el balanceador de carga equilibra el tráfico reenviando las solicitudes al NEG sin servidor de la región disponible más cercana. Sin embargo, los servicios de backend solo pueden contener un NEG sin servidor por región. Para que tu servicio de Cloud Run esté disponible en varias regiones, debes configurar el enrutamiento entre regiones. Deberías poder usar un único esquema de URL que funcione en cualquier parte del mundo, pero que responda a las solicitudes de los usuarios desde la región más cercana.

Para configurar el servicio multirregional, debes usar el nivel de red Premium para asegurarte de que todos los despliegues regionales de Cloud Run sean compatibles y estén listos para servir tráfico desde cualquier región.

Para configurar un balanceador de carga multirregional, sigue estos pasos:

1. Configura dos servicios de Cloud Run en regiones diferentes. Supongamos que has desplegado dos servicios de Cloud Run: uno en una región de EE. UU. y otro en una región de Europa.
2. Crea un balanceador de carga de aplicación externo con la siguiente configuración:
   1. Configura un servicio de backend global con dos NEGs sin servidor:
      1. Crea el primer NEG en la misma región que el servicio de Cloud Run desplegado en EE. UU.
      2. Crea el segundo NEG en la misma región que el servicio de Cloud Run desplegado en Europa.
   2. Configura tu frontend con el nivel de servicio de red Premium.

La configuración resultante se muestra en el siguiente diagrama.

En esta sección se explica cómo configurar el balanceador de carga descrito anteriormente en esta página, en el que has creado un NEG sin servidor en la región us-central1 que apunta a un servicio de Cloud Run en la misma región. También se da por hecho que has creado un segundo servicio de Cloud Run en la región europe-west1. El segundo NEG sin servidor que crees apuntará a este servicio de Cloud Run en la región europe-west1.

En este ejemplo, seguirás estos pasos:

1. Crea un segundo NEG sin servidor en la región europe-west1.
2. Asocia el segundo NEG sin servidor al servicio de backend.

Para añadir un segundo NEG sin servidor a un servicio de backend, sigue estos pasos.

Usar una suscripción de inserción de Pub/Sub autenticada con un despliegue multirregional de Cloud Run

En el caso de las solicitudes de inserción autenticadas, Cloud Run espera un campo de audiencia específico de la región de forma predeterminada. En el caso de un despliegue de Cloud Run multirregional, si la solicitud push se enruta a un servicio de Cloud Run de otra región, la verificación del token JWT falla debido a una discrepancia en la audiencia.

Para evitar esta restricción específica de la región, haz lo siguiente:

1. Configura una audiencia personalizada que sea la misma para las implementaciones de servicios en diferentes regiones.
2. Configura los mensajes push de Pub/Sub para que usen la audiencia personalizada como audiencia en el token JWT.

Configurar el enrutamiento regional

Un motivo habitual para servir aplicaciones desde varias regiones es cumplir los requisitos de localización de datos. Por ejemplo, puede que quieras asegurarte de que las solicitudes de los usuarios europeos siempre se atiendan desde una región ubicada en Europa. Para configurarlo, necesitas un esquema de URL con URLs independientes para los usuarios de la UE y los que no lo son, y dirigir a los usuarios de la UE a las URLs de la UE.

En ese caso, usarías el mapa de URLs para dirigir las solicitudes de URLs específicas a las regiones correspondientes. Con esta configuración, las solicitudes destinadas a una región nunca se envían a otra. De esta forma, se consigue un aislamiento entre regiones. Por otro lado, cuando falla una región, las solicitudes no se enrutan a otra región. Por lo tanto, esta configuración no aumenta la disponibilidad de tu servicio.

Para configurar el enrutamiento regional, debe usar el nivel de red Premium para poder combinar diferentes regiones en una sola regla de reenvío.

Para configurar un balanceador de carga con enrutamiento regional, sigue estos pasos:

1. Configura dos servicios de Cloud Run en regiones diferentes. Supongamos que has desplegado dos servicios de Cloud Run: hello-world-eu en una región de Europa y hello-world-us en una región de EE. UU.
2. Crea un balanceador de carga de aplicación externo con la siguiente configuración:
   1. Configura un servicio de backend con un NEG sin servidor en Europa. El NEG sin servidor debe crearse en la misma región que el servicio de Cloud Run implementado en Europa.
   2. Configura un segundo servicio de backend con otro NEG sin servidor en EE. UU. Este NEG sin servidor debe crearse en la misma región que el servicio de Cloud Run desplegado en EE. UU.
   3. Configura tu mapa de URLs con las reglas de host y de ruta adecuadas para que un conjunto de URLs se dirija al servicio de backend europeo, mientras que todas las solicitudes se dirijan al servicio de backend de EE. UU.
   4. Configure su frontend con el nivel de red Premium.

El resto de la configuración puede ser el mismo que se ha descrito anteriormente. La configuración resultante debería tener este aspecto:

Usar una máscara de URL

Cuando creas un NEG sin servidor, en lugar de seleccionar un servicio de Cloud Run específico, puedes usar una máscara de URL para apuntar a varios servicios que se ejecutan en el mismo dominio. Una máscara de URL es una plantilla de su esquema de URL. El NEG sin servidor usará esta plantilla para extraer el nombre del servicio de la URL de la solicitud entrante y asignar la solicitud al servicio adecuado.

Las máscaras de URL son especialmente útiles si tu servicio está asignado a un dominio personalizado en lugar de a la dirección predeterminada queGoogle Cloud proporciona para el servicio desplegado. Una máscara de URL te permite orientar una sola regla a varios servicios y versiones, incluso cuando tu aplicación usa un patrón de URL personalizado.

Si aún no lo has hecho, lee el artículo Descripción general de los NEGs sin servidor: máscaras de URL.

Crear una máscara de URL

Para crear una máscara de URL para tu balanceador de carga, empieza con la URL de tu servicio. En este ejemplo, usaremos una aplicación sin servidor de muestra que se ejecuta en https://example.com/login. Esta es la URL en la que se publicará el loginservicio de la aplicación.

1. Quita http o https de la URL. Te quedan example.com/login.
2. Sustituye el nombre del servicio por un marcador de posición de la máscara de URL.
   1. Cloud Run: sustituye el nombre del servicio de Cloud Run por el marcador de posición <service>. Si el servicio de Cloud Run tiene una etiqueta asociada, sustituye el nombre de la etiqueta por el marcador de posición <tag>. En este ejemplo, la máscara de URL que te queda es example.com/<service>.
   2. Funciones de Cloud Run: sustituye el nombre de la función por el marcador de posición <function>. En este ejemplo, la máscara de URL que te queda es example.com/<function>.
   3. App Engine: sustituye el nombre del servicio por el marcador de posición <service>. Si el servicio tiene una versión asociada, sustitúyala por el marcador de posición <version>. En este ejemplo, la máscara de URL que te queda es example.com/<service>.
   4. API Gateway: sustituye el nombre de la pasarela por el marcador de posición <gateway>. En este ejemplo, la máscara de URL que te queda es example.com/<gateway>.

3. (Opcional) Si el nombre del servicio (o la función, la versión o la etiqueta) se puede extraer de la parte de la ruta de la URL, se puede omitir el dominio. La parte de la ruta de la máscara de URL se distingue por el primer carácter /. Si no hay ningún / en la máscara de URL, se entiende que la máscara representa solo el host. Por lo tanto, en este ejemplo, la máscara de URL se puede reducir a /<service>, /<gateway> o /<function>.

   Del mismo modo, si el nombre del servicio se puede extraer de la parte del host de la URL, puedes omitir la ruta por completo de la máscara de URL.

   También puede omitir cualquier componente de host o subdominio que vaya antes del primer marcador de posición, así como cualquier componente de ruta que vaya después del último marcador de posición. En estos casos, el marcador de posición recoge la información necesaria para el componente.

A continuación, te mostramos algunos ejemplos más que demuestran estas reglas:

Crear un NEG sin servidor con una máscara de URL

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-url-mask="example.com/<service>"

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

Para saber cómo gestiona el balanceador de carga los problemas con las discrepancias de máscara de URL, consulta Solucionar problemas con NEG sin servidor.

Mover el dominio personalizado para que lo sirva el balanceador de carga de aplicación externo

Si tus aplicaciones de computación sin servidor se están asignando a dominios personalizados, puede que quieras actualizar tus registros DNS para que el tráfico enviado a las URLs de dominio personalizado de Cloud Run, Cloud Run Functions, API Gateway o App Engine se enrute a través del balanceador de carga.

Por ejemplo, si tienes un dominio personalizado llamado example.com y todos tus servicios de Cloud Run están asignados a este dominio, debes actualizar el registro DNS de example.com para que apunte a la dirección IP del balanceador de carga.

Antes de actualizar los registros DNS, puedes probar tu configuración localmente forzando la resolución de DNS local del dominio personalizado a la dirección IP del balanceador de carga. Para hacer pruebas a nivel local, modifica el archivo /etc/hosts/ de tu máquina local para que example.com apunte a la dirección IP del balanceador de carga o usa la marca curl --resolve para obligar a curl a usar la dirección IP del balanceador de carga en la solicitud.

Cuando el registro DNS de example.com se resuelve en la dirección IP del balanceador de carga HTTP(S), las solicitudes enviadas a example.com empiezan a enrutarse a través del balanceador de carga. El balanceador de carga los envía al servicio de backend correspondiente según su mapa de URLs. Además, si el servicio de backend está configurado con una máscara de URL, el NEG sin servidor usa la máscara para enrutar la solicitud al servicio de Cloud Run, Cloud Run Functions, API Gateway o App Engine adecuado.

Habilitar Cloud CDN

Si habilitas Cloud CDN en tu servicio de Cloud Run, puedes optimizar la distribución de contenido almacenando en caché el contenido cerca de tus usuarios.

Puedes habilitar Cloud CDN en los servicios de backend que usan los balanceadores de carga de aplicaciones externos globales con el comando gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

Cloud CDN es compatible con servicios de backend con backends de Cloud Run, Cloud Run functions, API Gateway y App Engine.

Habilitar IAP en el balanceador de carga de aplicación externo

Puedes configurar las compras en aplicaciones para que estén habilitadas o inhabilitadas (opción predeterminada). Si está habilitada, debe proporcionar valores para oauth2-client-id y oauth2-client-secret.

Para habilitar IAP, actualiza el servicio de backend para incluir la marca --iap=enabled con oauth2-client-id y oauth2-client-secret.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

De forma opcional, puedes habilitar IAP en un recurso de Compute Engine mediante la Google Cloud consola, la CLI de gcloud o la API.

Habilitar Google Cloud Armor

Cloud Armor es un producto de seguridad que ofrece protección contra ataques de denegación de servicio distribuido (DDoS) a todos los balanceadores de carga proxy de GCLB. Cloud Armor también proporciona políticas de seguridad configurables a los servicios a los que se accede a través de un balanceador de carga de aplicaciones externo. Para obtener información sobre las políticas de seguridad de Cloud Armor para balanceadores de carga de aplicaciones externos, consulta el artículo Información general sobre la política de seguridad de Cloud Armor.

Si usas Cloud Run functions, puedes bloquear las solicitudes enviadas a URLs predeterminadas mediante el ajuste de internal-and-gclbentrada.

Si usas Cloud Run, puedes bloquear las solicitudes enviadas a URLs predeterminadas o a cualquier otro dominio personalizado configurado a través de Cloud Run restringiendo el acceso a "balanceo de carga interno y de Cloud".

Si usas App Engine, puedes usar controles de entrada para que tu aplicación solo reciba solicitudes enviadas desde el balanceador de carga (y la VPC, si la usas).

Si no se configura correctamente el ajuste de acceso, los usuarios podrán usar la URL predeterminada de tu aplicación sin servidor para saltarse el balanceador de carga, las políticas de seguridad de Cloud Armor, los certificados SSL y las claves privadas que se transfieren a través del balanceador de carga.

Opcional: Configura una política de seguridad de backend predeterminada. La política de seguridad predeterminada limita el tráfico por encima de un umbral configurado por el usuario. Para obtener más información sobre las políticas de seguridad predeterminadas, consulta el artículo Descripción general de la limitación de frecuencia.

1. Para inhabilitar la política de seguridad predeterminada de Cloud Armor, selecciona None en la lista Política de seguridad de backend de Cloud Armor.
2. Para configurar la política de seguridad predeterminada de Cloud Armor, selecciona Política de seguridad predeterminada en la lista Política de seguridad de backend de Cloud Armor.
3. En el campo Nombre de la política, acepta el nombre generado automáticamente o introduce un nombre para tu política de seguridad.
4. En el campo Número de solicitudes, acepta el número de solicitudes predeterminado o introduce un número entero entre 1 y 10,000.
5. En el campo Intervalo, selecciona un intervalo.
6. En el campo Enforce on key (Aplicar en clave), elige uno de los siguientes valores: All (Todo), IP address (Dirección IP) o X-Forwarded-For IP address (Dirección IP X-Forwarded-For). Para obtener más información sobre estas opciones, consulta Identificar clientes para limitar la frecuencia.

Habilitar el registro y la monitorización

Puede habilitar, inhabilitar y ver los registros de un servicio de backend de un balanceador de carga de aplicaciones externo. Cuando se usa la consola de Google Cloud , el registro está habilitado de forma predeterminada en los servicios de backend con backends de NEG sin servidor. Puedes usar gcloud para inhabilitar el registro de cada servicio backend según sea necesario. Para obtener instrucciones, consulta Registro.

El balanceador de carga también exporta datos de monitorización a Cloud Monitoring. Las métricas de monitorización se pueden usar para evaluar la configuración, el uso y el rendimiento de un balanceador de carga. Las métricas también se pueden usar para solucionar problemas y mejorar la utilización de los recursos y la experiencia de usuario. Para obtener instrucciones, consulta Monitorización.

Actualizar el tiempo de espera de keep-alive HTTP del cliente

Para actualizar el tiempo de espera de keep-alive HTTP del cliente, sigue estas instrucciones.

      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    

      gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    

Habilitar la detección de valores atípicos

Puedes habilitar la detección de valores atípicos en los servicios de backend globales para identificar los NEGs sin servidor que no estén en buen estado y reducir el número de solicitudes que se envían a esos NEGs.

La detección de valores atípicos se habilita en el servicio backend mediante uno de los siguientes métodos:

• El método consecutiveErrors (outlierDetection.consecutiveErrors), en el que un código de estado HTTP de la serie 5xx se considera un error.
• El método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), en el que solo los códigos de estado HTTP 502, 503 y 504 se consideran errores.

Sigue estos pasos para habilitar la detección de anomalías en un servicio backend. Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, algunas solicitudes se pueden enviar al servicio no operativo y devolver un código de estado 5xx a los clientes. Para reducir aún más la tasa de error, puedes configurar valores más agresivos para los parámetros de detección de valores atípicos. Para obtener más información, consulta el campo outlierDetection.

Eliminar un NEG sin servidor

No se puede eliminar un grupo de endpoints de red si está asociado a un servicio de backend. Antes de eliminar un NEG, asegúrate de que esté separado del servicio de backend.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

Siguientes pasos

• Usar el almacenamiento de registros y la monitorización
• Solucionar problemas con NEGs sin servidor
• Limpiar la configuración del balanceador de carga
• Usar un módulo de Terraform para un balanceador de carga HTTPS externo con un backend de Cloud Run