Configurar un balanceador de carga de aplicación interno entre regiones con Cloud Run

En este documento se explica cómo desplegar un balanceador de carga de aplicación interno entre regiones con Cloud Run. Para configurarlo, usa un backend de NEG sin servidor para el balanceador de carga.

Aunque en este documento se describe una configuración de Cloud Run, un NEG sin servidor de Cloud Run puede apuntar a un recurso de Cloud Run o a un recurso de Cloud Functions (2.ª gen.).

Los NEGs sin servidor te permiten usar servicios de Cloud Run con tu balanceador de carga. Después de configurar un balanceador de carga con el backend de NEG sin servidor, las solicitudes al balanceador de carga se enrutan al backend de Cloud Run.

El balanceo de carga interregional proporciona redundancia, de modo que, si no se puede acceder a una región, el tráfico se desvía automáticamente a otra. En función de la ubicación de Envoy, el tráfico del proxy se distribuye a los servicios de Cloud Run de la siguiente manera:

  • Si los servicios de Cloud Run multirregionales se configuran en la misma región que Envoy, se prefiere el NEG que se encuentre 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 no está en buen estado.
  • Si los servicios de Cloud Run multirregionales no están configurados en la misma región que Envoy, el tráfico se distribuye de forma uniforme entre todos los NEGs. No se prefieren los NEGs que estén más cerca.
  • Si Identity-Aware Proxy está habilitado, solo se admite un NEG sin servidor. Sin embargo, puedes configurar servicios de Cloud Run adicionales, pero el balanceador de carga no les envía tráfico.

Antes de empezar

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

Desplegar un servicio de Cloud Run

En estas instrucciones, se presupone que ya tienes un servicio 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 desplegar un servicio de Cloud Run.

Para evitar que se acceda al servicio de Cloud Run desde Internet, restringe el acceso al internal. El tráfico del balanceador de carga de aplicaciones interno se considera tráfico interno.

Si colocas el servicio de Cloud Run en varias regiones, se evitan los fallos en una sola región. Para desplegar 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

Anota el nombre del servicio que crees. En el resto de esta página se explica cómo configurar un balanceador de carga que enrute las solicitudes a este servicio.

Configurar un recurso de certificado SSL

Crea un recurso de certificado SSL de Certificate Manager de la siguiente manera:

Te recomendamos que uses un certificado gestionado por Google.

Permisos

Para seguir esta guía, debes poder crear instancias y modificar una red en un proyecto. Debes ser propietario o editor del proyecto, o bien tener todos los roles de gestión de identidades y accesos de Compute Engine que se indican a continuación.

Tarea Rol necesario
Crear redes, subredes y componentes de balanceador de carga Administrador de red de Compute
Añadir y eliminar reglas de cortafuegos Administrador de seguridad de Compute
Crear instancias Administrador de instancias de Compute

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

Descripción general de la configuración

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

Balanceador de carga de aplicación interno entre regiones con un despliegue de Cloud Run.
Balanceador de carga de aplicación interno entre regiones con despliegue de Cloud Run (haz clic para ampliar la imagen).

Como se muestra en el diagrama, en este ejemplo se crea un balanceador de carga 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 carga de aplicaciones interno entre regiones se describe de la siguiente manera:

  1. Una red de VPC con las siguientes subredes:

    • Subred SUBNET_A y una subred de solo proxy en REGION_A.
    • Subred 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 carga de aplicación internos entre regiones. La subred de solo proxy de la región se comparte entre todos los balanceadores de carga de aplicaciones internos entre regiones de la región. Las direcciones de origen de los paquetes enviados desde el balanceador de carga a los backends de tu servicio se asignan desde la subred solo proxy. En este ejemplo, la subred solo proxy de la región REGION_A tiene un intervalo de direcciones IP principales de 10.129.0.0/23 y, en el caso de REGION_B, tiene un intervalo de direcciones IP principales de 10.130.0.0/23, que es el tamaño de subred recomendado.

  2. Una regla de cortafuegos que permita el flujo de tráfico de la subred de solo proxy en tu red. Esto significa añadir 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 intervalo de las subredes de solo proxy de este ejemplo).

  3. Otra regla de cortafuegos para las pruebas de comprobación del estado.

  4. Una configuración de alta disponibilidad que tiene back-ends sin servidor para despliegues de Cloud Run en las regiones REGION_A y REGION_B. Si los backends de una región no funcionan, el tráfico se redirige a la otra región.

  5. Un servicio de backend global que monitoriza el uso y el estado de los backends. Habilita la detección de valores atípicos en el servicio de backend.

  6. Un mapa de URLs 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 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 URLs. En el caso de HTTPS, configura un recurso de certificado SSL regional. El proxy de destino usa el certificado SSL para descifrar el tráfico SSL si configuras el balanceo de carga 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 carga, para reenviar cada solicitud entrante al proxy de destino.

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

    • La dirección IP puede (pero no tiene por qué) proceder de la misma subred que los grupos de instancias de backend.
    • La dirección IP no debe proceder de una subred reservada de solo proxy que tenga el valor GLOBAL_MANAGED_PROXY en su marca --purpose.
    • Si quieres usar la misma dirección IP interna con varias reglas de reenvío, asigna el valor --purpose a la marca de la dirección IP SHARED_LOADBALANCER_VIP.

  9. Opcional: configura políticas de enrutamiento de DNS de tipo GEO para enrutar el tráfico de los clientes a la dirección IP virtual del balanceador de carga en la región más cercana al cliente.

Configurar la red y las subredes

En la red de VPC, configura una subred en cada región en la que estén configurados tus back-ends. Además, configura un proxy-only-subnet en cada región en la que quieras configurar el balanceador de carga.

En este ejemplo se usan la siguiente red VPC, región y subredes:

  • Red La red es una red de VPC en modo personalizado llamada NETWORK.

  • Subredes para back-ends. Una subred llamada SUBNET_A en la región REGION_A usa 10.1.2.0/24 para su intervalo de IPs principal. La subred llamada SUBNET_B de la región REGION_B usa 10.1.3.0/24 para su intervalo de IPs principal.

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

Se puede acceder a los balanceadores de carga de aplicaciones internos entre regiones desde cualquier región de la VPC. De esta forma, los clientes de cualquier región pueden acceder a los backends de tu balanceador de carga a nivel mundial.

Configurar las subredes de backend

Consola

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

    Ir a redes de VPC

  2. Haz clic en Crear red VPC.

  3. Asigne un nombre a la red.

  4. En la sección Subredes, selecciona Personalizado en Modo de creación de subredes.

  5. Crea una subred para los back-ends del balanceador de carga. En la sección Nueva subred, introduce la siguiente información:

    • Asigna un nombre a la subred.
    • Selecciona una región: REGION_A
    • Introduce un intervalo de direcciones IP: 10.1.2.0/24

  6. Haz clic en Listo.

  7. Haz clic en Añadir subred.

  8. Crea una subred para los back-ends del balanceador de carga. En la sección Nueva subred, introduce la siguiente información:

    • Asigna un nombre a la subred.
    • Selecciona una región: REGION_B
    • Introduce un intervalo 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 de 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 de 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. Sustituye PROJECT_ID por el ID de tu 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. Sustituye PROJECT_ID por el ID de tu 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. Sustituye PROJECT_ID por el ID de tu 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",
}

Configurar la subred de solo proxy

Una subred de solo 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 con los back-ends.

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

Consola

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

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

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

    Ir a redes de VPC

  2. Haga clic en el nombre de la red VPC.
  3. En la pestaña Subredes, haz clic en Añadir subred.
  4. Asigna un nombre a la subred de solo proxy.
  5. En la lista Región, selecciona REGION_A.
  6. En la lista Propósito, selecciona Proxy gestionado entre regiones.
  7. En el campo Intervalo de direcciones IP, introduce 10.129.0.0/23.
  8. Haz clic en Añadir.

Crea la subred de solo proxy en REGION_B

  1. Haz clic en Añadir subred.
  2. Asigna un nombre a la subred de solo proxy.
  3. En la lista Región, selecciona REGION_B.
  4. En la lista Propósito, selecciona Proxy gestionado entre regiones.
  5. En el campo Intervalo de direcciones IP, introduce 10.130.0.0/23.
  6. Haz clic en Añadir.

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. Sustituye PROJECT_ID por el ID de tu 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"
    }

Crear los NEGs sin servidor

  1. Crea un NEG sin servidor 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

Configurar el balanceador de carga

El tráfico que va del balanceador de carga a los backends de NEG sin servidor usa rutas especiales definidas fuera de tu VPC que no están sujetas a reglas de firewall. Por lo tanto, si tu balanceador de carga solo tiene backends de NEG sin servidor, no tienes que crear reglas de cortafuegos para permitir que el tráfico de la subred de solo proxy llegue al backend sin servidor.

Consola

Selecciona el tipo de balanceador de carga

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

    Ir a Balanceo de carga

  2. Haga clic en Crear balanceador de carga.
  3. En Tipo de balanceador de carga, selecciona Balanceador de carga de aplicación (HTTP/HTTPS) y haz clic en Siguiente.
  4. En Público o interno, selecciona Interno y haz clic en Siguiente.
  5. En Implementación en una sola región o en varias regiones, selecciona La mejor opción para cargas de trabajo entre regiones y haz clic en Siguiente.
  6. Haz clic en Configurar.

Configuración básica

  1. Asigna un nombre al balanceador de carga.
  2. En Red, selecciona NETWORK.

Configurar el frontend con dos reglas de reenvío

Para HTTP:

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

      Reservar 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.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.2.99.
      • Selecciona Reservar.
  2. Haz clic en Listo.
  3. Para añadir la segunda regla de reenvío, haz clic en Añadir IP y puerto de frontend.
    1. Asigne un nombre a la regla de reenvío.
    2. En la lista Región de la subred, selecciona REGION_B.

      Reservar 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.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.3.99.
      • Selecciona Reservar.
  4. Haz clic en Listo.

En el caso de HTTPS:

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

Una vez que hayas creado el certificado gestionado por Google, adjunta el certificado directamente al proxy de destino. Los balanceadores de carga de aplicaciones internos entre regiones no admiten mapas de certificados.

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

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

      Reservar 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.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.3.99.
      • Selecciona Reservar.
    7. En la sección Añadir certificado, selecciona el certificado.
    8. Opcional: Para añadir certificados además del certificado SSL principal, sigue estos pasos:
      1. Haz clic en Añadir certificado.
      2. Selecciona el certificado de la lista.
    9. Selecciona una política de SSL de la lista Política de SSL. Si no has creado ninguna política de SSL, se aplicará una política de SSL predeterminada Google Cloud .
    10. Haz clic en Listo.

    Añade la segunda configuración de frontend:

    1. Asigna un nombre a la configuración del frontend.
    2. En el campo Protocol (Protocolo), selecciona HTTPS (includes HTTP/2).
    3. Asegúrate de que el Puerto esté configurado como 443.
    4. En la lista Región de la subred, selecciona REGION_B.

      Reservar 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.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.3.99.
      • Selecciona Reservar.
    7. En la sección Añadir certificado, selecciona el certificado.
    8. Opcional: Para añadir certificados además del certificado SSL principal, sigue estos pasos:
      1. Haz clic en Añadir certificado.
      2. Selecciona el certificado de la lista.
    9. Selecciona una política de SSL de la lista Política de SSL. Si no has creado ninguna política de SSL, se aplicará una política de SSL predeterminada Google Cloud .
    10. Haz clic en Listo.
    Configurar 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. Asigna un Nombre al servicio de backend.
    4. En Protocol (Protocolo), selecciona HTTP.
    5. En Puerto con nombre, introduce http.
    6. En la lista Tipo de backend, selecciona Grupo de endpoints de red sin servidor.
    7. En la sección Nuevo backend:
      • En la lista Grupo de endpoints de red sin servidor, selecciona gl7ilb-serverless-neg-a.
      • Haz clic en Listo.
      • Para añadir otro backend, haz clic en Añadir backend.
      • En la lista Grupo de endpoints de red sin servidor, selecciona gl7ilb-serverless-neg-b.
      • Haz clic en Listo.

    Configurar las reglas de enrutamiento

    1. Haz clic en Reglas de enrutamiento.
    2. En Modo, selecciona Regla sencilla de host y ruta.
    3. Asegúrate de que solo haya un servicio de backend para cualquier host y cualquier ruta sin coincidencia.

    Revisar la configuración

    1. Haz clic en Revisar y finalizar.
    2. Revisa los ajustes de configuración de tu balanceador de carga.
    3. Haz clic en Crear.

gcloud

  1. Define el servicio 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. Añade 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 URLs 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.

    En 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 gestionado por Google, consulta la siguiente documentación:

    Una vez que hayas creado el certificado gestionado por Google, adjúntalo directamente al proxy de destino. Los balanceadores de carga de aplicaciones internos entre regiones no admiten mapas de certificados.

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

    Asigna las rutas de los 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 de 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 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 dirección IP virtual (10.1.2.99) en la región REGION_B y otra con una dirección IP virtual (10.1.3.99) en la región REGION_A.

    En el caso de las redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que se trata de la subred de la instancia de la máquina virtual, no de la subred del proxy.

    En 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

Crea el servicio de backend global haciendo una solicitud POST al método backendServices.insert y sustituyendo PROJECT_ID por el ID de tu 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"
}

Crea el mapa de URLs haciendo una solicitud POST al método urlMaps.insert y sustituyendo PROJECT_ID por el ID de tu 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:

Crea el proxy HTTP de destino haciendo una solicitud POST al método targetHttpProxies.insert y sustituyendo PROJECT_ID por el ID de tu 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, haz una solicitud POST al método globalforwardingRules.insert y sustituye PROJECT_ID por el ID de tu 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 los archivos de certificado y clave privada y, a continuación, crea el certificado SSL. En el siguiente ejemplo se muestra cómo hacerlo con Python.

Crea el proxy HTTPS de destino enviando una solicitud POST al método targetHttpsProxies.insert y sustituyendo PROJECT_ID por el ID de tu 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, haz una solicitud POST al método globalForwardingRules.insert y sustituye PROJECT_ID por el ID de tu 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"
}

Probar el balanceador de carga

Ahora que el servicio de balanceo de carga está en funcionamiento, puedes enviar tráfico a la regla de reenvío y observar cómo se dispersa el tráfico a diferentes instancias.

Configurar la regla de cortafuegos

En este ejemplo, se necesita la regla de cortafuegos fw-allow-ssh para la VM del cliente de prueba. fw-allow-ssh es una regla de entrada que se aplica a la VM del cliente de prueba y que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un intervalo de direcciones IP de origen más restrictivo para esta regla. Por ejemplo, puedes especificar solo los intervalos 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 cortafuegos fw-allow-ssh para permitir la conectividad SSH a las VMs con la etiqueta de red allow-ssh. Si omite source-ranges, Google Cloud interpreta que la regla se aplica a cualquier fuente.

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

Crear una instancia de máquina virtual para probar la conectividad

  1. Crea una VM cliente:

    gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-12 \
    --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-12 \
    --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 esté sirviendo su nombre de host.

    • Verifica que la VM cliente pueda acceder a ambas direcciones IP. El comando se ejecuta correctamente y devuelve el nombre de la VM de backend que ha atendido la solicitud:

      Para las pruebas HTTP:

      curl 10.1.2.99

      curl 10.1.3.99

      Para probar HTTPS:

      curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.2.99:443

      curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.3.99:443

      Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.

      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 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:

Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME: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://DOMAIN_NAME:443' --connect-to DOMAIN_NAME: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 de conmutación por error

  1. Verifica la conmutación por error a los backends de la región REGION_A cuando los backends de las regiones REGION_B no estén en buen estado o no se pueda acceder a ellos. Para simularlo, quitamos todos los back-ends 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 cliente en REGION_B.

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

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

    Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.

    {
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME: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 amplía el ejemplo de configuración para ofrecer opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes llevarlas a cabo en el orden que quieras.

Usar una máscara de URL

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

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

Si aún no lo has hecho, lee la descripción general de NEGs sin servidor: máscaras de URL.

Crear una máscara de URL

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

  1. Quita http o https de la URL. Te quedan example.com/login.
  2. Sustituye el nombre del servicio por un marcador de posición de la máscara de URL.
    • Cloud Run: sustituye el nombre del servicio de Cloud Run por el marcador de posición <service>. Si el servicio de Cloud Run tiene una etiqueta asociada, sustituye el nombre de la etiqueta por el marcador de posición <tag>. En este ejemplo, la máscara de URL que queda es example.com/<service>.

  3. Opcional: Si el nombre del servicio se puede extraer de la parte de la ruta de la URL, se puede omitir el dominio. La parte de la ruta de la máscara de URL se distingue por el primer carácter de barra diagonal (/). Si no hay una barra inclinada (/) en la máscara de URL, se entiende que la máscara representa solo el host. Por lo tanto, en este ejemplo, la máscara de URL se puede reducir a /<service>.

    Del mismo modo, si se puede extraer <service> de la parte del host de la URL, puedes omitir la ruta por completo de la máscara de URL.

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

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

En esta tabla se da por hecho que tienes un dominio personalizado llamado example.com y que todos tus servicios de Cloud Run están asignados a este dominio.

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

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

Consola

En el caso de un nuevo balanceador de carga, puedes usar el mismo proceso integral que se ha descrito anteriormente en este documento. Cuando configures el servicio de backend, en lugar de seleccionar un servicio específico, introduce una máscara de URL.

Si ya tienes un balanceador de carga, puedes editar la configuración del backend para que el NEG sin servidor apunte a una máscara de URL en lugar de a un servicio específico.

Para añadir un NEG sin servidor basado en una máscara de URL a un servicio de backend, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Balanceo de carga.
    Ve a Balanceo de carga
  2. Haga clic en el nombre del balanceador de carga que tenga el servicio de backend que quiera editar.
  3. En la página Detalles del balanceador de carga, haga clic en Editar.
  4. En la página Editar balanceador de carga de aplicación externo global, haga 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 quieras modificar.
  6. Haz clic en Añadir backend.
  7. Selecciona Crear grupo de endpoints de red sin servidor.
    1. En Nombre, escribe helloworld-serverless-neg.
    2. En Región, se muestra la región del balanceador de carga.
    3. En Tipo de grupo de endpoints de red sin servidor, Cloud Run es el único tipo de grupo de endpoints de red admitido.
      1. Selecciona Usar máscara de URL.
      2. Introduce una máscara de URL. Para obtener información sobre cómo crear una máscara de URL, consulta el artículo Crear una máscara de URL.
      3. Haz clic en Crear.

  8. En Nuevo backend, haga clic en Hecho.
  9. Haz clic en Actualizar.

gcloud

Para crear un NEG sin servidor con una máscara de URL de ejemplo de example.com/<service>, sigue estos pasos:

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

Usar la misma dirección IP en varias reglas de reenvío internas

Para que varias reglas de reenvío internas compartan la misma dirección IP interna, debe reservar la dirección IP y definir 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 redirigir el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío que usen una dirección IP común. Para obtener más información, consulta el artículo Configurar el redireccionamiento de HTTP a HTTPS para balanceadores de carga de aplicaciones internos.

Configurar políticas de enrutamiento de DNS

Si tus clientes se encuentran en varias regiones, puede que quieras que tu balanceador de carga de aplicación interno entre regiones sea accesible mediante VIPs en esas regiones. Esta configuración multirregión minimiza la latencia y los costes de tránsito de red. Además, te permite configurar una solución de balanceo de carga global basada en DNS que proporciona resiliencia frente a las interrupciones regionales. Para obtener más información, consulta Gestionar políticas de enrutamiento de DNS y comprobaciones de estado.

gcloud

Para crear una entrada 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

Haz los cambios siguientes:

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

    Por ejemplo, service.example.com

  • REGION_A y REGION_B: las regiones en las que has configurado el balanceador de carga

API

Crea el registro DNS haciendo una solicitud POST al método ResourceRecordSets.create. Sustituye PROJECT_ID por el ID de tu 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 servidor que no estén en buen estado y reducir el número de solicitudes que se envían a esos NEGs.

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

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

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

Consola

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

    Ir a Balanceo de carga

  2. Haga clic en el nombre del balanceador de carga cuyo servicio de backend quiera editar.

  3. En la página Detalles del balanceador de carga, haga clic en Editar.

  4. En la página Editar balanceador de carga de aplicación interno entre regiones, haz clic en Configuración de backend.

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

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

  7. En la sección Detección de valores atípicos, selecciona la casilla 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
    Intervalo 1000
    Tiempo base de expulsión 30000
    Porcentaje máximo de expulsión 50
    Aplicar errores consecutivos 100

    En este ejemplo, el análisis de detección de anomalías se ejecuta cada segundo. Si el número de códigos de estado HTTP 5xx consecutivos que recibe un proxy Envoy es cinco o más, el endpoint de backend se expulsa del grupo de balanceo de carga de ese proxy Envoy durante 30 segundos. Cuando el porcentaje de aplicación es del 100%, el servicio backend aplica la expulsión de los endpoints que no están en buen estado de los grupos de balanceo de carga 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 endpoints de backend del grupo de balanceo de carga.

  9. Haz clic en Guardar.

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

  11. Para actualizar el balanceador de carga, en la página Editar balanceador de carga de aplicación interno entre regiones, haz clic en Actualizar.

gcloud

  1. Exporta el servicio backend a un archivo YAML.

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

    Sustituye BACKEND_SERVICE_NAME por el nombre del servicio backend.

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

    En este ejemplo, el análisis de detección de anomalías se ejecuta cada segundo. Si el número de códigos de estado HTTP 5xx consecutivos que recibe un proxy Envoy es cinco o más, el endpoint de backend se expulsa del grupo de balanceo de carga de ese proxy Envoy durante 30 segundos. Cuando el porcentaje de aplicación es del 100%, el servicio backend aplica la expulsión de los endpoints que no están en buen estado de los grupos de balanceo de carga 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 endpoints de backend del grupo de balanceo de carga. 

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

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre del servicio de backend
    • PROJECT_ID: el ID de tu proyecto
    • REGION_A y REGION_B: las regiones en las que se ha configurado el balanceador de carga.
    • SERVERLESS_NEG_NAME: el nombre del primer NEG sin servidor
    • SERVERLESS_NEG_NAME_2: el nombre del segundo NEG sin servidor

  3. Actualiza el servicio de backend importando 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.

Eliminar un NEG sin servidor

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

Consola

  1. Para asegurarte de que el NEG sin servidor que quieres eliminar no lo esté usando ningún servicio de backend, ve a la pestaña Servicios de backend de la página Componentes de balanceo de carga.
    Ve a Servicios de backend.
  2. Si el NEG sin servidor está en uso, haga lo siguiente:
    1. Haga clic en el nombre del servicio de backend que esté usando el NEG sin servidor.
    2. Haz clic en Editar.
    3. En la lista Backends (Backends), haga clic en para quitar el backend de NEG sin servidor del servicio de backend.
    4. Haz clic en Guardar.

  3. Ve a la página Grupo de puntos finales de red de la consola de Google Cloud Google Cloud.
    Ir a Grupo de puntos finales de red
  4. Marca la casilla de la NEG sin servidor que quieras eliminar.
  5. Haz clic en Eliminar.
  6. Haz clic en Eliminar de nuevo para confirmar la acción.

gcloud

Para quitar un NEG sin servidor de un servicio 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 eliminar el NEG sin servidor, sigue estos pasos:

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

Siguientes pasos