En este documento, se muestran ejemplos de cómo usar la administración del tráfico en algunos casos de uso específicos. Muchos otros casos prácticos son posibles.
El documento contiene ejemplos para los siguientes balanceadores de cargas:
- Balanceador de cargas de aplicaciones externo regional
- Balanceador de cargas de aplicaciones interno regional
- Balanceador de cargas de aplicaciones interno entre regiones
Balanceador de cargas de aplicaciones externo regional en comparación con el balanceador de cargas de aplicaciones interno regional. Para la configuración de administración del tráfico de los balanceadores de cargas regionales, la API de mapa de URL regional y la documentación de la API del servicio de backend regional proporcionan una lista completa de los campos, incluida la semántica sobre las relaciones, las restricciones y la cardinalidad.
La única diferencia entre estos dos balanceadores es el esquema de balanceo de cargas, que se muestra a continuación:
- Los balanceadores de cargas de aplicaciones externos regionales usan
EXTERNAL_MANAGED. - Los balanceadores de cargas de aplicaciones internos regionales usan
INTERNAL_MANAGED.
Balanceador de cargas de aplicaciones interno regional en comparación con el balanceador de cargas de aplicaciones interno entre regiones. Para la configuración de administración del tráfico, haz lo siguiente:
Los balanceadores de cargas de aplicaciones internos regionales usan la API de mapa de URL regional, y la documentación de la API del servicio de backend regional proporciona una lista completa de los campos, incluida la semántica sobre las relaciones, las restricciones y la cardinalidad.
Los balanceadores de cargas de aplicaciones internos entre regiones usan la API de mapa de URL global, y la documentación de la API del servicio de backend global proporciona una lista completa de los campos, incluidos la semántica sobre las relaciones, las restricciones y la cardinalidad.
Además de las funciones avanzadas de enrutamiento descritas en esta página, ciertos balanceadores de cargas de aplicaciones se integran con las extensiones del servicio para que puedas incorporar lógica personalizada en la ruta de datos del balanceo de cargas mediante la configuración de textos destacados de extensiones de servicio.
Antes de comenzar
Asegúrate de comprender cómo funciona la administración del tráfico. Para obtener más información, consulta los Conceptos de administración del tráfico.
Sigue las instrucciones en Configura un balanceador de cargas de aplicaciones interno y configura los clústeres de GKE o hosts de VM que necesites.
Crea la verificación de estado necesaria o vuelve a usar una existente, como se describe en Configura el balanceador de cargas.
Configura la administración del tráfico
En el entorno de configuración elegido, configura la administración del tráfico mediante configuraciones YAML. Un mapa de URL y un servicio de backend tienen cada uno su archivo YAML. Según la funcionalidad que desees, debes escribir un archivo YAML de mapa de URL, un archivo YAML de servicio de backend o ambos.
Si necesitas ayuda para escribir estos archivos YAML, puedes usar los ejemplos de esta página y la documentación de la API de Cloud Load Balancing.
Para el balanceador de cargas de aplicaciones interno regional, también puedes usar la consola de Google Cloud para configurar la administración del tráfico.En el caso de los balanceadores de cargas de aplicaciones internos y externos regionales, la API de mapa de URL regional y la documentación de API del servicio de backend regional proporcionan una lista completa de los campos, incluida la semántica sobre las relaciones, las restricciones y la cardinalidad.
Accede a los ejemplos de YAML en la consola de Google Cloud
Para acceder a los ejemplos de YAML en la consola de Google Cloud, sigue estos pasos:
En la consola de Google Cloud, ve a la página Balanceo de cargas.
- Haz clic en Crear balanceador de cargas.
- Completa los pasos del asistente para crear un balanceador de cargas de aplicaciones interno regional.
- En la configuración Reglas de enrutamiento, selecciona Host avanzado, ruta de acceso y regla de enrutamiento.
- Haz clic en Agregar hosts y comparadores de rutas de acceso.
- Haz clic en el vínculo Código de orientación.
Aparecerá la página Ejemplos de comparador de rutas de acceso YAML.
Asigna tráfico a un solo servicio
Envía todo el tráfico a un solo servicio. Asegúrate de reemplazar los marcadores de posición.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
Divide el tráfico entre dos servicios
Divide el tráfico entre dos o entre varios servicios. Asegúrate de reemplazar los marcadores de posición.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
weight: 5
Configura un redireccionamiento de la URL
En el ejemplo siguiente, se muestra un código de respuesta 3xx configurable. También establece el encabezado de respuesta Location con el URI apropiado, lo que reemplaza el host y la ruta de acceso como se especifica en la acción de redireccionamiento.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
urlRedirect:
hostRedirect: "new-host-name.com" # Omit to keep the requested host
pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
redirectResponseCode: FOUND
stripQuery: True
Duplica el tráfico
Además de reenviar la solicitud al servicio de backend seleccionado, envía una solicitud idéntica al servicio de backend duplicado y configurado en una base de enviar y olvidar. El balanceador de cargas no espera una respuesta del backend al que envía la solicitud duplicada. La duplicación es útil para probar una versión nueva de un servicio de backend. También puedes usarla para depurar errores de producción en una versión de depuración de tu servicio de backend, en lugar de hacerlo en la versión de producción.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
Vuelve a escribir la URL solicitada
Vuelve a escribir la parte del nombre de host de la URL, la parte de la ruta de la URL o ambas, antes de enviar una solicitud al servicio de backend seleccionado. Asegúrate de reemplazar los marcadores de posición.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
urlRewrite:
hostRewrite: "new-host-name.com" # Omit to keep the requested host
pathPrefixRewrite: "/new-path/" # Omit to keep the requested path
Reintentar una solicitud
Configura las condiciones en las que el balanceador de cargas reintenta enviar solicitudes con errores, cuánto espera el balanceador de cargas hasta volver a intentarlo y la cantidad máxima de reintentos permitidos.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
Especifica el tiempo de espera de la ruta
Especifica el tiempo de espera para la ruta seleccionada. El tiempo de espera se calcula desde el momento en que la solicitud se procesa por completo hasta que la respuesta hace lo mismo. El tiempo de espera incluye todos los reintentos. Asegúrate de reemplazar los marcadores de posición:
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 500000000
Configura la inserción de errores
Presenta errores cuando se entregan solicitudes para simular fallas, incluida la latencia alta, la sobrecarga del servicio, las fallas del servicio y la partición de la red. Esta característica es útil a fin de probar la resistencia de un servicio ante fallas simuladas.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 500000000
percentage: 25
abort:
httpStatus: 503
percentage: 50
Configurar CORS
Configura las políticas de uso compartido de recursos entre dominios (CORS) a fin de controlar la configuración para aplicar las solicitudes de CORS.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: my-domain.com
allowMethods: GET, POST
allowHeaders: Authorization, Content-Type
maxAge: 1200
allowCredentials: True
Agrega y quita encabezados de solicitud y respuesta
Agrega y quita encabezados de solicitud antes de enviar una solicitud al servicio de backend. Además, agrega y quita los encabezados de respuesta después de recibir una respuesta del servicio de backend.
Los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos también admiten el uso de variables en encabezados personalizados. Puedes especificar una o más variables en los campos del valor del encabezado personalizado (headerValue) que luego se traducen en sus valores correspondientes por solicitud. Para obtener una lista de valores de encabezado compatibles, consulta Crea encabezados personalizados en mapas de URL.
defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
headerAction:
requestHeadersToAdd:
- headerName: header-1-name
headerValue: header-1-value
replace: True
requestHeadersToRemove:
- header-2-name
- header-3-name
responseHeadersToAdd:
- headerName: header-4-name
headerValue: header-4-value
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
Configura la detección de valores atípicos
Especifica los criterios para la expulsión de las VM de backend o extremos en mal estado en los NEG, junto con criterios que definan cuándo un backend o extremo tiene un estado lo suficientemente bueno como para recibir tráfico otra vez. Asegúrate de reemplazar los marcadores de posición.
loadBalancingScheme: LOAD_BALANCING_SCHEME
localityLbPolicy: RANDOM
name: regions/REGION/backendServices/BACKEND_SERVICE_1
outlierDetection:
baseEjectionTime:
nanos: 0
seconds: '30'
consecutiveErrors: 5
consecutiveGatewayFailure: 3
enforcingConsecutiveErrors: 2
enforcingConsecutiveGatewayFailure: 100
enforcingSuccessRate: 100
interval:
nanos: 0
seconds: '1'
maxEjectionPercent: 50
successRateMinimumHosts: 5
successRateRequestVolume: 100
successRateStdevFactor: 1900
region: region/REGION
Configura la interrupción del circuito
La interrupción de circuitos te permite establecer umbrales de fallas para evitar que las solicitudes del cliente sobrecarguen tus backends. Una vez que las solicitudes alcanzan el límite que configuraste, el balanceador de cargas deja de permitir conexiones nuevas o de enviar solicitudes adicionales, lo que permite que los backends tengan tiempo de recuperarse. Por lo tanto, la interrupción de circuitos evita errores en cascada, ya que muestra un error al cliente en vez de sobrecargar un backend. Esto permite que se entregue parte del tráfico mientras se proporciona tiempo para administrar la situación de sobrecarga, como controlar un aumento repentino de tráfico mediante el aumento de la capacidad a través del ajuste de escala automático.
Establece límites máximos para las solicitudes por conexión y el volumen de conexiones a un servicio de backend. También limita la cantidad de solicitudes y reintentos pendientes.
loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
localityLbPolicy: RANDOM
affinityCookieTtlSec: 0
backends:
- balancingMode: UTILIZATION
capacityScaler: 1.0
group: region/REGION/instanceGroups/INSTANCE_GROUP
maxUtilization: 0.8
circuitBreakers:
maxConnections: 1000
maxPendingRequests: 200
maxRequests: 1000
maxRequestsPerConnection: 100
maxRetries: 3
connectionDraining:
drainingTimeoutSec: 0
healthChecks:
- region/REGION/healthChecks/HEALTH_CHECK
Configura la división de tráfico: pasos detallados
En este ejemplo, se muestran los siguientes pasos:
Crear plantillas distintas para servicios diferentes
Crear grupos de instancias para esas plantillas
Crea reglas de enrutamiento que configuren una división del tráfico del 95% / 5%.
Envía los comandos curl que muestren que los porcentajes de división del tráfico coinciden de forma aproximada con la configuración.
En estas instrucciones, se supone lo siguiente:
- La región es
us-west1. Se creó un proxy de destino y una regla de reenvío, junto con un mapa de URL llamado
regional-lb-map.El mapa de URL envía todo el tráfico a un servicio de backend llamado
red-service, que es el servicio de backend predeterminado.Configura una ruta alternativa que envíe el 5% del tráfico a
blue-servicey el 95% del tráfico agreen-service.Se usa un comparador de rutas.
Usas Cloud Shell o algún otro entorno con bash instalada.
Define los servicios
La siguiente función bash crea un servicio de backend, lo que incluye la plantilla de instancias y el grupo de instancias administrado.
En estas instrucciones, se supone que se creó una verificación de estado de HTTP (regional-lb-basic-check). Para obtener instrucciones, consulta Configura un balanceador de cargas de aplicaciones interno.
function make_service() {
local name="$1"
local region="$2"
local zone="$3"
local network="$4"
local subnet="$5"
local subdir="$6"
www_dir="/var/www/html/$subdir"
(set -x; \
gcloud compute instance-templates create "${name}-template" \
--region="$region" \
--network="$network" \
--subnet="$subnet" \
--tags=allow-ssh,load-balanced-backend \
--image-family=debian-10 \
--image-project=debian-cloud \
--metadata=startup-script="#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
sudo mkdir -p $www_dir
/bin/hostname | sudo tee ${www_dir}index.html
systemctl restart apache2"; \
gcloud compute instance-groups managed create \
"${name}-instance-group" \
--zone="$zone" \
--size=2 \
--template="${name}-template"; \
gcloud compute backend-services create "${name}-service" \
--load-balancing-scheme=LOAD_BALANCING_SCHEME\
--protocol=HTTP \
--health-checks=regional-lb-basic-check \
--health-checks-region="$region" \
--region="$region"; \
gcloud compute backend-services add-backend "${name}-service" \
--balancing-mode='UTILIZATION' \
--instance-group="${name}-instance-group" \
--instance-group-zone="$zone" \
--region="$region")
}
Crea los servicios
Llama a la función para crear tres servicios: red, green y blue. El servicio red actúa como el servicio predeterminado para las solicitudes a /. Los servicios green y blue se configuraron en /PREFIX para administrar el 95% y el 5% del tráfico, respectivamente.
make_service red us-west1 us-west1-a lb-network backend-subnet "" make_service green us-west1 us-west1-a lb-network backend-subnet /PREFIX make_service blue us-west1 us-west1-a lb-network backend-subnet /PREFIX
Crea el mapa de URL
gcloud
Exporta el mapa de URL existente con el comando
gcloud compute url-maps export:gcloud compute url-maps export regional-lb-map \ --destination=regional-lb-map-config.yaml \ --region=us-west1
Actualiza el archivo de mapa de URL
regional-lb-map-config.yaml. Para esto, agrega lo siguiente al final del archivo:hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: regions/us-west1/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: regions/us-west1/backendServices/green-service weight: 95 - backendService: regions/us-west1/backendServices/blue-service weight: 5Actualiza el mapa de URL con el comando
gcloud compute url-maps import:gcloud compute url-maps import regional-lb-map \ --region=us-west1 \ --source=regional-lb-map-config.yaml
Prueba la configuración
Para probar la configuración, primero asegúrate de que las solicitudes a la dirección IP que se configuró antes en el balanceador de cargas se manejen mediante la configuración red predeterminada.
Luego, asegúrate de que las solicitudes que se enviaron a FORWARDING_RULE_IP_ADDRESS/PREFIX estén divididas según lo esperado.
Crea una VM de cliente
Si deseas obtener instrucciones, consulta Crea una instancia de VM en la zona para probar la conectividad.
Envía solicitudes a FORWARDING_RULE_IP_ADDRESS
Usa
sshpara conectarte al cliente.gcloud compute ssh global-lb-client-us-west1-a \ --zone=us-west1-a
Ejecuta el siguiente comando:
for LB_IP in FORWARDING_RULE_IP_ADDRESS; do RESULTS= for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1 IFS=':' echo "***" echo "*** Results of load balancing to $LB_IP: " echo "***" for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c echo done
Verifica los resultados
*** ***Results of load balancing to FORWARDING_RULE_IP_ADDRESS: *** 502 red-instance-group-9jvq 498 red-instance-group-sww8
Envía solicitudes a FORWARDING_RULE_IP_ADDRESS/PREFIX
Envía solicitudes a FORWARDING_RULE_IP_ADDRESS/PREFIX y anota la división del tráfico.
for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
RESULTS=
for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1
IFS=':'
echo "***"
echo "*** Results of load balancing to $LB_IP/PREFIX: "
echo "***"
for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
echo
done
Verifica los resultados
*** ***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX: *** 21 blue-instance-group-8n49 27 blue-instance-group-vlqc 476 green-instance-group-c0wv 476 green-instance-group-rmf4
La configuración Canary envía con éxito el 95% de las solicitudes /PREFIX al servicio green y el 5% al servicio blue.
Configura la afinidad de sesión basada en HTTP_COOKIE
El control de tráfico te permite configurar la afinidad de sesión en función de una cookie proporcionada. Si deseas configurar la afinidad de sesión basada en HTTP_COOKIE para un servicio de backend llamado red-service, sigue estas instrucciones.
Usa el comando
gcloud compute backend-services exportpara obtener la configuración del servicio de backend.gcloud compute backend-services export red-service \ --destination=red-service-config.yaml \ --region=us-west1Actualiza el archivo
red-service-config.yamlde la siguiente manera:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 500000000 minimumRingSize: 10000En el archivo
red-service-config.yaml, incluye la siguiente línea:sessionAffinity: NONE
Actualiza el archivo de configuración del servicio de backend:
gcloud compute backend-services import red-service \ --source=red-service-config.yaml \ --region=us-west1
Soluciona problemas
Usa esta información para solucionar problemas cuando el tráfico no se enruta de acuerdo con las reglas de enrutamiento y las políticas de tráfico que configuraste.
Para obtener información sobre el registro y la supervisión, consulta la sección sobre el registro y la supervisión de HTTP(S) interno.Síntomas:
- Mayor tráfico a los servicios en reglas que se encuentran por encima de la regla en cuestión
- Aumento inesperado en las respuestas HTTP 4xx y 5xx para una regla de enrutamiento determinada
Solución: verifica el orden de tus reglas de enrutamiento. Las reglas de enrutamiento se interpretan en el orden en que se especifican.
Las reglas de enrutamiento dentro de una asignación de URL se interpretan en el orden en que se especifican. Esto las diferencia de las reglas de ruta de acceso, que se interpretan por la coincidencia de prefijo más largo. Para una regla de ruta de acceso, los balanceadores de cargas de aplicaciones internos solo seleccionarán una única regla de ruta de acceso; sin embargo, cuando usas reglas de enrutamiento, podría aplicarse más de una.
Cuando definas reglas de enrutamiento, asegúrate de que las reglas ubicadas en la parte superior de la lista no desvíen de forma involuntaria el tráfico que, de lo contrario, se enrutaría mediante una regla de enrutamiento posterior. Es probable que el servicio que recibe tráfico mal dirigido rechace las solicitudes y el servicio en tus reglas de enrutamiento reciba poco o nada de tráfico.