Configura un balanceador de cargas de aplicaciones interno entre regiones con Cloud Run

En este documento, se muestra cómo implementar un balanceador de cargas de aplicaciones interno entre regiones con Cloud Run. Para configurar esto, debes usar un backend de NEG sin servidores para el balanceador de cargas.

Los NEG sin servidores te permiten usar los servicios de Cloud Run con tu balanceador de cargas. 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 Cloud Run.

El balanceo de cargas interregional brinda redundancia de modo que, si no puede accederse a una región, el tráfico se desvía a otra de forma automática. Según la ubicación del Envoy, el tráfico del proxy se distribuye a los servicios de Cloud Run de la siguiente manera:

  • Si los servicios multirregionales de Cloud Run están configurados en la misma región que Envoy, se prefiere el NEG que se encuentra en la misma región que Envoy. El tráfico se envía a la región de conmutación por error solo si la detección de valores atípicos está habilitada y el NEG local está en mal estado.
  • Si los servicios multirregionales de Cloud Run no están configurados en la misma región que Envoy, el tráfico se distribuye de manera uniforme en todos los NEG. No se prefieren los NEG ubicados más cerca.
  • Si Identity-Aware Proxy está habilitado, solo se admite un único NEG sin servidores. Sin embargo, puedes configurar servicios adicionales de Cloud Run, pero el balanceador de cargas no les envía tráfico.

Antes de comenzar

Antes de seguir con esta guía, familiarízate con lo siguiente:

Implementa un servicio de Cloud Run

En las instrucciones de esta página, se da por sentado que ya tienes un servicio de Cloud Run en ejecución.

En el ejemplo de esta página, puedes usar cualquiera de las guías de inicio rápido de Cloud Run para implementar un servicio de Cloud Run.

Para evitar el acceso al servicio de Cloud Run desde internet, restringe la entrada a internal. El tráfico desde el balanceador de cargas de aplicaciones interno se considera tráfico interno.

Colocar el servicio de Cloud Run en varias regiones ayuda a evitar fallas en una única región. Para implementar el servicio de Cloud Run en las regiones REGION_A y REGION_B, ejecuta los siguientes comandos:

gcloud

gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_A \
   --image=IMAGE_URLA

gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_B \
   --image=IMAGE_URLB

Toma nota del nombre del servicio que crees. En el resto de esta página, se muestra cómo configurar un balanceador de cargas que enrute las solicitudes a este servicio.

Configura un recurso de certificado SSL

Crea un recurso de certificado SSL del Administrador de certificados de la siguiente manera:

Recomendamos que uses un certificado administrado por Google.

Permisos

Para seguir esta guía, debes poder crear instancias y modificar una red en un proyecto. Debes ser propietario o editor de un proyecto o tener todas las siguientes funciones de IAM de Compute Engine:

Tarea Función requerida
Crear redes, subredes y componentes del balanceador de cargas Administrador de red de Compute
Agrega y quita reglas de firewall Administrador de seguridad de Compute
Crea instancias Administrador de instancias de Compute

Si deseas obtener más información, consulta las siguientes guías:

Descripción general de la configuración

Puedes configurar el balanceador de cargas de aplicaciones interno entre regiones como se describe en el siguiente diagrama:

Balanceador de cargas de aplicaciones interno entre regiones con la implementación de Cloud Run.
Balanceador de cargas de aplicaciones interno entre regiones con la implementación de Cloud Run (haz clic para ampliar).

Como se muestra en el diagrama, este ejemplo crea un balanceador de cargas de aplicaciones interno entre regiones en una red de VPC, con un servicio de backend y dos implementaciones de Cloud Run en las regiones REGION_A y REGION_B.

La configuración del balanceador de cargas de aplicaciones interno entre regiones se describe de la siguiente manera:

  1. Una red de VPC con las siguientes subredes:

    • Una subred de SUBNET_A y una subred de solo proxy en REGION_A.
    • Una subred de SUBNET_B y una subred de solo proxy en REGION_B.

    Debes crear subredes de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de aplicaciones interno entre regiones. La subred de solo proxy de la región se comparte entre todos los balanceadores de cargas de aplicaciones internos entre regiones de la región. Las direcciones de origen de los paquetes enviados desde los balanceadores de cargas a los backends de tu servicio se asignan desde la subred de solo proxy. En este ejemplo, la subred solo de proxy para la región REGION_A tiene el rango principal de direcciones IP de 10.129.0.0/23 y para REGION_B tiene un rango de direcciones IP principal de 10.130.0.0/23 que es el tamaño de subred recomendado.

  2. Una regla de firewall que permite flujos de tráfico de subred de solo proxy en tu red. Esto significa que se agrega una regla que permita el tráfico de los puertos TCP 80, 443 y 8080 desde 10.129.0.0/23 y 10.130.0.0/23 (el rango de la subredes de solo proxy en este ejemplo).

  3. Otra regla de firewall para las sondas de verificación de estado.

  4. Una configuración de alta disponibilidad que tiene backends sin servidores para implementaciones de Cloud Run en las regiones REGION_A y REGION_B. Si los backends en una región están inactivos, el tráfico se dirige a la otra región.

  5. Un servicio de backend global que supervisa el uso y el estado de los backends. Asegúrate de habilitar la detección de valores atípicos en el servicio de backend.

  6. Un mapa de URL global que analiza la URL de una solicitud y reenvía las solicitudes a servicios de backend específicos en función del host y la ruta de acceso de la URL de la solicitud.

  7. Un proxy HTTP o HTTPS de destino global, que recibe una solicitud del usuario y la reenvía al mapa de URL. Para HTTPS, configura un recurso de certificado SSL regional. El proxy de destino usa el certificado SSL para desencriptar el tráfico SSL si configuras el balanceo de cargas de HTTPS. El proxy de destino puede reenviar tráfico a tus instancias mediante HTTP o HTTPS.

  8. Reglas de reenvío globales, que tienen la dirección IP interna de tu balanceador de cargas, para reenviar cada solicitud entrante al proxy de destino.

    La dirección IP interna asociada con la regla de reenvío puede provenir de cualquier subred en la misma red y región. Ten en cuenta las siguientes condiciones:

    • La dirección IP puede (pero no es necesario) provenir de la misma subred que los grupos de instancias de backend.
    • La dirección IP no debe provenir de la subred de solo proxy reservada que tiene la marca --purpose configurada como GLOBAL_MANAGED_PROXY.
    • Si deseas usar la misma dirección IP interna con varias reglas de reenvío, configura la marca de dirección IP --purpose como SHARED_LOADBALANCER_VIP.

  9. Opcional: Configura las políticas de enrutamiento de DNS del tipo GEO para enrutar el tráfico del cliente a la VIP del balanceador de cargas en la región más cercana al cliente.

Configura la red y las subredes

Dentro de la red de VPC, configura una subred en cada región en la que estén configurados los backends. Además, configura un proxy-only-subnet en cada región en la que desees configurar el balanceador de cargas.

Este ejemplo usa la siguiente red de VPC, región y subredes:

  • Red. Es una red de VPC de modo personalizado con el nombre NETWORK.

  • Subredes para backends. Una subred llamada SUBNET_A en la región REGION_A usa 10.1.2.0/24 para su rango de IP principal. La subred llamada SUBNET_A en la región REGION_B usa 10.1.3.0/24 para su rango de IP principal.

  • Subred para proxies. Una subred llamada PROXY_SN_A en la región REGION_A usa 10.129.0.0/23 para su rango de IP principal. Una subred llamada PROXY_SN_B en la región REGION_B usa 10.130.0.0/23 para su rango de IP principal.

Se puede acceder a los balanceadores de cargas de aplicaciones internos entre regiones desde cualquier región dentro de la VPC. Los clientes de cualquier región pueden acceder de manera global a los backends del balanceador de cargas.

Configura las subredes de backend

Console

  1. En la consola de Google Cloud, ve a la página Redes de VPC.

    Ir a las redes de VPC

  2. Haz clic en Crear red de VPC.

  3. Proporciona un Nombre para la red.

  4. En la sección Subredes, establece Modo de creación de subred como Personalizado.

  5. Crea una subred para los backends del balanceador de cargas. En la sección Nueva subred, ingresa la siguiente información:

    • Proporciona un Nombre para la subred.
    • Selecciona una Región: REGION_A
    • Ingresa un Rango de direcciones IP: 10.1.2.0/24

  6. Haz clic en Listo.

  7. Haz clic en Agregar subred.

  8. Crea una subred para los backends del balanceador de cargas. En la sección Nueva subred, ingresa la siguiente información:

    • Proporciona un Nombre para la subred.
    • Selecciona una Región: REGION_B
    • Ingresa un Rango de direcciones IP: 10.1.3.0/24

  9. Haz clic en Listo.

  10. Haz clic en Crear.

gcloud

  1. Crea la red de VPC personalizada con el comando gcloud compute networks create:

    gcloud compute networks create NETWORK --subnet-mode=custom

  2. Crea una subred en la red NETWORK en la región REGION_A con el comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A

  3. Crea una subred en la red NETWORK en la región REGION_B con el comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B

API

Realiza una solicitud POST al método networks.insert. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Realiza una solicitud POST al método subnetworks.insert. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Realiza una solicitud POST al método subnetworks.insert. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configura la subred solo de proxy

La subred solo de proxy proporciona un conjunto de direcciones IP que Google Cloud usa para ejecutar proxies de Envoy en tu nombre. Los proxies finalizan las conexiones del cliente y crean conexiones a los backends.

Todos los balanceadores de cargas regionales basados en Envoy usan esta subred de solo proxy en la misma región de la red de VPC . Solo puede haber una subred de solo proxy activa para un propósito determinado, por región, por red.

Console

Si usas la consola de Google Cloud, puedes esperar y crear la subred de solo proxy más adelante en la página Balanceo de cargas.

Si quieres crear la subred de solo proxy ahora, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Redes de VPC.

    Ir a las redes de VPC

  2. Haz clic en el nombre de la red de VPC.
  3. En la pestaña Subredes, haz clic en Agregar subred.
  4. Proporciona un Nombre para la subred de solo proxy.
  5. En la lista Región, selecciona REGION_A.
  6. En la lista Propósito, selecciona Proxy administrado entre regiones.
  7. En el campo Rango de direcciones IP, ingresa 10.129.0.0/23.
  8. Haz clic en Agregar.

Crea la subred de solo proxy en REGION_B

  1. Haz clic en Agregar subred.
  2. Proporciona un Nombre para la subred de solo proxy.
  3. En la lista Región, selecciona REGION_B.
  4. En la lista Propósito, selecciona Proxy administrado entre regiones.
  5. En el campo Rango de direcciones IP, ingresa 10.130.0.0/23.
  6. Haz clic en Agregar.

gcloud

Crea las subredes de solo proxy con el comando gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

API

Crea las subredes de solo proxy con el método subnetworks.insert y reemplaza PROJECT_ID por el ID del proyecto.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

Crea los NEG sin servidores

  1. Crea un NEG sin servidores para tu servicio de Cloud Run:

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \
   --region=REGION_A \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \
   --region=REGION_B \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB

Configura el balanceador de cargas

El tráfico que va desde el balanceador de cargas hasta los backends de NEG sin servidores usa rutas especiales definidas fuera de la VPC que no están sujetas a las reglas de firewall. Por lo tanto, si tu balanceador de cargas solo tiene backends de NEG sin servidores, no necesitas crear reglas de firewall para permitir el tráfico desde la subred de solo proxy al backend 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 Interno y haz clic en Siguiente.
  5. En Implementación entre regiones o de una sola región, selecciona Ideal para cargas de trabajo entre regiones y haz clic en Siguiente.
  6. Haz clic en Configurar.

Configuración básica

  1. Ingresa un Nombre para el balanceador de cargas.
  2. En Red, selecciona NETWORK.

Configura el frontend con dos reglas de reenvío

Para HTTP:

  1. Haz clic en Configuración de frontend.
    1. Proporciona un nombre para la regla de reenvío.
    2. En la lista Región de subred, selecciona REGION_A.

      Reserva una subred de solo proxy

    3. En la lista Subred, selecciona SUBNET_A.
    4. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Proporciona un Nombre para la dirección IP estática.
      • En la sección Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, ingresa 10.1.2.99.
      • Selecciona Reservar.
  2. Haz clic en Listo.
  3. Para agregar la segunda regla de reenvío, haz clic en Agregar IP y puerto de frontend.
    1. Proporciona un nombre para la regla de reenvío.
    2. En la lista Región de subred, selecciona REGION_B.

      Reserva una subred de solo proxy

    3. En la lista Subred, selecciona SUBNET_B.
    4. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Proporciona un Nombre para la dirección IP estática.
      • En la sección Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, ingresa 10.1.3.99.
      • Selecciona Reservar.
  4. Haz clic en Listo.

Para HTTPS:

Si usas HTTPS entre el cliente y el balanceador de cargas, necesitas uno o más recursos de certificado SSL para configurar el proxy. Para crear un certificado all-regions administrado por Google, consulta la siguiente documentación:

Después de crear el certificado administrado por Google, adjunta el certificado directamente al proxy de destino. Los balanceadores de cargas de aplicaciones internos entre regiones no admiten mapas de certificados.

Para crear un certificado autoadministrado all-regions, consulta la siguiente documentación: Implementa un certificado autoadministrado regional.

  1. Haz clic en Configuración de frontend.
    1. Proporciona un nombre para la regla de reenvío.
    2. En el campo Protocolo, selecciona HTTPS (includes HTTP/2).
    3. Asegúrate de que el Puerto esté establecido en 443.
    4. En la lista Región de subred, selecciona REGION_A.

      Reserva una subred de solo proxy

    5. En la lista Subred, selecciona SUBNET_A.
    6. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Proporciona un Nombre para la dirección IP estática.
      • En la sección Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, ingresa 10.1.3.99.
      • Selecciona Reservar.
    7. En la sección Agregar certificado, selecciona el certificado.
    8. Opcional: Para agregar certificados además del certificado SSL principal, sigue estos pasos:
      1. Haz clic en Agregar certificado.
      2. Selecciona el certificado de la lista.
    9. Selecciona una política de SSL de la lista Política de SSL. Si no creaste ninguna política de SSL, se aplica una política predeterminada de Google Cloud SSL.
    10. Haz clic en Listo.

    Agrega la segunda configuración de frontend:

    1. Proporciona un Nombre para la configuración de frontend.
    2. En el campo Protocolo, selecciona HTTPS (includes HTTP/2).
    3. Asegúrate de que el Puerto esté establecido en 443.
    4. En la lista Región de subred, selecciona REGION_B.

      Reserva una subred de solo proxy

    5. En la lista Subred, selecciona SUBNET_B.
    6. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Proporciona un Nombre para la dirección IP estática.
      • En la sección Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, ingresa 10.1.3.99.
      • Selecciona Reservar.
    7. En la sección Agregar certificado, selecciona el certificado.
    8. Opcional: Para agregar certificados además del certificado SSL principal, sigue estos pasos:
      1. Haz clic en Agregar certificado.
      2. Selecciona el certificado de la lista.
    9. Selecciona una política de SSL de la lista Política de SSL. Si no creaste ninguna política de SSL, se aplica una política predeterminada de Google Cloud SSL.
    10. Haz clic en Listo.
    Configura el servicio de backend
    1. Haz clic en Configuración de backend.
    2. En la lista Crear o seleccionar servicios de backend, haz clic en Crear un servicio de backend.
    3. Proporciona un Nombre para el servicio de backend.
    4. En Protocolo, selecciona HTTP.
    5. En Puerto con nombre, ingresa http.
    6. En la lista Tipo de backend, selecciona Grupo de extremos de red sin servidores.
    7. En la sección Nuevo backend, sigue estos pasos:
      • En la lista Grupo de extremos de red sin servidores, selecciona gl7ilb-serverless-neg-a.
      • Haz clic en Listo.
      • Para agregar otro backend, haz clic en Agregar backend.
      • En la lista Grupo de extremos de red sin servidores, selecciona gl7ilb-serverless-neg-b.
      • Haz clic en Listo.

    Configura las reglas de enrutamiento

    1. Haga clic en Reglas de enrutamiento.
    2. En Modo, selecciona Regla sencilla de host y ruta de acceso.
    3. Asegúrate de que solo haya un servicio de backend para los hosts y rutas de acceso no coincidentes.

    Revisa la configuración

    1. Haz clic en Revisar y finalizar.
    2. Revisa la configuración del balanceador de cargas.
    3. Haz clic en Crear.

gcloud

  1. Define el servicio de backend con el comando gcloud compute backend-services create.

    gcloud compute backend-services create gil7-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

  2. Agrega backends al servicio de backend con el comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-a \
  --network-endpoint-group-region=REGION_A \
  --global

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-b \
  --network-endpoint-group-region=REGION_B \
  --global

  3. Crea el mapa de URL con el comando gcloud compute url-maps create.

    gcloud compute url-maps create gil7-map \
  --default-service=gil7-backend-service \
  --global

  4. Crea el proxy de destino.

    Para HTTP:

    Crea el proxy de destino con el comando gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create gil7-http-proxy \
  --url-map=gil7-map \
  --global

    Para HTTPS:

    Para crear un certificado administrado por Google, consulta la siguiente documentación:

    Después de crear el certificado administrado por Google, adjunta el certificado directamente al proxy de destino. Los balanceadores de cargas de aplicaciones internos entre regiones no admiten mapas de certificados.

    Para crear un certificado autoadministrado, consulta la siguiente documentación:

    Asigna tus rutas de archivos a nombres de variables.

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE

    export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE

    Crea un certificado SSL para todas las regiones con el comando gcloud certificate-manager certificates create.

    gcloud certificate-manager certificates create gilb-certificate \
  --private-key-file=$LB_PRIVATE_KEY \
  --certificate-file=$LB_CERT \
  –-scope=all-regions

    Usa el certificado SSL regional para crear un proxy de destino con el comando gcloud compute target-https-proxies create.

    gcloud compute target-https-proxies create gil7-https-proxy \
  --url-map=gil7-map \
  --certificate-manager-certificates=gilb-certificate

  5. Crea dos reglas de reenvío: una con una VIP (10.1.2.99) en la región REGION_B y otra con una VIP (10.1.3.99) en la región REGION_A.

    Para redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que esta es la subred de la instancia de máquina virtual (VM), no la subred de proxy.

    Para HTTP:

    Usa el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    Para HTTPS:

    Crea la regla de reenvío con el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --address=10.1.3.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --address=10.1.2.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

API

Para crear el servicio de backend global, realiza una solicitud POST al método backendServices.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gil7-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast",
  }
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Para crear el mapa de URL, realiza una solicitud POST al método urlMaps.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service"
}

Para HTTP:

Para crear el proxy HTTP de destino, realiza una solicitud POST al método targetHttpProxies.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map"
}

Para crear la regla de reenvío, realiza una solicitud POST al método globalforwardingRules.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Para HTTPS:

Lee el certificado y los archivos de claves privadas y, luego, crea el certificado SSL. En el siguiente ejemplo, se muestra cómo hacer esto con Python.

Para crear el proxy de HTTPS de destino, realiza una solicitud POST al método targetHttpsProxies.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

Para crear la regla de reenvío, realiza una solicitud POST al método globalForwardingRules.insert y reemplaza PROJECT_ID por el ID del proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Prueba el balanceador de cargas

Ahora que el servicio de balanceo de cargas está en ejecución, puedes enviar tráfico a la regla de reenvío y ver cómo este se dispersa en las diferentes instancias.

Cómo configurar la regla de firewall

En este ejemplo, se requiere la fw-allow-ssh regla de firewall para la VM de cliente de prueba: fw-allow-ssh es una regla de entrada aplicable a la VM de cliente de prueba y que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de direcciones IP de origen más restrictivo para esta regla; por ejemplo, puedes especificar solo los rangos de direcciones IP del sistema desde el que inicias sesiones SSH. En este ejemplo, se usa la etiqueta de destino allow-ssh.

gcloud

  1. Crea la regla de firewall fw-allow-ssh para permitir la conectividad SSH a las VM con la etiqueta de red allow-ssh. Cuando omites source-ranges, Google Cloud interpreta que la regla significa cualquier fuente.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Crea una instancia de VM para probar la conectividad

  1. Crea una VM de cliente:

    gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

    gcloud compute instances create l7-ilb-client-b \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

  2. Conéctate mediante SSH a cada instancia de cliente:

    gcloud compute ssh l7-ilb-client-a \
   --zone=ZONE_A

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Verifica que la dirección IP entregue su nombre de host.

    • Verifica que la VM del cliente pueda acceder a ambas direcciones IP. El comando se ejecuta correctamente y muestra el nombre de la VM de backend que entregó la solicitud:

      curl 10.1.2.99

      curl 10.1.3.99

      Para la prueba de HTTPS, reemplaza curl por lo siguiente:

      curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443

      curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443

      La marca -k hace que curl omita la validación del certificado.

    • (Opcional): Usa el registro DNS configurado para resolver la dirección IP.

      curl service.example.com

Ejecuta 100 solicitudes y confirma que sus cargas estén balanceadas

Para HTTP:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.3.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Para HTTPS:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Prueba la conmutación por error

  1. Verifica la conmutación por error a los backends en la región REGION_A cuando los backends en la región REGION_B estén en mal estado o sean inaccesibles. Simulamos esto mediante la eliminación de todos los backends de REGION_B:

    gcloud compute backend-services remove-backend gil7-backend-service \
   --network-endpoint-group=gl7ilb-serverless-neg-b \
   --network-endpoint-group-zone=ZONE_B

  2. Conéctate mediante SSH a una VM de cliente en REGION_B.

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Envía solicitudes a la dirección IP del balanceo de cargas en la región REGION_B. El resultado del comando muestra respuestas de las VMs de backend en REGION_A:

    {
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

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.

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 múltiples servicios que entregan en el mismo dominio. Una máscara de URL es una plantilla del esquema de URL. El NEG sin servidores usa 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. En este ejemplo, se usa una app sin servidores de muestra que se ejecuta en https://example.com/login. Esta es la URL en la que se entrega 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.
    • 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>.

  3. Opcional: Si el nombre del servicio se puede extraer de la porción de la ruta 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 de barra oblicua (/). Si la barra oblicua (/) 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>.

    De manera similar, si el <service> se puede extraer 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:

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

Servicio, nombre de la etiqueta URL de dominio personalizado de Cloud Run 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>

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

Sigue estos pasos para agregar un NEG sin servidores basado en máscaras de URL a un servicio de backend existente:

  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 tiene el servicio de backend que deseas 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 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, se muestra la región del balanceador de cargas.
    3. En Tipo de grupo de extremos de red sin servidores, Cloud Run es el único tipo de grupo de extremos de red compatible.
      1. Selecciona Usar máscara de URL.
      2. Ingresa una máscara de URL. Para obtener información sobre cómo crear una máscara de URL, consulta Crea una máscara de URL.
      3. Haz clic en Crear.

  8. En el Backend nuevo, haz clic en Listo.
  9. Haz clic en Actualizar.

gcloud

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

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

Usa la misma dirección IP entre varias reglas de reenvío internas

Para que varias reglas de reenvío interno compartan una dirección IP interna común, debes reservar la dirección IP y establecer su marca --purpose en SHARED_LOADBALANCER_VIP.

gcloud 

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Si necesitas redireccionar el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío que use una dirección IP común. Si deseas obtener más información, consulta Configura el redireccionamiento de HTTP a HTTPS para balanceadores de cargas de aplicaciones internos.

Configura políticas de enrutamiento de DNS

Si tus clientes están en varias regiones, es posible que desees hacer que el balanceador de cargas de aplicaciones interno entre regiones sea accesible mediante VIPs en estas regiones. Esta configuración multirregional minimiza la latencia y los costos de tránsito de la red. Además, te permite configurar una solución de balanceo de cargas global basada en DNS que proporcione resiliencia contra interrupciones regionales. Para obtener más información, consulta Administra políticas de enrutamiento de DNS y verificaciones de estado.

gcloud

Para crear una entrada de DNS con un TTL de 30 segundos, usa el comando gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

Reemplaza lo siguiente:

  • DNS_ENTRY: el nombre de dominio o DNS del conjunto de registros.

    Por ejemplo, service.example.com

  • REGION_A y REGION_B: las regiones en las que configuraste el balanceador de cargas.

API

Crea el registro DNS mediante una solicitud POST al método ResourceRecordSets.create. Reemplaza PROJECT_ID con el ID del proyecto.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

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 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 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 en mal estado 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 el balanceador de cargas de aplicaciones interno entre regiones, 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 se establece en el 100%, el servicio de backend aplica la expulsión de 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 interno entre regiones, 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 se establece en el 100%, el servicio de backend aplica la expulsión de 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. Importa la configuración más reciente para actualizar el servicio de backend.

    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 parte de algún servicio de backend, ve a la pestaña Servicios de backend en la página Componentes de balanceo de cargas.
    Ir a Servicios de backend
  2. Si el NEG sin servidores está en uso, haz lo siguiente:
    1. Haz clic en el nombre del servicio de backend que usa 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 al grupo 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.

gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=SERVERLESS_NEG_NAME \
    --network-endpoint-group-region=REGION \
    --region=REGION

Para borrar el NEG sin servidores, haz lo siguiente:

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \
    --region=REGION

¿Qué sigue?