Configurar la gestión del tráfico para balanceadores de carga de aplicación externos globales

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 balanceadores de carga de aplicación externos globales. Los balanceadores de carga de aplicaciones externos globales usan el EXTERNAL_MANAGED esquema de balanceo de carga y componentes de balanceo de carga globales, como la regla de reenvío, el mapa de URLs y el servicio de backend.

Para obtener información sobre la gestión del tráfico con un balanceador de carga de aplicación clásico, consulta el artículo Introducción a la gestión del tráfico de un balanceador de carga de aplicación clásico.

Para obtener información sobre la gestión del tráfico con balanceadores de carga de aplicación externos regionales, consulta el resumen de la gestión del tráfico de los balanceadores de carga de aplicación externos regionales.

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

Asegúrate de que entiendes cómo funciona la gestión del tráfico. Para obtener más información, consulta la descripción general de la gestión del tráfico de los balanceadores de carga de aplicación externos globales.

Configurar y probar 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 elegida, debe escribir un archivo YAML de mapa de URLs, un archivo YAML de servicio 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.

No se admite la consola Google Cloud .

La documentación de la API de mapa de URLs global y de la API de servicio backend global proporciona una lista completa de campos, incluida la semántica relativa a las relaciones, las restricciones y la cardinalidad.

Puedes añadir pruebas de configuración a un mapa de URLs para asegurarte de que este enruta las solicitudes correctamente. Puede experimentar con diferentes reglas de asignación de URLs y realizar tantas pruebas como necesite para asegurarse de que la asignación dirige el tráfico al servicio backend o al backend de almacenamiento adecuados. Para obtener más información, consulta Añadir pruebas a un mapa de URLs. Si quieres probar los cambios de un mapa de URLs sin desplegarlo, consulta Validar la configuración del mapa de URLs.

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/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

Configurar una redirección de URL

En el siguiente ejemplo se devuelve un código de respuesta 301 MOVED_PERMANENTLY_DEFAULT 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.

Para crear una redirección para un backend, usa projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET en el campo defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

Si tienes varios servicios de backend ponderados y quieres registrar qué servicio de backend se ha usado para atender la solicitud original, puedes añadir un encabezado personalizado que incluya esta información a todas las solicitudes. En el siguiente ejemplo se añade un encabezado personalizado llamado x-weighted-picked-backend a todas las solicitudes del cliente. En el valor del encabezado, usa el nombre del servicio de backend que ha servido la solicitud original.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

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/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Configurar CORS

Configura políticas de uso compartido de recursos entre dominios (CORS) para controlar cómo gestiona tu balanceador de carga las solicitudes entre dominios.

Política de CORS aplicada a nivel de comparador de rutas

En esta configuración, la política CORS se define en el defaultRouteAction del matcher de rutas (pathMatchers[].defaultRouteAction.corsPolicy). Esto significa que la política se aplica a todas las solicitudes que se enrutan a través del matcher de rutas predeterminado, independientemente de la ruta específica.

Este enfoque es adecuado cuando quieres una política de CORS única y coherente para todas las rutas gestionadas por un buscador de rutas.

defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
  - '*'
  pathMatcher: path-matcher-1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
  name: path-matcher-1
- defaultRouteAction:
    corsPolicy:
      allowCredentials: true
      allowOrigins: [ "http://example.com" ]
      allowMethods: [ "GET", "POST" ]
      allowHeaders: [ "Authorization", "Content-Type" ]

Cómo funciona

  • El balanceador de carga aplica la política CORS a todas las solicitudes gestionadas por el path matcher.
  • Solo se permiten las solicitudes del host example.com que utilicen los métodos GET o POST y que incluyan los encabezados permitidos (Authorization y Content-Type).
  • Se permiten las credenciales (como las cookies o los encabezados de autorización) en las solicitudes entre orígenes.
  • El servicio de backend solo recibe solicitudes que cumplen esta política CORS.

Política de CORS aplicada a nivel de regla de ruta

En esta configuración, la política de CORS se define en un routeAction para una regla de ruta específica (pathMatchers[].routeRules[].routeAction.corsPolicy). De esta forma, puedes aplicar diferentes políticas de CORS a diferentes rutas o prefijos de ruta.

Este método es adecuado cuando necesitas un control preciso, como aplicar diferentes políticas de CORS a diferentes endpoints o rutas de API.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://example.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

Cómo funciona

  • La política de CORS solo se aplica a las solicitudes que coinciden con el prefijo de ruta especificado (por ejemplo, /PREFIX).
  • Solo se permiten las solicitudes de example.com con los métodos GET o POST y con los encabezados permitidos para esta ruta.
  • El campo maxAge especifica durante cuánto tiempo puede almacenar en caché el navegador los resultados de una solicitud de comprobación previa (en segundos).
  • Las credenciales se permiten en las solicitudes entre orígenes.
  • Otras rutas pueden tener políticas de CORS diferentes o no tener ninguna.

También puede definir una política de CORS en los siguientes niveles de un mapa de URLs:

  • defaultRouteAction.corsPolicy
  • pathMatchers[].pathRules[].routeAction.corsPolicy

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.

Hay restricciones en los valores válidos de headerName y headerValue. Para obtener más información, consulta Cómo funcionan los encabezados personalizados.

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

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:

  • Se han creado un proxy de destino y una regla de reenvío, así como un mapa de URLs llamado global-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 (global-lb-basic-check). Para obtener instrucciones, consulta una de las siguientes páginas:

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=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

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

Consola

  1. Ve a la página Balanceo de carga de la Google Cloud consola.
    Ve a Balanceo de carga.
  2. Haz clic en el enlace global-lb-map.
  3. Haz clic en Editar .

Configurar las nuevas reglas de enrutamiento

  1. En Reglas de direccionamiento, selecciona Regla de host, ruta y direccionamiento avanzadas.
  2. En Nuevos hosts y comparador de rutas, crea la acción predeterminada definiendo el Servicio como red-service.
  3. Haz clic en Listo.
  4. Haz clic en Añadir hosts y coincidencia de ruta.
  5. En el campo Hosts (Hosts), introduce la dirección IP de la regla de reenvío de tu balanceador de carga.

  6. Pega el siguiente contenido YAML en el cuadro Comparador de rutas:

    defaultService: projects/PROJECT_ID/global/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /PREFIX
  routeAction:
    weightedBackendServices:
      - backendService: projects/PROJECT_ID/global/backendServices/green-service
        weight: 95
      - backendService: projects/PROJECT_ID/global/backendServices/blue-service
        weight: 5

  7. Haz clic en Listo.

  8. Haz clic en Actualizar.

gcloud

  1. Exporta el mapa de URLs que ya tengas con el comando gcloud compute url-maps export:

    gcloud compute url-maps export global-lb-map \
  --destination=global-lb-map-config.yaml \
  --global

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

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

  3. Actualiza el mapa de URLs con el comando gcloud compute url-maps import:

    gcloud compute url-maps import global-lb-map \
   --global \
   --source=global-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.

El control de 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 \
    --global

  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: 0
 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 \
    --global

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

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, el balanceador de carga de aplicaciones externo global solo selecciona una regla de ruta, pero, si usas reglas de enrutamiento, se pueden aplicar varias.

Cuando definas reglas de ruta, asegúrate de 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