Configura un balanceador de cargas de aplicaciones externo global con Cloud Run, App Engine o funciones de Cloud Run

En esta página, se muestra cómo crear un balanceador de cargas de aplicaciones externo para enrutar solicitudes a backends sin servidores. El término “sin servidores” hace referencia a los siguientes productos de procesamiento sin servidores:

• App Engine
• Funciones de Cloud Run
• Cloud Run

La integración de balanceadores de cargas de aplicaciones externos con API Gateway permite que los backends sin servidores aprovechen todas las funciones de Cloud Load Balancing. Si deseas configurar un balanceador de cargas de aplicaciones externo para enrutar el tráfico a una API Gateway, consulta Comienza a usar un balanceador de cargas de aplicaciones externo para API Gateway. La compatibilidad del balanceador de cargas de aplicaciones externo con API Gateway se encuentra en versión preliminar.

Los NEG sin servidores te permiten usar las apps sin servidores de Google Cloud con balanceadores de cargas de aplicaciones externos. Después de configurar un balanceador de cargas con el backend de NEG sin servidores, las solicitudes al balanceador de cargas se enrutan al backend de la app sin servidores.

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

Si eres un usuario existente del balanceador de cargas de aplicaciones clásico, asegúrate de revisar la descripción general de la migración cuando planifiques una implementación nueva con el balanceador de cargas de aplicaciones externo global.

Antes de comenzar

1. Implementa un servicio de App Engine, funciones de Cloud Run o Cloud Run.
2. Si aún no lo hiciste, instala Google Cloud CLI.
3. Configura permisos.
4. Agrega un recurso de certificado SSL.

Implementa un servicio de App Engine, funciones de Cloud Run o Cloud Run

En las instrucciones de esta página, se supone que ya tienes un servicio de Cloud Run, funciones de Cloud Run o App Engine en ejecución.

En el ejemplo de esta página, se usa la guía de inicio rápido de Python de Cloud Run a fin de implementar un servicio de Cloud Run en la región us-central1. En el resto de esta página, se muestra cómo configurar un balanceador de cargas de aplicaciones externo que usa un backend de NEG sin servidores para enrutar las solicitudes a este servicio.

Si aún no implementaste una app sin servidores o si quieres probar un NEG sin servidores con una app de muestra, usa una de las siguientes guías de inicio rápido. Puedes crear una app sin servidores en cualquier región, pero debes usar la misma región más adelante para crear el NEG sin servidores y el balanceador de cargas.

Cloud Run

Para crear una aplicación Hello World sencilla, empaquetarla en una imagen de contenedor y, luego, implementar la imagen de contenedor en Cloud Run, consulta la Guía de inicio rápido: Compila e implementa.

Si ya subiste un contenedor de muestra a Container Registry, consulta la Guía de inicio rápido: Implementa un contenedor de muestra ya compilado.

Funciones de Cloud Run

Consulta Funciones de Cloud Run: 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

Instala Google Cloud CLI

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

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

Configura permisos

Para seguir esta guía, debes crear un NEG sin servidores y un balanceador de cargas de HTTP(S) externo en un proyecto. Debes ser propietario o editor de un proyecto o tener las siguientes funciones de IAM de Compute Engine:

Tarea	Función requerida
Crear balanceador de cargas y componentes de herramientas de redes	Administrador de redes
Crear y modificar los NEG	Administrador de instancias de procesamiento
Crear y modificar certificados SSL	Administrador de seguridad

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 usen para llegar a tu balanceador de cargas.

Nota: Este paso es obligatorio para este ejemplo, y se recomienda en general, ya que una dirección IP externa estática proporciona una única dirección a la que puedes apuntar la app sin servidores. Reservar una dirección IP también es esencial si usas un dominio personalizado para tu app sin servidores (también es necesario en certificados SSL administrados por Google). Con un dominio personalizado, deberás actualizar tus registros DNS para que tu dominio apunte a esta dirección IP.

Console

1. En la consola de Google Cloud, ve a la página Direcciones IP externas.

   Ir a Direcciones IP externas

2. Haz clic en Reservar dirección IP externa estática.

3. En Nombre, ingresa example-ip.

4. En Nivel de servicio de red, selecciona Premium.

5. Para Versión de la IP, selecciona IPv4.

6. En Tipo, selecciona Global.

7. Haz clic en Reservar.

gcloud

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

Toma nota de la dirección IPv4 que se reservó:

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

Crea un recurso de certificado SSL

Si quieres crear un balanceador de cargas de HTTPS, debes agregar un recurso de certificado SSL al frontend del balanceador de cargas. Crea un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado.

• Certificados administrados por Google. Se recomienda usar certificados administrados por Google, ya que Google Cloud obtiene, administra y renueva estos certificados de manera automática. Si quieres crear un certificado administrado por Google, debes tener un dominio y los registros DNS para ese dominio a fin de que se aprovisione el certificado. Además, deberás actualizar el registro DNS A del dominio para que apunte a la dirección IP del balanceador de cargas que se creó en el paso anterior (example-ip). Para obtener instrucciones detalladas, consulta Usa certificados administrados por Google.

• Certificados autofirmados. Si no deseas configurar un dominio en este momento, puedes usar un certificado SSL autofirmado para realizar una prueba.

Advertencia: No uses un certificado autofirmado para fines de producción.

En este ejemplo, se supone que ya creaste un recurso de certificado SSL.

Si quieres probar este proceso sin crear un recurso de certificado SSL (o un dominio requerido por los certificados administrados por Google), puedes seguir las instrucciones de esta página para configurar un balanceador de cargas de HTTP en su lugar.

Crea el balanceador de cargas

En el siguiente diagrama, el balanceador de cargas usa un backend de NEG sin servidores para dirigir las solicitudes a un servicio de Cloud Run sin servidores. En este ejemplo, usamos la guía de inicio rápido de Python de Cloud Run para implementar un servicio de Cloud Run.

Arquitectura del balanceador de cargas de aplicaciones externo para una aplicación de Cloud Run (haz clic para ampliar).

Debido a que las verificaciones de estado no admiten los servicios de backend con backends de NEG sin servidores, no necesitas crear una regla de firewall que permita verificaciones de estado si el balanceador de cargas solo tiene backends de NEG sin servidores.

Console

Inicia la configuración

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

   Ir a Balanceo de cargas

2. Haz clic en Crear balanceador de cargas.
3. En Tipo de balanceador de cargas, selecciona Balanceador de cargas de aplicaciones (HTTP/HTTPS) y haz clic en Siguiente.
4. En Orientado al público o interno, selecciona Orientado al público (externo) y haz clic en Siguiente.
5. En Implementación global o de una sola región, selecciona Mejor para cargas de trabajo globales y haz clic en Siguiente.
6. En Generación de balanceadores de cargas, selecciona Balanceador de cargas de aplicaciones externo global y haz clic en Siguiente.
7. Haz clic en Configurar.

Configuración básica

1. Para el Nombre del balanceador de cargas, ingresa serverless-lb.
2. Mantén la ventana abierta para continuar.

Configuración de frontend

1. Haz clic en Configuración de frontend.
2. En Nombre, ingresa un nombre.
3. Si quieres crear un balanceador de cargas de HTTPS, debes tener un certificado SSL (gcloud compute ssl-certificates list).

   Recomendamos usar un certificado administrado por Google como se describió antes.

Para configurar un balanceador de cargas de aplicaciones externo, completa los campos como se muestra a continuación.

Verifica que las siguientes opciones estén configuradas con estos valores:

Propiedad	Valor (escribe un valor o selecciona una opción como se especifica)
Protocolo	HTTPS
Nivel de servicio de red	Premium
Versión de IP	IPv4
Dirección IP	example-ip
Puerto	443
Opcional: Tiempo de espera de keepalive de HTTP (opcional)	Ingresa un valor de tiempo de espera de 5 a 1,200 segundos. El valor predeterminado es 610 segundos.
Certificado	Selecciona un certificado SSL existente o crea uno nuevo. Si quieres crear un balanceador de cargas de HTTPS, debes tener un recurso de certificado SSL para usar en el proxy HTTPS. Puedes crear un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado. Para crear un certificado administrado por Google, debes tener un dominio. El registro A del dominio debe resolverse en la dirección IP del balanceador de cargas (en este ejemplo, example-ip). Se recomienda usar certificados administrados por Google porque Google Cloud obtiene, administra y renueva estos certificados de forma automática. Si no tienes un dominio, puedes usar un certificado SSL autofirmado para las pruebas.
(Opcional) Habilitar el redireccionamiento de HTTP a HTTPS	Usa esta casilla de verificación para habilitar los redireccionamientos HTTP a HTTPS. Si habilitas esta casilla de verificación, se creará un balanceador de cargas HTTP parcial adicional que usa la misma dirección IP que tu balanceador de cargas HTTPS y redirecciona las solicitudes HTTP al frontend de HTTPS del balanceador de cargas. Esta casilla de verificación solo se puede seleccionar cuando se selecciona el protocolo HTTPS y se usa una dirección IP reservada.

Si quieres probar este proceso sin configurar un recurso de certificado SSL (o un dominio según lo requieren los certificados administrados por Google), puedes configurar un balanceador de cargas de HTTP.

Para crear un balanceador de cargas de HTTP, verifica que las siguientes opciones estén configuradas con estos valores:

Propiedad	Valor (escribe un valor o selecciona una opción como se especifica)
Protocolo	HTTP
Nivel de servicio de red	Premium
Versión de IP	IPv4
Dirección IP	example-ip
Puerto	80
Opcional: Tiempo de espera de keepalive de HTTP (opcional)	Ingresa un valor de tiempo de espera de 5 a 1,200 segundos. El valor predeterminado es 610 segundos.

4. Haz clic en Listo.

Configuración de backend

1. Haz clic en Configuración de backend.
2. En la lista Servicios y buckets de backend, haz clic en Crear un servicio de backend.
3. En Nombre, ingresa un nombre.
4. En Tipo de backend, selecciona Grupo de extremos de red sin servidores.
5. Deja Protocolo sin modificar. Este parámetro se ignora.
6. En la sección Backends, para Nuevo backend, selecciona Crear grupo de extremos de red sin servidores.
7. En Nombre, ingresa un nombre.
8. En Región, selecciona us-central1 y, luego, Cloud Run.
9. Elige Seleccionar nombre de servicio.
10. En la lista Servicio, selecciona el servicio de Cloud Run para el que quieres crear un balanceador de cargas.
11. Haz clic en Crear.
12. En la sección Backend nuevo, haz clic en Listo.
13. Haz clic en Crear.

Reglas de enrutamiento

Las reglas de enrutamiento determinan cómo se dirige el tráfico. Para configurar el enrutamiento, deberás configurar reglas de host y comparadores de rutas de acceso, que son componentes de configuración de un mapa de URL del balanceador de cargas de aplicaciones externo.

1. Haga clic en Reglas de enrutamiento.

2. Conserva los hosts y las rutas de acceso predeterminados. Para este ejemplo, todas las solicitudes se envían al servicio de backend que creaste en el paso anterior.

Revisa la configuración

1. Haz clic en Revisar y finalizar.
2. Revisa toda la configuración.
3. Opcional: Haz clic en Código equivalente a fin de ver la solicitud a la API de REST que se usará para crear el balanceador de cargas.
4. Haz clic en Crear.
5. Espera a que se cree el balanceador de cargas.
6. Haz clic en el nombre del balanceador de cargas (serverless-lb).
7. Anote la dirección IP del balanceador de cargas para la siguiente tarea. Se hace referencia a ella como IP_ADDRESS.

Cuando usas la consola de Google Cloud para crear un balanceador de cargas HTTP(S) con un backend de NEG sin servidores, el registro está habilitado de forma predeterminada. Puedes usar el comando gcloud compute backend-services update para inhabilitar el registro, si es necesario.

gcloud

1. Crea un NEG sin servidores para tu app sin servidores.

   Para crear un NEG sin servidores con un servicio de Cloud Run, sigue estos pasos:

      gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
          --region=us-central1 \
          --network-endpoint-type=serverless  \
          --cloud-run-service=CLOUD_RUN_SERVICE_NAME
      

   Si deseas ver más opciones, consulta la guía de referencia de gcloud para gcloud compute network-endpoint-groups create.
2. Crea un servicio de backend.

      gcloud compute backend-services create BACKEND_SERVICE_NAME \
          --load-balancing-scheme=EXTERNAL_MANAGED \
          --global
      

3. Agrega el NEG sin servidores como un backend al servicio de backend:

      gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
          --global \
          --network-endpoint-group=SERVERLESS_NEG_NAME \
          --network-endpoint-group-region=us-central1
      

4. Crea un mapa de URL para enrutar las solicitudes entrantes al servicio de backend:

      gcloud compute url-maps create URL_MAP_NAME \
          --default-service BACKEND_SERVICE_NAME
      

   Este mapa de URL de ejemplo solo se orienta a un servicio de backend que representa una sola app sin servidores, por lo que no es necesario configurar reglas de host ni comparadores de rutas de acceso. Si tienes más de un servicio de backend, puedes usar reglas de host a fin de dirigir las solicitudes a diferentes servicios según el nombre de host y configurar comparadores de rutas de acceso para dirigir solicitudes a diferentes servicios según la ruta de acceso de la solicitud.

5. Sigue este paso solo si quieres crear un balanceador de cargas de HTTPS. Esto no es obligatorio para los balanceadores de cargas de HTTP.
   Si quieres crear un balanceador de cargas de HTTPS, debes tener un recurso de certificado SSL para usar en el proxy HTTPS. Puedes crear un recurso de certificado SSL mediante un certificado SSL administrado por Google o un certificado SSL autoadministrado. Se recomienda usar certificados administrados por Google, ya que Google Cloud obtiene, administra y renueva estos certificados de manera automática.
   
   Para crear un certificado administrado por Google, debes tener un dominio. Si no tienes un dominio, puedes usar un certificado SSL autofirmado para realizar pruebas.
   
   Si deseas crear un recurso de certificado SSL que administra Google, ingresa el comando siguiente:

      gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
          --domains DOMAIN
      

   Si deseas crear un recurso de certificado SSL autoadministrado, haz lo siguiente:

      gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
          --certificate CRT_FILE_PATH \
          --private-key KEY_FILE_PATH
      

6. Crea un proxy HTTP(S) de destino para enrutar las solicitudes al mapa de URL.

   Para un balanceador de cargas de HTTP, crea un proxy HTTP de destino:

      gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
         --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
         --url-map=URL_MAP_NAME
      

   Para un balanceador de cargas de HTTPS, crea un proxy HTTPS de destino. El proxy es la parte del balanceador de cargas que contiene el certificado SSL para el balanceo de cargas de HTTPS, por lo que también debes cargar el certificado en este paso.

      gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --ssl-certificates=SSL_CERTIFICATE_NAME \
          --url-map=URL_MAP_NAME
      

   Reemplaza lo siguiente:

   • TARGET_HTTP_PROXY_NAME: el nombre del proxy HTTP de destino.
   • TARGET_HTTPS_PROXY_NAME: el nombre del proxy HTTPS de destino.
   • HTTP_KEEP_ALIVE_TIMEOUT_SEC: un campo opcional que se usa para especificar el tiempo de espera de keepalive de HTTP del cliente. El valor del tiempo de espera debe ser de 5 a 1,200 segundos. El valor predeterminado es 610 segundos.
   • SSL_CERTIFICATE_NAME: es el nombre del certificado SSL.
   • URL_MAP_NAME: el nombre del mapa de URL.
7. Crea una regla de reenvío para enrutar las solicitudes entrantes al proxy.
   
   

   Para un balanceador de cargas de HTTP, ingresa el siguiente comando:

      gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
      --load-balancing-scheme=EXTERNAL_MANAGED \
      --network-tier=PREMIUM \
      --address=example-ip \
      --target-http-proxy=TARGET_HTTP_PROXY_NAME \
      --global \
      --ports=80
      

   Para un balanceador de cargas HTTPS, ingresa el siguiente comando:

      gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
          --load-balancing-scheme=EXTERNAL_MANAGED \
          --network-tier=PREMIUM \
          --address=example-ip \
          --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
          --global \
          --ports=443
      

Conecta tu dominio al balanceador de cargas

Después de crear el balanceador de cargas, toma nota de la dirección IP asociada con este: por ejemplo, 30.90.80.100. Para apuntar tu dominio al balanceador de cargas, crea un registro A mediante tu servicio de registro de dominio. Si agregaste varios dominios a tu certificado SSL, debes agregar un registro A para cada uno, que apunte a la dirección IP del balanceador de cargas. Por ejemplo, para crear registros A para 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 Agrega, modifica y borra registros.

Prueba el balanceador de cargas

Ahora que ya configuraste el balanceador de cargas, puedes comenzar a enviar tráfico a la dirección IP del balanceador de cargas. Si configuraste un dominio, también puedes enviar tráfico al nombre de dominio. Sin embargo, la propagación de DNS puede llevar un tiempo en completarse, por lo que puedes comenzar a usar la dirección IP para realizar pruebas.

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

   Ir a Balanceo de cargas

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

3. Toma nota de la Dirección IP del balanceador de cargas.

4. En el caso de un balanceador de cargas de HTTP, puedes probar tu balanceador de cargas con un navegador web en http://IP_ADDRESS. Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas. Deberías dirigirte a la página principal del servicio helloworld.
   

5. En el caso de un balanceador de cargas de HTTPS, puedes probar tu balanceador de cargas con un navegador web en https://IP_ADDRESS. Reemplaza IP_ADDRESS por la dirección IP del balanceador de cargas. Deberías dirigirte a la página principal del servicio helloworld.
   Si eso no funciona y usas un certificado administrado por Google, confirma que el estado del recurso de certificado sea ACTIVO. Para obtener más información, consulta el estado de los recursos del certificado SSL administrado por Google.
   Si usaste un certificado autofirmado para las pruebas, el navegador mostrará una advertencia. Debes indicar de manera explícita a tu navegador que acepte un certificado autofirmado. Haz clic en la advertencia para ver la página real.

Opciones de configuración adicionales

En esta sección se expande el ejemplo de configuración para proporcionar opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en cualquier orden.

Configura el balanceo de cargas multirregión

Nota: En el caso de los NEGs sin servidores, el balanceo de cargas multirregión solo es compatible si el NEG sin servidores apunta a un servicio de Cloud Run o funciones de Cloud Run. El balanceo de cargas multirregional con detección de valores extremos no es compatible con App Engine, ya que no puedes implementar App Engine de un proyecto en varias regiones.

En el ejemplo que se describió antes en esta página, solo tenemos un servicio de Cloud Run que funciona como backend en la región us-central1. Debido a que el NEG sin servidores solo puede apuntar a un extremo a la vez, el balanceo de cargas no se realiza en varias regiones. El balanceador de cargas de aplicaciones externo solo funciona como frontend y envía el tráfico al extremo de la app helloworld especificado. Sin embargo, es posible que desees entregar la app de Cloud Run desde más de una región para mejorar la latencia del usuario final.

Si un servicio de backend tiene varios NEGs sin servidores conectados a él, el balanceador de cargas balancea el tráfico mediante el reenvío de solicitudes al NEG sin servidores en la región disponible más cercana. Sin embargo, los servicios de backend solo pueden contener un NEG sin servidores por región. Para que tu servicio de Cloud Run esté disponible en varias regiones, deberás configurar el enrutamiento entre regiones. Deberías poder usar un único esquema de URL que funcione en cualquier parte del mundo, pero que entregue las solicitudes de los usuarios desde la región más cercana al usuario.

A fin de configurar la entrega multirregional, deberás usar el nivel de red Premium para asegurarte de que todas las implementaciones regionales de Cloud Run sean compatibles y estén listas para entregar tráfico desde cualquier región.

Para configurar un balanceador de cargas multirregión, sigue estos pasos:

1. Configura dos servicios de Cloud Run en diferentes regiones. Supongamos que implementaste 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 cargas de aplicaciones externo con la siguiente configuración:
   1. Configura un servicio de backend global con dos NEG sin servidores:
      1. Crea el primer NEG en la misma región que el servicio de Cloud Run implementado en EE.UU.
      2. Crea el segundo NEG en la misma región que el servicio de Cloud Run implementado en Europa.
   2. Establece tu configuración de frontend con el nivel de servicio de red Premium.

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

Enrutamiento multirregión para aplicaciones sin servidores

En esta sección, se basa en la configuración del balanceador de cargas que se describió anteriormente en esta página, en la que creaste un NEG sin servidores en la región us-central1 que apunta a un servicio de Cloud Run en la misma región. También se asume que creaste un segundo servicio de Cloud Run en la región europe-west1. El segundo NEG sin servidores que crees apuntará a este servicio de Cloud Run en la región europe-west1.

En este ejemplo, completarás los siguientes pasos:

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

Para agregar un segundo NEG sin servidores a un servicio de backend existente, sigue estos pasos.

Console

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

   Ir a Balanceo de cargas

2. Haz clic en el nombre del balanceador de cargas cuyo servicio de backend quieres editar.

3. En la página Detalles del balanceador de cargas, haz clic en Editar.

4. En la página Editar balanceador de cargas de aplicaciones externo global, haz clic en Configuración de backend.

5. En la página de Configuración de backend, haz clic en Editar en el servicio de backend que deseas modificar.

6. En la sección Backends, haz clic en Agregar un backend.

7. En la lista Grupos de extremos de red sin servidores, selecciona Crear grupo de extremos de red sin servidores.

8. Ingresa un nombre para el NEG sin servidores.

9. En Región, selecciona europe-west1.

10. En Tipo de grupo de extremos de red sin servidores, selecciona Cloud Run y, luego, haz lo siguiente:

    1. Selecciona la opción Seleccionar servicio.
    2. En la lista Servicio, selecciona el servicio de Cloud Run para el que quieres crear un balanceador de cargas.

11. Haz clic en Crear.

12. En la página Nuevo backend, haz clic en Listo.

13. Haz clic en Guardar.

14. Para actualizar el servicio de backend, haz clic en Actualizar.

15. Para actualizar el balanceador de cargas, en la página Edita el balanceador de cargas de aplicaciones externo global, haz clic en Actualizar.

gcloud

1. Crea un segundo NEG sin servidores en la misma región en la que se implementó el servicio de Cloud Run.

   gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
     --region=europe-west1 \
     --network-endpoint-type=SERVERLESS \
     --cloud-run-service=CLOUD_RUN_SERVICE_2
   

   Reemplaza lo siguiente:

   • SERVERLESS_NEG_NAME_2: es el nombre del segundo NEG sin servidores.
   • CLOUD_RUN_SERVICE_2: es el nombre del servicio de Cloud Run.

2. Agrega el segundo NEG sin servidores como un backend al servicio de backend.

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --global \
     --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
     --network-endpoint-group-region=europe-west1
   

   Reemplaza lo siguiente:

   • BACKEND_SERVICE_NAME: es el nombre del servicio de backend.
   • SERVERLESS_NEG_NAME_2: es el nombre del segundo NEG sin servidores.

Usa una suscripción de envío de Pub/Sub autenticada con una implementación multirregional de Cloud Run

Para las solicitudes de envío autenticadas, Cloud Run espera un campo de público específico de la región de forma predeterminada. En el caso de una implementación de Cloud Run multirregión, si la solicitud de envío se enruta a un servicio de Cloud Run en una región diferente, la verificación del token de JWT falla debido a una discrepancia de público.

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

1. Configura un público personalizado que sea el mismo para las implementaciones de servicios en diferentes regiones.
2. Configura los mensajes de envío de Pub/Sub para usar el público personalizado como público en el token JWT.

Configura el enrutamiento regional

Un motivo común para entregar aplicaciones desde varias regiones es a fin de cumplir con los requisitos de localidad de datos. Por ejemplo, es posible que desees asegurarte de que las solicitudes que realizan los usuarios europeos siempre se entreguen desde una región de Europa. Si deseas configurar esto, necesitas un esquema de URL con URL independientes para usuarios de la UE y que no pertenezcan a la UE, y dirigir a los usuarios de la UE a las URL de la UE.

En ese caso, deberías usar el mapa de URL para enrutar solicitudes de URL específicas a sus regiones correspondientes. Con esta configuración las solicitudes creadas para una región nunca se entregarán a otra. Esto proporciona aislamiento entre regiones. Por otro lado, cuando una región falla, las solicitudes no se enrutan a una región diferente. Por lo tanto, esta configuración no aumenta la disponibilidad del servicio.

Para configurar el enrutamiento regional, deberás usar el nivel de red Premium de modo que puedas combinar diferentes regiones en una sola regla de reenvío.

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

1. Configura dos servicios de Cloud Run en diferentes regiones. Supongamos que implementaste 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 cargas de aplicaciones externo con la siguiente configuración:
   1. Configura un servicio de backend con un NEG sin servidores en Europa. El NEG sin servidores 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 servidores en EE.UU. Este NEG sin servidores debe crearse en la misma región que el servicio de Cloud Run implementado en EE.UU.
   3. Configura tu mapa de URL con las reglas de host y ruta de acceso adecuadas para que un conjunto de URL se enrute al servicio de backend europeo mientras todas las solicitudes se enrutan al servicio de backend de EE.UU.
   4. Establece tu configuración de frontend con el nivel de red Premium.

El resto de la configuración puede ser la misma que se describió antes. La configuración resultante se verá de la siguiente manera:

Enrutamiento regional para aplicaciones sin servidores sin conmutación por error

Usa una máscara para URL

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

Las máscaras de URL son útiles sobre todo si tu servicio se mapea a un dominio personalizado en lugar de mapearse a la dirección predeterminada que proporciona Google Cloud para el servicio implementado. Una máscara de URL te permite orientar varios servicios y versiones con una regla única, incluso cuando tu aplicación usa un patrón de URL personalizado.

Si aún no lo hiciste, asegúrate de leer la Descripción general de NEG sin servidores: Máscaras de URL.

Crea una máscara para URL

A fin de crear una máscara de URL para tu balanceador de cargas, comienza con la URL de tu servicio. Para este ejemplo usaremos una app sin servidores de muestra que se ejecuta en https://example.com/login. Esta es la URL en la que se entregará el servicio login de la app.

1. Quita http o https de la URL. Quedará example.com/login.
2. Reemplaza el nombre del servicio por un marcador de posición para la máscara de URL.
   1. Cloud Run: reemplaza el nombre del servicio de Cloud Run por el marcador de posición <service>. Si el servicio de Cloud Run tiene una etiqueta asociada, reemplaza el nombre de la etiqueta por el marcador de posición <tag>. En este ejemplo la máscara de URL que queda es example.com/<service>.
   2. Funciones de Cloud Run: reemplaza el nombre de la función por el marcador de posición <function>. En este ejemplo la máscara de URL que queda es example.com/<function>.
   3. App Engine: reemplaza el nombre del servicio por el marcador de posición <service>. Si el servicio tiene una versión asociada, reemplaza la versión con el marcador de posición <version>. En este ejemplo la máscara de URL que queda es example.com/<service>.
   4. API Gateway: reemplaza el nombre de la puerta de enlace por el marcador de posición <gateway>. En este ejemplo la máscara de URL que 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 porción de la ruta de acceso de la URL, se puede omitir el dominio. La porción de la ruta de acceso de la máscara de URL se distingue por el primer carácter /. Si / no está presente en la máscara de URL, se entiende que la máscara solo representa al host. Por lo tanto, para este ejemplo, la máscara de URL se puede reducir a /<service>, /<gateway> o /<function>.

   De manera similar, si se puede extraer el nombre del servicio de la parte del host de la URL, puedes omitir la ruta de acceso por completo de la máscara de URL.

   También puedes omitir cualquier componente de host o subdominio que aparezca antes del primer marcador de posición, y cualquier componente de la ruta de acceso que aparezca después del último marcador de posición. En esos casos, el marcador de posición captura la información requerida del componente.

Los siguientes son algunos otros ejemplos en los que se demuestran estas reglas:

Cloud Run

En esta tabla, se supone que tienes un dominio personalizado llamado example.com y que todos tus servicios de Cloud Run se asignan a este dominio mediante un balanceador de cargas de aplicaciones externo.

Servicio, nombre de la etiqueta	URL de dominio personalizado	Máscara de URL
servicio: login	https://login-home.example.com/web	<service>-home.example.com
servicio: login	https://example.com/login/web	example.com/<service> o /<service>
servicio: login, etiqueta: test	https://test.login.example.com/web	<tag>.<service>.example.com
servicio: login, etiqueta: test	https://example.com/home/login/test	example.com/home/<service>/<tag> o /home/<service>/<tag>
servicio: login, etiqueta: test	https://test.example.com/home/login/web	<tag>.example.com/home/<service>

Funciones de Cloud Run

En esta tabla se supone que tienes un dominio personalizado llamado example.com y que todos tus servicios de funciones de Cloud Run se mapean a este dominio.

Nombre de la función	URL de dominio personalizado	Máscara de URL
login	https://example.com/login	/<function>
login	https://example.com/home/login	/home/<function>
login	https://login.example.com	<function>.example.com
login	https://login.home.example.com	<function>.home.example.com

App Engine

En esta tabla, se supone que tienes un dominio personalizado llamado example.com y que todos tus servicios de App Engine se asignan a este dominio.

Nombre del servicio, versión	URL de dominio personalizado	Máscara de URL
servicio: login	https://login.example.com/web	<service>.example.com
servicio: login	https://example.com/home/login/web	example.com/home/<service>, o /home/<service>
servicio: login, versión: test	https://test.example.com/login/web	<version>.example.com/<service>
servicio: login, versión: test	https://example.com/login/test	example.com/<service>/<version>

API Gateway

En esta tabla, se supone que tienes un dominio personalizado llamado example.com y que todos tus servicios de API Gateway se asignan a este dominio.

Nombre de la puerta de enlace	URL de dominio personalizado de API Gateway (vista previa)	Máscara de URL
login	https://example.com/login	/<gateway>
login	https://example.com/home/login	/home/<gateway>
login	https://login.example.com	<gateway>.example.com
login	https://login.home.example.com	<gateway>.home.example.com

Crea un NEG sin servidores con una máscara de URL

Console

Para un balanceador de cargas nuevo, puedes usar el mismo proceso de extremo a extremo como se describió antes en este tema. Cuando configures el servicio de backend, en lugar de seleccionar un servicio específico, ingresa una máscara de URL.

Si tienes un balanceador de cargas existente, puedes editar la configuración del backend y hacer que el NEG sin servidores apunte a una máscara de URL en lugar de a un servicio específico.

Usa este comando para agregar un NEG sin servidores basado en máscaras de URL a un servicio de backend existente:

1. Ve a la página Balanceo de cargas en la consola de Google Cloud.
   Ir a la página Balanceo de cargas
2. Haz clic en el nombre del balanceador de cargas cuyo servicio de backend quieres editar.
3. En la página Detalles del balanceador de cargas, haz clic en Editar .
4. En la página Editar balanceador de cargas de aplicaciones externo global, haz clic en Configuración de backend.
5. En la página de Configuración de backend, haz clic en Editar  en el servicio de backend que deseas modificar.
6. Haz clic en Agregar backend.
7. Selecciona Crear grupo de extremos de red sin servidores.
   1. En Nombre, ingresa helloworld-serverless-neg.
   2. En Región, selecciona us-central1.
   3. En Tipo de grupo de extremos de red sin servidores, selecciona la plataforma en la que se crearon tus apps (o servicios o funciones).
      1. Selecciona Usar máscara de URL.
      2. Ingresa una máscara de URL. Para obtener instrucciones sobre cómo crear una máscara de URL, consulta Crea una máscara de URL.
      3. Haz clic en Crear.
8. En la sección Backend nuevo, haz clic en Listo.
9. Haz clic en Actualizar.

gcloud: Cloud Run

Para crear un NEG sin servidores con una máscara de URL de muestra de example.com/<service>, haz lo siguiente:

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

gcloud: Cloud Run Functions

Para crear un NEG sin servidores con una máscara de URL de muestra de example.com/<service>, haz lo siguiente:

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

gcloud: App Engine

Para crear un NEG sin servidores con una máscara de URL de muestra de example.com/<service>, haz lo siguiente:

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

gcloud: API Gateway

Para crear un NEG sin servidores con una máscara de URL de muestra de example.com/<gateway>, haz lo siguiente:

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 obtener información sobre cómo el balanceador de cargas controla los problemas con las discrepancias de la máscara de URL, consulta Soluciona problemas con NEG sin servidores.

Mueve tu dominio personalizado para que lo entregue el balanceador de cargas de aplicaciones externo

Si las apps de computación sin servidores se asignan a dominios personalizados, es recomendable que actualices los registros DNS para que el tráfico que se envía a las URLs de dominio personalizado de Cloud Run, funciones de Cloud Run, API Gateway o App Engine se enrute a través del balanceador de cargas.

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

Antes de actualizar los registros DNS, puedes probar la configuración de manera local si fuerzas la resolución de DNS local del dominio personalizado a la dirección IP del balanceador de cargas. Si deseas realizar una prueba local, modifica el archivo /etc/hosts/ en tu máquina local para apuntar example.com a la dirección IP del balanceador de cargas o usa la marca curl --resolve a fin de forzar a curl a usar la dirección IP del balanceador de cargas de la solicitud.

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

Nota: Si usas certificados administrados por Google, migrar un servicio existente a un balanceador de cargas de aplicaciones externo puede generar cierto tiempo de inactividad, por lo general, menos de una hora. Esto se debe a que el certificado SSL de tu balanceador de cargas de aplicaciones externo no se aprovisionará hasta que actualices tus registros DNS para que apunten a la dirección IP del balanceador de cargas.

Habilitar Cloud CDN

Habilitar Cloud CDN para tu servicio de Cloud Run te permite optimizar la entrega de contenido mediante el almacenamiento en caché del contenido cerca de tus usuarios.

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

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

Cloud CDN se admite en servicios de backend con backends de Cloud Run, funciones de Cloud Run, API Gateway y App Engine.

Habilita IAP en el balanceador de cargas de aplicaciones externo

Nota: Ten en cuenta que IAP no es compatible con Cloud CDN.

Puedes configurar IAP para que se habilite o inhabilite (predeterminado). Si se habilita, debes proporcionar valores para oauth2-client-id y oauth2-client-secret.

Para habilitar IAP, actualiza el servicio de backend a fin de 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 manera opcional, puedes habilitar IAP para un recurso de Compute Engine con la consola de Google Cloud, gcloud CLI o la API.

Habilita Google Cloud Armor

Google Cloud Armor es un producto de seguridad que brinda protección contra ataques de denegación de servicio distribuido (DSD) a todos los balanceadores de cargas de proxy GCLB. Google 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 cargas de aplicaciones externo. Si quieres obtener información sobre las políticas de seguridad de Google Cloud Armor para el balanceador de cargas de aplicaciones externo, consulta Descripción general de la política de seguridad de Google Cloud Armor.

Si usas funciones de Cloud Run, puedes asegurarte de que las solicitudes enviadas a URL predeterminadas estén bloqueadas mediante la configuración de entrada internal-and-gclb.

Si usas Cloud Run, puedes asegurarte de que las solicitudes enviadas a URLs predeterminadas o a cualquier otro dominio personalizado configurado mediante Cloud Run estén bloqueadas si restringes la entrada al “balanceo de cargas interno y en la nube”.

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

Sin la configuración de entrada adecuada, los usuarios pueden usar la URL predeterminada de la aplicación sin servidores 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.

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 la Descripción general del límite de frecuencia.

1. Para inhabilitar la política de seguridad predeterminada de Google Cloud Armor, selecciona None en el menú de lista de la política de seguridad de backend.
2. En la sección Seguridad, selecciona Política de seguridad predeterminada.
3. En el campo Nombre de la política, acepta el nombre que se genera automáticamente o ingresa un nombre para la política de seguridad.
4. En el campo Recuento de solicitudes, acepta el recuento de solicitudes predeterminado o ingresa un número entero entre 1 y 10,000.
5. En el campo Intervalo, selecciona un intervalo.
6. En el campo Aplicar en la clave, elige uno de los siguientes valores: Todos, Dirección IP o Dirección IP X‑Forwarded‑For. Para obtener más información sobre estas opciones, consulta Identifica clientes para el límite de frecuencia.

Habilita el registro y la supervisión

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

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

Actualiza el tiempo de espera de keepalive del HTTP del cliente

El balanceador de cargas creado en los pasos anteriores se configuró con un valor predeterminado para el tiempo de espera de keepalive de HTTP del cliente.

Para actualizar el tiempo de espera de keepalive del cliente HTTP, sigue las siguientes instrucciones.

Console

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

   Ir a Balanceo de cargas

2. Haz clic en el nombre del balanceador de cargas que deseas modificar.
3. Haz clic en Editar.
4. Haz clic en Configuración de frontend.
5. Expande Funciones avanzadas. Para el tiempo de espera de keepalive de HTTP, ingresa un valor de tiempo de espera.
6. Haz clic en Actualizar.
7. Para revisar los cambios, haz clic en Revisar y finalizar y, luego, haz clic en Actualizar.

gcloud

Para un balanceador de cargas de HTTP, actualiza el proxy HTTP de destino con el comandogcloud compute target-http-proxies update:

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

Para un balanceador de cargas de HTTPS, actualiza el proxy HTTPS de destino con el comandogcloud compute target-https-proxies update:

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

Reemplaza lo siguiente:

• TARGET_HTTP_PROXY_NAME: el nombre del proxy HTTP de destino.
• TARGET_HTTPS_PROXY_NAME: el nombre del proxy HTTPS de destino.
• HTTP_KEEP_ALIVE_TIMEOUT_SEC: El valor de tiempo de espera de keepalive de HTTP de 5 a 600 segundos.

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 servidores y reducir la cantidad de solicitudes enviadas a los NEGs sin servidores en mal estado.

La detección de valores atípicos se habilita en el servicio de backend con 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 califica como un error.
• El método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), en el que solo los códigos de estado HTTP 502, 503 y 504 califican como un error.

Sigue los pasos a continuación para habilitar la detección de valores atípicos para un servicio de backend existente. Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, algunas solicitudes se pueden enviar al servicio deteriorado y mostrar 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.

Console

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

   Ir a Balanceo de cargas

2. Haz clic en el nombre del balanceador de cargas cuyo servicio de backend quieres editar.

3. En la página Detalles del balanceador de cargas, haz clic en Editar.

4. En la página Editar balanceador de cargas de aplicaciones externo global, haz clic en Configuración de backend.

5. En la página de Configuración de backend, haz clic en Editar en el servicio de backend que deseas modificar.

6. Desplázate hacia abajo y expande la sección Configuración avanzada.

7. En la sección Detección de valores atípicos, selecciona la casilla de verificación Habilitar.

8. Haz clic en Editar para configurar la detección de valores atípicos.

   Verifica que las siguientes opciones estén configuradas con estos valores:

   Propiedad	Valor
   Errores consecutivos	5
   Interval	1000
   Tiempo de expulsión base	30,000
   Porcentaje de expulsión máximo	50
   Aplicación de errores consecutivos	100

   En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP 5xx consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.

9. Haz clic en Guardar.

10. Para actualizar el servicio de backend, haz clic en Actualizar.

11. Para actualizar el balanceador de cargas, en la página Edita el balanceador de cargas de aplicaciones externo global, haz clic en Actualizar.

gcloud

1. Exporta el servicio de backend a un archivo YAML.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME.yaml --global
   

   Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.

2. Edita la configuración YAML del servicio de backend para agregar los campos para la detección de valores atípicos, como se destaca en la siguiente configuración de YAML, en la sección outlierDetection:

   En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP 5xx consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.

   name: BACKEND_SERVICE_NAME
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
   outlierDetection:
     baseEjectionTime:
       nanos: 0
       seconds: 30
     consecutiveErrors: 5
     enforcingConsecutiveErrors: 100
     interval:
       nanos: 0
       seconds: 1
     maxEjectionPercent: 50
   port: 80
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
   sessionAffinity: NONE
   timeoutSec: 30
   ...
   

   Reemplaza lo siguiente:

   • BACKEND_SERVICE_NAME: es el nombre del servicio de backend.
   • PROJECT_ID: Es el ID de tu proyecto.
   • REGION_A y REGION_B: las regiones en las que se configuró el balanceador de cargas.
   • SERVERLESS_NEG_NAME: Es el nombre del primer NEG sin servidores.
   • SERVERLESS_NEG_NAME_2: es el nombre del segundo NEG sin servidores.

3. Para actualizar el servicio de backend, importa la configuración más reciente.

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
     --source=BACKEND_SERVICE_NAME.yaml --global
   

   La detección de valores atípicos ahora está habilitada en el servicio de backend.

Borra un NEG sin servidores

Si un grupo de extremos de red está vinculado a un servicio de backend, no se puede quitar. Antes de borrar un NEG, asegúrate de que esté desvinculado del servicio de backend.

Console

1. Para asegurarte de que el NEG sin servidores que desees borrar no esté en uso por algún servicio de backend, ve a la pestaña Servicios de backend en el menú avanzado del balanceo de cargas.
   Ir a la pestaña Servicios de backend
2. Si el NEG sin servidores está en uso actualmente:
   1. Haz clic en el nombre del servicio de backend mediante el NEG sin servidores.
   2. Haz clic en Editar .
   3. En la lista de Backends, haz clic en para quitar el backend de NEG sin servidores del servicio de backend.
   4. Haz clic en Guardar.
3. Ve a la página Grupo de extremos de red en la consola de Google Cloud.
   Ir a la página Grupos de extremos de red
4. Selecciona la casilla de verificación del NEG sin servidores que quieres borrar.
5. Haz clic en Borrar.
6. Haz clic en Borrar nuevamente para confirmar.

gcloud

Para quitar un NEG sin servidores de un servicio de backend, debes especificar la región en la que se creó el NEG. También debes especificar la marca --global, ya que helloworld-backend-service es un recurso global.

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

Para borrar el NEG sin servidores, haz lo siguiente:

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

¿Qué sigue?

• Usa Logging y Monitoring
• Solucionar problemas de NEG sin servidores
• Limpia la configuración del balanceador de cargas.
• Usa un módulo de Terraform para un balanceador de cargas de HTTPS externo con un backend de Cloud Run