Configurar la gestión del tráfico para balanceadores de carga de aplicaciones internos

En este documento se muestran ejemplos de cómo usar la gestión del tráfico en algunos casos prácticos específicos. Hay muchos otros casos prácticos posibles.

El documento contiene ejemplos de los siguientes balanceadores de carga:

  • Balanceador de carga de aplicación externo regional
  • Balanceador de carga de aplicación interno regional
  • Balanceador de carga de aplicación interno entre regiones

Balanceador de carga de aplicación externo regional frente a balanceador de carga de aplicación interno regional. Para la configuración de gestión del tráfico de los balanceadores de carga regionales, la API de mapas de URLs regionales y la documentación de la API de servicios de backend regionales proporcionan una lista completa de campos, incluida la semántica relativa a las relaciones, las restricciones y la cardinalidad.

La única diferencia entre estos dos balanceadores de carga es el esquema de balanceo de carga, que es el siguiente:

  • Los balanceadores de carga de aplicación externos regionales usan EXTERNAL_MANAGED.
  • Los balanceadores de carga de aplicación internos regionales usan INTERNAL_MANAGED.

Balanceador de carga de aplicación interno regional frente a balanceador de carga de aplicación interno entre regiones Para la configuración de gestión del tráfico:

Además de las funciones de enrutamiento avanzadas que se describen en esta página, los balanceadores de carga de aplicaciones compatibles se integran con las extensiones de servicio para permitirte insertar lógica personalizada en la ruta de datos de balanceo de carga.

Antes de empezar

Configurar la gestión del tráfico

En el entorno de configuración que elijas, puedes configurar la gestión del tráfico mediante configuraciones YAML. Un mapa de URLs y un servicio de backend tienen cada uno su propio archivo YAML. En función de la función que quieras, debes escribir un archivo YAML de mapa de URLs, un archivo YAML de servicio de backend o ambos.

Para obtener ayuda a la hora de escribir estos archivos YAML, puedes usar los ejemplos de esta página y la documentación de la API Cloud Load Balancing.

En el caso de los balanceadores de carga de aplicaciones internos regionales, también puedes usar la Google Cloud consola para configurar la gestión del tráfico.

En el caso de los balanceadores de carga de aplicación internos regionales y los balanceadores de carga de aplicación externos regionales, la documentación de la API de mapas de URLs regionales y la de la API de servicios backend regionales proporciona una lista completa de campos, incluida la semántica relativa a las relaciones, las restricciones y la cardinalidad.

Acceder a los ejemplos de YAML en la consola de Google Cloud

Para acceder a ejemplos de YAML en la Google Cloud consola, sigue estos pasos:

  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. Sigue los pasos del asistente para crear un balanceador de carga de aplicaciones interno regional.
  4. En la configuración Reglas de enrutamiento, selecciona Regla de host, ruta y direccionamiento avanzada.
  5. Haz clic en Añadir hosts y coincidencia de ruta.
  6. Haz clic en el enlace Guía de código.

Se abrirá la página YAML de ejemplos del comparador de rutas.

Asignar tráfico a un solo servicio

Envía todo el tráfico a un solo servicio. Sustituye los marcadores de posición.

    defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

Dividir el tráfico entre dos servicios

Dividir el tráfico entre dos o varios servicios. Sustituye los marcadores de posición.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
           weight: 5

Configurar una redirección de URL

En el siguiente ejemplo se devuelve un código de respuesta 3xx configurable. En el ejemplo también se define el encabezado de respuesta Location con el URI adecuado, sustituyendo el host y la ruta tal como se especifica en la acción de redirección.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: URL_MAP_NAME
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

Duplicar tráfico

Además de reenviar la solicitud al servicio de backend seleccionado, puede enviar una solicitud idéntica al servicio de backend de réplica configurado de forma inmediata. Esto significa que el balanceador de carga no espera una respuesta del backend al que envía la solicitud reflejada. La duplicación de solicitudes es útil para probar una nueva versión de un servicio de backend. También puedes usarlo para depurar errores de producción en una versión de depuración de tu servicio backend, en lugar de en la versión de producción.

De forma predeterminada, el servicio de backend reflejado recibe todas las solicitudes, aunque el tráfico original se divida entre varios servicios de backend ponderados. Puede configurar el servicio de backend reflejado para que reciba solo un porcentaje de las solicitudes mediante la marca opcional mirrorPercent, que le permite especificar el porcentaje de solicitudes que se reflejarán (expresado como un valor entre 0 y 100,0). La réplica de solicitudes basada en porcentajes está en versión preliminar.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

Ten en cuenta las siguientes limitaciones al usar la creación de reflejo del tráfico:

  • La duplicación de tráfico se admite cuando ambos servicios de backend tienen grupos de instancias gestionados, NEGs zonales o NEGs híbridos. No se admite en los NEGs de Internet, los NEGs sin servidor y los backends de Private Service Connect.
  • Las solicitudes al servicio de backend reflejado no generan ningún registro ni métrica para Cloud Logging y Cloud Monitoring.

Reescribir la URL solicitada

Reescribe 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 sustituir los marcadores de posición.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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

Volver a intentar una solicitud

Configura las condiciones en las que el balanceador de carga vuelve a intentar las solicitudes fallidas, el tiempo que espera el balanceador de carga antes de volver a intentarlo y el número máximo de reintentos permitidos.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Especificar el tiempo de espera de la ruta

Especifica el tiempo de espera de la ruta seleccionada. El tiempo de espera se calcula desde el momento en que la solicitud se procesa por completo hasta que la respuesta se procesa por completo. Tiempo de espera incluye todos los reintentos. Sustituye los marcadores de posición.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 500000000

Configurar la inyección de fallos

Introduce errores al atender solicitudes para simular fallos, como alta latencia, sobrecarga del servicio, fallos del servicio y partición de la red. Esta función es útil para probar la resiliencia de un servicio ante fallos simulados.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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 políticas de uso compartido de recursos entre dominios (CORS) para gestionar los ajustes de aplicación de solicitudes CORS.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: my-domain.com
               allowMethods: GET, POST
               allowHeaders: Authorization, Content-Type
               maxAge: 1200
               allowCredentials: True

Añadir y quitar encabezados de solicitud y respuesta

Añade y elimina encabezados de solicitud antes de enviar una solicitud al servicio de backend. También puedes añadir y quitar encabezados de respuesta después de recibir una respuesta del servicio backend.

Los balanceadores de carga de aplicación externos regionales y los balanceadores de carga de aplicación internos también admiten el uso de variables en encabezados personalizados. Puede especificar una o varias variables en los campos de valor de encabezado personalizado (headerValue), que se traducen a sus valores correspondientes por solicitud. Para ver una lista de los valores de encabezado admitidos, consulta Crear encabezados personalizados en mapas de URLs.

   defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/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

Configurar la detección de valores atípicos

Especifica los criterios para expulsar las VMs o los endpoints de backend que no estén en buen estado en los NEGs, así como los criterios que definen cuándo se considera que un backend o un endpoint está lo suficientemente en buen estado como para volver a recibir tráfico. No olvides sustituir los marcadores de posición.

    loadBalancingScheme: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/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

Configurar la interrupción de circuitos

La interrupción de circuitos te permite definir umbrales de errores para evitar que las solicitudes de los clientes sobrecarguen tus back-ends. Cuando las solicitudes alcanzan el límite que has definido, el balanceador de carga deja de permitir nuevas conexiones o de enviar solicitudes adicionales, lo que da tiempo a tus back-ends para recuperarse. Por lo tanto, los interruptores evitan los fallos en cascada devolviendo un error al cliente en lugar de sobrecargar un backend. De esta forma, se puede atender parte del tráfico y, al mismo tiempo, se dispone de tiempo para gestionar la situación de sobrecarga, como gestionar un pico de tráfico aumentando la capacidad mediante el escalado automático.

Define límites superiores en las solicitudes por conexión, así como en el volumen de conexiones a un servicio de backend. También limita el número de solicitudes pendientes y reintentos.

    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

Configurar la división del tráfico: pasos detallados

En este ejemplo se muestran los siguientes pasos:

  1. Crea plantillas distintas para diferentes servicios.

  2. Crea grupos de instancias para esas plantillas.

  3. Crea reglas de enrutamiento que configuren una división del tráfico del 95 % y el 5 %.

  4. Envía comandos curl que muestren que los porcentajes de división del tráfico coinciden aproximadamente con la configuración.

En estas instrucciones se presupone lo siguiente:

  • La región es us-west1.

  • Se han creado un proxy de destino y una regla de reenvío, así como un mapa de URLs llamado regional-lb-map.

  • El mapa de URLs envía todo el tráfico a un servicio de backend llamado red-service, que es el servicio de backend predeterminado.

  • Has configurado una ruta alternativa que envía el 5% del tráfico a blue-service y el 95% a green-service.

  • Se usa un buscador de rutas.

  • Estás usando Cloud Shell u otro entorno con bash instalado.

Definir los servicios

La siguiente función de bash crea un servicio de backend, incluida la plantilla de instancia y el grupo de instancias gestionado.

En estas instrucciones se da por hecho que se ha creado una comprobación del estado de HTTP (regional-lb-basic-check). Para obtener instrucciones, consulta Configurar un balanceador de carga de aplicación 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-12 \
    --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 servicio predeterminado para las solicitudes a /. Los servicios green y blue se han configurado en /PREFIX para gestionar 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

Crear el mapa de URLs

gcloud

  1. Exporta el mapa de URLs que ya tengas 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

  2. Actualiza el archivo de mapa de URLs regional-lb-map-config.yaml añadiendo lo siguiente al final del archivo:

    hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/green-service
          weight: 95
        - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/blue-service
          weight: 5

  3. Actualiza el mapa de URLs 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

Probar la configuración

Para probar la configuración, primero asegúrate de que las solicitudes a la dirección IP del balanceador de carga que has configurado anteriormente se gestionan con la redconfiguración predeterminada.

A continuación, comprueba que las solicitudes enviadas a FORWARDING_RULE_IP_ADDRESS/PREFIX se dividen como esperabas.

Crear una VM cliente

Para obtener instrucciones, consulta Crear una instancia de VM en la zona para probar la conectividad.

Enviar solicitudes a FORWARDING_RULE_IP_ADDRESS

  1. Usa ssh para conectarte al cliente.

    gcloud compute ssh global-lb-client-us-west1-a \
   --zone=us-west1-a

  2. 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
Comprobar los resultados
***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Enviar solicitudes a FORWARDING_RULE_IP_ADDRESS/PREFIX

Envía solicitudes a FORWARDING_RULE_IP_ADDRESS/PREFIX y observa 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
Comprobar 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 correctamente el 95% de las solicitudes de /PREFIX al servicio green y el 5% al servicio blue.

El control del tráfico te permite configurar la afinidad de sesión en función de una cookie proporcionada. Para configurar la afinidad de sesión basada en HTTP_COOKIE para un servicio de backend llamado red-service, sigue estas instrucciones.

  1. Usa el comando gcloud compute backend-services export para obtener la configuración del servicio de backend.

    gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --region=us-west1

  2. Modifica el archivo red-service-config.yaml del siguiente modo:

    sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
 httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 500000000
 minimumRingSize: 10000

  3. En el archivo red-service-config.yaml, elimina la siguiente línea:

    sessionAffinity: NONE

  4. Actualiza el archivo de configuración del servicio backend:

    gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --region=us-west1

Solución de problemas

Utilice esta información para solucionar problemas cuando el tráfico no se enrute de acuerdo con las reglas de ruta y las políticas de tráfico que haya configurado.

Para obtener información sobre el registro y la monitorización, consulta Registro y monitorización de HTTP(S) interno.

Síntomas:

  • Aumento del tráfico a los servicios de las reglas que están por encima de la regla en cuestión.
  • Un aumento inesperado de respuestas HTTP 4xx y 5xx en una regla de ruta determinada.

Solución: Comprueba el orden de las reglas de ruta. Las reglas de ruta se interpretan en el orden en el que se especifican.

Las reglas de ruta de un mapa de URLs se interpretan en el orden en el que se especifican. Esto es diferente de la forma en que las reglas de ruta se interpretan por la coincidencia de prefijo más largo. En el caso de las reglas de ruta, los balanceadores de carga de aplicaciones internos solo seleccionarán una regla de ruta. Sin embargo, cuando se usan reglas de ruta, se pueden aplicar varias.

Cuando defina reglas de ruta, compruebe que las reglas de la parte superior de la lista no enruten por error tráfico que, de lo contrario, se habría enrutado mediante una regla de ruta posterior. El servicio que recibe tráfico mal dirigido probablemente rechace las solicitudes, y el servicio de tus reglas de ruta recibirá menos tráfico o ninguno.

Siguientes pasos