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. En función de la ubicación de Envoy, el tráfico de 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 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 no está en buen estado.
- Si los servicios multirregión de Cloud Run no se configuran en la misma región que Envoy, el tráfico se distribuye de forma uniforme entre 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 de Cloud Run adicionales, 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:
- Descripción general del balanceador de cargas de aplicaciones interno, incluida la sección Limitaciones
- Reglas de firewall de VPC
- Descripción general de los grupos de extremos de red sin servidores
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:
- Implementa un certificado auto-administrado global.
- Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
- Crea un certificado administrado por Google con autorización de DNS.
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 | Rol requerido |
---|---|
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:
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:
Una red de VPC con las siguientes subredes:
- Una subred de
SUBNET_A
y una subred de solo proxy enREGION_A
. - Una subred de
SUBNET_B
y una subred de solo proxy enREGION_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 de10.129.0.0/23
y paraREGION_B
tiene un rango de direcciones IP principal de10.130.0.0/23
que es el tamaño de subred recomendado.- Una subred de
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
y8080
desde10.129.0.0/23
y10.130.0.0/23
(el rango de la subredes de solo proxy en este ejemplo).Otra regla de firewall para las sondas de verificación de estado.
Una configuración de alta disponibilidad que tiene backends sin servidores para implementaciones de Cloud Run en regiones
REGION_A
yREGION_B
. Si los backends en una región están inactivos, el tráfico se dirige a la otra región.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.
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.
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.
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 comoGLOBAL_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
comoSHARED_LOADBALANCER_VIP
.
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ónREGION_A
usa10.1.2.0/24
para su rango de IP principal. La subred llamadaSUBNET_A
en la regiónREGION_B
usa10.1.3.0/24
para su rango de IP principal.Subred para proxies. Una subred llamada
PROXY_SN_A
en la regiónREGION_A
usa10.129.0.0/23
para su rango de IP principal. Una subred llamadaPROXY_SN_B
en la regiónREGION_B
usa10.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
En la consola de Google Cloud, ve a la página Redes de VPC.
Haz clic en Crear red de VPC.
Proporciona un Nombre para la red.
En la sección Subredes, establece Modo de creación de subred como Personalizado.
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
Haz clic en Listo.
Haz clic en Agregar subred.
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
Haz clic en Listo.
Haz clic en Crear.
gcloud
Crea la red de VPC personalizada con el comando
gcloud compute networks create
:gcloud compute networks create NETWORK --subnet-mode=custom
Crea una subred en la red
NETWORK
en la regiónREGION_A
con el comandogcloud compute networks subnets create
:gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=10.1.2.0/24 \ --region=REGION_A
Crea una subred en la red
NETWORK
en la regiónREGION_B
con el comandogcloud 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:
En la consola de Google Cloud, ve a la página Redes de VPC.
- Haz clic en el nombre de la red de VPC.
- En la pestaña Subredes, haz clic en Agregar subred.
- Proporciona un Nombre para la subred de solo proxy.
- En la lista Región, selecciona REGION_A.
- En la lista Propósito, selecciona Proxy administrado entre regiones.
- En el campo Rango de direcciones IP, ingresa
10.129.0.0/23
. - Haz clic en Agregar.
Crea la subred de solo proxy en REGION_B
- Haz clic en Agregar subred.
- Proporciona un Nombre para la subred de solo proxy.
- En la lista Región, selecciona REGION_B.
- En la lista Propósito, selecciona Proxy administrado entre regiones.
- En el campo Rango de direcciones IP, ingresa
10.130.0.0/23
. - 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
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
En la consola de Google Cloud, ve a la página Balanceo de cargas.
- Haz clic en Crear balanceador de cargas.
- En Tipo de balanceador de cargas, selecciona Balanceador de cargas de aplicaciones (HTTP/HTTPS) y haz clic en Siguiente.
- En Orientado al público o interno, selecciona Interno y haz clic en Siguiente.
- En Implementación entre regiones o de una sola región, selecciona Ideal para cargas de trabajo entre regiones y haz clic en Siguiente.
- Haz clic en Configurar.
Configuración básica
- Ingresa un Nombre para el balanceador de cargas.
- En Red, selecciona NETWORK.
Configura el frontend con dos reglas de reenvío
Para HTTP:
- Haz clic en Configuración de frontend.
- Proporciona un nombre para la regla de reenvío.
- En la lista Región de la subred, selecciona REGION_A.
Reserva una subred de solo proxy
- En la lista Subred, selecciona SUBNET_A.
- 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.
- Haz clic en Listo.
- Para agregar la segunda regla de reenvío, haz clic en Agregar IP y puerto de frontend.
- Proporciona un nombre para la regla de reenvío.
- En la lista Región de la subred, selecciona REGION_B.
Reserva una subred de solo proxy
- En la lista Subred, selecciona SUBNET_B.
- 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.
- 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 administrado por Google de all-regions
, consulta la siguiente documentación:
- Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
- Crea un certificado administrado por Google con autorización de DNS.
Después de crear el certificado administrado por Google, adjunta el certificado directamente al proxy de destino. Los mapas de certificados no son compatibles con los balanceadores de cargas de aplicaciones internos entre regiones.
Para crear un certificado autoadministrado de all-regions
, consulta la siguiente documentación:
Implementa un certificado autoadministrado regional.
- Haz clic en Configuración de frontend.
- Proporciona un nombre para la regla de reenvío.
- En el campo Protocolo, selecciona
HTTPS (includes HTTP/2)
. - Asegúrate de que el Puerto esté establecido en
443
. - En la lista Región de la subred, selecciona REGION_A.
Reserva una subred de solo proxy
- En la lista Subred, selecciona SUBNET_A.
- 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.
- En la sección Agregar certificado, selecciona el certificado.
- Opcional: Para agregar certificados además del certificado SSL principal, sigue estos pasos:
- Haz clic en Agregar certificado.
- Selecciona el certificado de la lista.
- 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.
- Haz clic en Listo.
- Proporciona un Nombre para la configuración del frontend.
- En el campo Protocolo, selecciona
HTTPS (includes HTTP/2)
. - Asegúrate de que el Puerto esté establecido en
443
. - En la lista Región de la subred, selecciona REGION_B.
Reserva una subred de solo proxy
- En la lista Subred, selecciona SUBNET_B.
- 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.
- En la sección Agregar certificado, selecciona el certificado.
- Opcional: Para agregar certificados además del certificado SSL principal, sigue estos pasos:
- Haz clic en Agregar certificado.
- Selecciona el certificado de la lista.
- 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.
- Haz clic en Listo.
- Haz clic en Configuración de backend.
- En la lista Crear o seleccionar servicios de backend, haz clic en Crear un servicio de backend.
- Proporciona un Nombre para el servicio de backend.
- En Protocolo, selecciona HTTP.
- En Puerto con nombre, ingresa
http
. - En la lista Tipo de backend, selecciona Grupo de extremos de red sin servidores.
- 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.
- Haga clic en Reglas de enrutamiento.
- En Modo, selecciona Regla sencilla de host y ruta de acceso.
- Asegúrate de que haya un solo servicio de backend para los hosts y las rutas de acceso no coincidentes.
- Haz clic en Revisar y finalizar.
- Revisa la configuración del balanceador de cargas.
- Haz clic en Crear.
Agrega la segunda configuración de frontend:
Configura las reglas de enrutamiento
Revisa la configuración
gcloud
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
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
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
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:
- Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service.
- Crea un certificado administrado por Google con autorización de DNS.
Después de crear el certificado administrado por Google, adjúntalo directamente al proxy de destino. Los mapas de certificados no son compatibles con los balanceadores de cargas de aplicaciones internos entre regiones.
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
Crea dos reglas de reenvío: una con una VIP (
10.1.2.99
) en la regiónREGION_B
y otra con una VIP (10.1.3.99
) en la regiónREGION_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 que se aplica 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
Crea la regla de firewall
fw-allow-ssh
para permitir la conectividad SSH a las VM con la etiqueta de redallow-ssh
. Cuando omitessource-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
Crea una VM de 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
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
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
Verifica la conmutación por error a los backends en la región
REGION_A
cuando los backends en la regiónREGION_B
estén en mal estado o sean inaccesibles. Para simular esto, quitamos todos los backends deREGION_B
:gcloud compute backend-services remove-backend gil7-backend-service \ --network-endpoint-group=gl7ilb-serverless-neg-b \ --network-endpoint-group-zone=ZONE_B
Conéctate mediante SSH a una VM de cliente en
REGION_B
.gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
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 enREGION_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.
- Quita
http
ohttps
de la URL. Quedaráexample.com/login
. - 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 esexample.com/<service>
.
- Cloud Run: reemplaza el nombre del servicio de Cloud Run por el marcador de posición
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:
- En la consola de Google Cloud, ve a la página Balanceo de cargas.
Ir a Balanceo de cargas - Haz clic en el nombre del balanceador de cargas que tiene el servicio de backend que deseas editar.
- En la página Detalles del balanceador de cargas, haz clic en Editar.
- En la página Editar balanceador de cargas de aplicaciones externo global, haz clic en Configuración de backend.
- En la página Configuración de backend, haz clic en Editar en el servicio de backend que deseas modificar.
- Haz clic en Agregar backend.
- Selecciona Crear grupo de extremos de red sin servidores.
- En Nombre, ingresa
helloworld-serverless-neg
. - En Región, se muestra la región del balanceador de cargas.
- En Tipo de grupo de extremos de red sin servidores, Cloud Run es el único tipo de grupo de extremos de red compatible.
- Selecciona Usar máscara de URL.
- 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.
- Haz clic en Crear.
- En el Backend nuevo, haz clic en Listo.
- 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
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 de varias regiones minimiza la latencia y los costos de tránsito de 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 las políticas de enrutamiento de DNS y las 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
yREGION_B
: las regiones en las que configuraste el balanceador de cargas.
API
Para crear el registro DNS, realiza 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 con uno de los siguientes métodos:
- El método
consecutiveErrors
(outlierDetection.consecutiveErrors
), en el que un código de estado HTTP de la serie5xx
califica como un error. - El método
consecutiveGatewayFailure
(outlierDetection.consecutiveGatewayFailure
), en el que solo los códigos de estado HTTP502
,503
y504
califican como un error.
Sigue los pasos a continuación para habilitar la detección de valores atípicos para un servicio de backend existente. Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, algunas solicitudes se pueden enviar al servicio deteriorado y mostrar un código de estado 5xx
a los clientes. Para reducir aún más la tasa de error, puedes configurar valores más agresivos para los parámetros de detección de valores atípicos. Para obtener más información, consulta el campo outlierDetection
.
Console
En la consola de Google Cloud, ve a la página Balanceo de cargas.
Haz clic en el nombre del balanceador de cargas cuyo servicio de backend quieres editar.
En la página Detalles del balanceador de cargas, haz clic en
Editar.En la página Editar balanceador de cargas de aplicaciones interno entre regiones, haz clic en Configuración de backend.
En la página de Configuración de backend, haz clic en
Editar en el servicio de backend que deseas modificar.Desplázate hacia abajo y expande la sección Configuración avanzada.
En la sección Detección de valores atípicos, selecciona la casilla de verificación Habilitar.
Haz clic en
Editar para configurar la detección de valores atípicos.Verifica que las siguientes opciones estén configuradas con estos valores:
Propiedad Valor Errores consecutivos 5 Interval 1000 Tiempo de expulsión base 30,000 Porcentaje de expulsión máximo 50 Aplicación de errores consecutivos 100 En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP
5xx
consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.Haz clic en Guardar.
Para actualizar el servicio de backend, haz clic en Actualizar.
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
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.Edita la configuración YAML del servicio de backend para agregar los campos para la detección de valores atípicos, como se destaca en la siguiente configuración de YAML, en la sección
outlierDetection
:En este ejemplo, el análisis de detección de valores atípicos se ejecuta cada segundo. Si la cantidad de códigos de estado HTTP
5xx
consecutivos que recibe un proxy de Envoy es de cinco o más, el extremo de backend se expulsa del grupo de balanceo de cargas de ese proxy de Envoy durante 30 segundos. Cuando el porcentaje de aplicación forzosa se establece en 100%, el servicio de backend aplica la expulsión de los extremos en mal estado de los grupos de balanceo de cargas de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los extremos de backend del grupo de balanceo de cargas.name: BACKEND_SERVICE_NAME backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2 outlierDetection: baseEjectionTime: nanos: 0 seconds: 30 consecutiveErrors: 5 enforcingConsecutiveErrors: 100 interval: nanos: 0 seconds: 1 maxEjectionPercent: 50 port: 80 selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME sessionAffinity: NONE timeoutSec: 30 ...
Reemplaza lo siguiente:
BACKEND_SERVICE_NAME
: es el nombre del servicio de backend.PROJECT_ID
: Es el ID de tu proyecto.REGION_A
yREGION_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.
Para actualizar el servicio de backend, importa la configuración más reciente.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME.yaml --global
La detección de valores atípicos ahora está habilitada en el servicio de backend.
Borra un NEG sin servidores
Si un grupo de extremos de red está vinculado a un servicio de backend, no se puede quitar. Antes de borrar un NEG, asegúrate de que esté desvinculado del servicio de backend.
Console
- 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 - Si el NEG sin servidores está en uso, haz lo siguiente:
- Haz clic en el nombre del servicio de backend que usa el NEG sin servidores.
- Haz clic en Editar.
- En la lista de Backends, haz clic en para quitar el backend de NEG sin servidores del servicio de backend.
- Haz clic en Guardar.
- Ve a la página Grupo de extremos de red en la consola de Google Cloud.
Ir al grupo de extremos de red - Selecciona la casilla de verificación del NEG sin servidores que quieres borrar.
- Haz clic en Borrar.
- 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?
- Implementa un balanceador de cargas de aplicaciones interno con Cloud Run mediante Terraform
- Limpia una configuración de balanceo de cargas
- Desaprovisiona la VPC compartida
- Registro y supervisión del balanceador de cargas de aplicaciones interno
- Soluciona problemas de balanceadores de cargas de aplicaciones internos