Administración de tráfico con reglas de enrutamiento y políticas de tráfico

El balanceo de cargas HTTP(S) interno funciona con la misma tecnología que Traffic Director con Envoy completamente administrado para que puedas usar las reglas de enrutamiento y las políticas de tráfico a fin de controlar el tráfico dentro de tu implementación. El balanceo de cargas HTTP(S) interno ofrece funciones avanzadas de control de tráfico de Envoy mediante componentes conocidos de balanceo de cargas de GCP: asignaciones de URL y servicios de backend.

Una regla de enrutamiento coincide con la información de una solicitud entrante y toma una decisión de enrutamiento en función de la coincidencia. GCP busca la primera regla de enrutamiento cuyas reglas coinciden con la solicitud, después de eso, GCP deja de buscar en cualquier otra regla. Luego, GCP aplica las acciones en la regla de enrutamiento. Una regla de enrutamiento es una alternativa a un comparador de rutas y una regla de rutas de acceso.

Después de enrutar el tráfico, las políticas de tráfico toman medidas adicionales para administrar tu tráfico:

  • La configuración del balanceador de cargas controla el algoritmo de balanceo de cargas.
  • La configuración del grupo de conexiones controla el volumen de conexiones a un servicio posterior.
  • La detección de valores atípicos controla la expulsión de hosts en mal estado del grupo de balanceo de cargas.

Ejemplos de casos prácticos

Las reglas de enrutamiento y las políticas de tráfico te permiten implementar división de tráfico, dirección de tráfico, inyección de fallas, interrupción de circuitos y duplicación.

La división del tráfico permite que una regla de enrutamiento tenga múltiples servicios de backend para que cada uno reciba un porcentaje específico de las solicitudes que coinciden con la regla de enrutamiento. Por ejemplo, puedes enviar el 95% del tráfico a una instancia de servicio y el 5% a otra. La división del tráfico suele usarse para implementar versiones nuevas, pruebas A/B, migración de servicios y procesos similares.

División de tráfico del balanceo de cargas de Google Cloud (haz clic para ampliarla)
División de tráfico del balanceo de cargas de Google Cloud (haz clic para ampliarla)

La dirección de tráfico dirige el tráfico a las instancias de servicio en función del contenido en los encabezados de las solicitudes HTTP. Por ejemplo, si un usuario usa un dispositivo Android con user-agent:Android en el encabezado de solicitud, la dirección de tráfico envía ese tráfico a instancias de servicio designadas para recibir tráfico de Android y envía el tráfico que no tiene user-agent:Android a instancias que manejan otros dispositivos.

Dirección de tráfico del balanceo de cargas de Google Cloud (haz clic para ampliarla)
Dirección de tráfico del balanceo de cargas de Google Cloud (haz clic para ampliarla)

La inyección de fallas te permite probar la resistencia de los servicios mediante la simulación de situaciones de falla del servicio, como demoras y solicitudes anuladas. La inyección de retraso configura el proxy para agregar retrasos en una fracción de las solicitudes antes de enviar la solicitud al servicio de backend seleccionado. La inyección de anulación configura el proxy para que responda de forma directa a una fracción de solicitudes con códigos de respuesta de falla, en lugar de reenviar esas solicitudes al servicio de backend.

La interrupción de circuitos aplica un límite a todas las solicitudes a un servicio específico si un servicio diferente no puede llegar a él luego de una cantidad configurable de intentos consecutivos.

La duplicación te permite enviar una copia de las solicitudes que coinciden con una regla de enrutamiento a un segundo servicio de backend. El proxy no espera una respuesta del segundo servicio de backend y descarta las respuestas que recibe de este. 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.

Acerca de las reglas de enrutamiento

Las reglas de enrutamiento proporcionan múltiples maneras de hacer coincidir las solicitudes HTTP y realizar diversas acciones, como dividir el tráfico entre varios servicios de backend, responder con redireccionamientos y alterar solicitudes o respuestas. Las reglas de enrutamiento se ejecutan en orden, lo que proporciona flexibilidad para vincular acciones con reglas de coincidencia en asignaciones de URL. Ten en cuenta que, cuando se realiza la primera coincidencia, el balanceo de cargas HTTP(S) interno deja de evaluar las reglas y se ignoran las restantes.

  • Las reglas de coincidencia permiten que el balanceo de cargas HTTP(S) interno coincida con uno o más atributos de una solicitud y realice las acciones especificadas en la regla de enrutamiento. Los siguientes atributos de una solicitud se pueden usar para especificar los criterios de coincidencia:

    • Host: un nombre de host es la parte del nombre de dominio de una URL; por ejemplo, la parte del nombre de host de la URL http://example.net/video/hd es example.net. En la solicitud, el nombre de host proviene del encabezado Host, como se muestra en este comando curl de ejemplo:
    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    

    en el que 10.1.2.9 es la dirección IP con balanceo de cargas.

    • Las rutas de acceso le siguen al nombre de host; por ejemplo /images. La regla puede especificar si se debe hacer coincidir la ruta de acceso completa o solo la parte inicial.

    • Otros parámetros de solicitud HTTP, como los encabezados HTTP, que permiten la coincidencia entre cookies, además de la coincidencia basada en parámetros de consulta (variables GET).

  • Las acciones de enrutamiento configuran el balanceo de cargas HTTP(S) interno con acciones específicas que se deben realizar cuando una regla de enrutamiento coincide con los atributos de una solicitud. Usa las siguientes acciones de enrutamiento avanzadas:

    • Redirecciones: el balanceo de cargas HTTP(S) interno muestra un código de respuesta 3xx configurable. También establece el encabezado de respuesta Location con el URI adecuado y reemplaza el host y la ruta de acceso como se especifica en la acción de redireccionamiento.

    • Reescrituras de URL: el balanceo de cargas HTTP(S) interno puede volver a escribir la parte del nombre de host de la URL, la parte de ruta de acceso (o ambas) antes de enviar una solicitud al servicio de backend seleccionado.

    • Transformaciones de encabezado: el balanceo de cargas HTTP(S) interno puede agregar o quitar encabezados de solicitud antes de enviar una solicitud al servicio de backend. También puede agregar o quitar encabezados de respuesta después de recibir una respuesta del servicio de backend.

    • Duplicación de tráfico: además de reenviar la solicitud al servicio de backend seleccionado, el balanceo de cargas HTTP(S) interno envía una solicitud idéntica al servicio de backend duplicado configurado según un principio de “enviar y olvidar”. 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.

    • La división del tráfico ponderada es una configuración que permite que el tráfico de una regla coincidente se distribuya a varios servicios de backend, en proporción a una ponderación definida por el usuario asignada al servicio de backend individual. Esta capacidad es útil para configurar implementaciones por etapas o pruebas A/B. Por ejemplo, la acción de enrutamiento puede configurarse de forma que el 99% del tráfico se envíe a un servicio que ejecuta una versión estable de una aplicación, mientras que el 1% se envía a otro servicio con una versión más reciente de esa aplicación.

  • Los reintentos configuran las condiciones en las que el balanceador de cargas reintentará las solicitudes con errores, la cantidad de tiempo que el balanceador de cargas esperará antes del reintento y el número máximo de reintentos permitidos.

  • Inyección de fallas: el balanceo de cargas HTTP(S) interno puede agregar errores de forma intencional cuando se atienden solicitudes para simular fallas, como latencia alta, sobrecarga de servicio, fallas de servicio y particiones de red. Esta característica es útil para probar la resistencia de un servicio a fallas simuladas.

  • La inyección de retraso configura el proxy para que agregue retrasos en una parte de las solicitudes definida por el usuario antes de enviar la solicitud al servicio de backend seleccionado.

  • La inyección de anulación configura el proxy para que responda de forma directa a una fracción de las solicitudes con códigos de estado HTTP definidos por el usuario en lugar de reenviar esas solicitudes al servicio de backend.

  • Políticas de seguridad: las políticas de uso compartido de recursos de origen múltiple (CORS) administran la configuración del balanceo de cargas HTTP(S) interno para aplicar las solicitudes CORS.

Acerca de las políticas de tráfico

Las políticas de tráfico son grupos de configuración que definen el comportamiento del balanceo de cargas, lo que incluye las respuestas a los servicios de backend con errores y la forma de evitar que las fallas localizadas afecten al resto de la malla de servicios. Las siguientes características de política de tráfico se configuran en el servicio de backend.

  • Política de balanceo de cargas: el balanceo de cargas HTTP(S) interno realiza balanceo de cargas en función de la capacidad disponible y, como se indica en la documentación de Envoy, establece las ponderaciones de balanceo de cargas de nivel de localidad (por zona de Google Cloud Platform) a fin de que el proxy elija una zona de GCP en particular para las VM o extremos de backend en los NEG. Las políticas de balanceo de cargas especificadas en el servicio de backend determinan aún más el algoritmo usado para las VM o extremos de backend en los NEG dentro de la localidad que se seleccionará luego de una elección de localidad ponderada. Los algoritmos de balanceo de cargas incluyen turnos rotativos, anillo de hash y VM o extremos de backend en los NEG con la solicitud menor. Ten en cuenta que en el balanceo de cargas HTTP(S) interno, el balanceo de cargas se realiza mediante asignaciones de URL y servicios de backend.

  • Afinidad de sesión: el balanceo de cargas HTTP(S) interno ofrece varias opciones de afinidad de sesión, lo que incluye afinidad basada en cookies HTTP, afinidad basada en encabezados HTTP, afinidad de direcciones IP de cliente y afinidad de cookie generada. Ten en cuenta que la configuración de afinidad no se respeta si se incluye más de un weightedBackendServices en routeAction. Para obtener más información sobre la afinidad de sesión, consulta la afinidad de sesión.

  • La detección de valores atípicos consiste en un conjunto de políticas que especifican los criterios para retirar VM o extremos de backend en mal estado de los NEG, junto con criterios que definen cuándo un backend o extremo se considera lo bastante saludable como para volver a recibir tráfico.

  • La interrupción de circuitos establece límites superiores en el volumen de conexiones y solicitudes por conexión a un servicio de backend.

Modelo de datos de control de tráfico

Los recursos existentes de GCP se usan para implementar capacidades como las políticas de tráfico y enrutamiento avanzado. En el siguiente diagrama, se muestra qué recursos se usan para implementar cada característica:

Dirección de tráfico del balanceo de cargas de Google Cloud (haz clic para ampliarla)
Modelo de datos de balanceo de cargas de Google Cloud (haz clic para ampliarlo)

Recurso de asignación de URL

El componente de asignación de URL se extiende para admitir características de enrutamiento avanzadas en el comparador de rutas. Puedes hacer coincidir las solicitudes según el prefijo de ruta de acceso, la ruta de acceso completa, el encabezado HTTP y el parámetro de consulta. El prefijo y la ruta de acceso completa se aplican a la porción de ruta de acceso de la coincidencia. Para obtener más información, consulta la documentación de RouteMatch de Envoy proxy.

  • Comparador de rutas: el balanceo de cargas HTTP(S) interno extiende el concepto de coincidencia de ruta de acceso de la asignación de URL. Puedes continuar con el uso de reglas de ruta de acceso simples, como lo harías para un balanceador de cargas HTTP(S) de GCP, o puedes usar reglas de enrutamiento en su lugar. Usa los dos tipos de reglas de forma exclusiva. Una asignación de URL individual puede contener solo un tipo o el otro. Las reglas de ruta de acceso se pueden especificar en cualquier orden y se evalúan según el principio de hacer coincidir primero la ruta de acceso más larga. Las reglas de enrutamiento se interpretan en orden. Esto permite una mayor flexibilidad en la definición de criterios de enrutamiento complejos.

    • Reglas de enrutamiento (HttpRouteRule): el balanceo de cargas HTTP(S) interno evalúa las reglas de enrutamiento en el orden en que se especifican. Esto te permite definir criterios de enrutamiento complejos. Una regla de enrutamiento tiene los siguientes componentes:

      • Coincidencia de regla de enrutamiento (HttpRouteRuleMatch): te permite determinar si la regla de enrutamiento se aplica a una solicitud mediante la coincidencia de todos los atributos de la solicitud o un subconjunto de ellos, como la ruta de acceso, los encabezados HTTP y los parámetros de consulta (GET).

        Dentro de una HttpRouteRuleMatch, todos los criterios de coincidencia se deben cumplir para que las acciones de la regla tengan efecto. Si una regla contiene múltiples HttpRouteRuleMatches, las acciones de la regla tienen efecto cuando una solicitud coincide con cualquiera de los HttpRouteRuleMatches de la regla.

      • Acción de enrutamiento (HttpRouteAction): te permite especificar qué acciones debe realizar el balanceo de cargas HTTP(S) interno cuando se cumplen los criterios dentro de la HttpRouteRuleMatch. Estas acciones incluyen división de tráfico, reescrituras de URL, reintentos y duplicación, inyección de fallas y políticas de CORS.

      • Acción de redireccionamiento (HttpRedirectAction): puedes configurar el balanceo de cargas HTTP(S) interno para que responda con un redireccionamiento HTTP cuando se cumplen los criterios dentro de HttpRouteRuleMatch.

      • Acción de encabezado (HttpHeaderAction): puedes configurar reglas de transformación de encabezado de solicitud y respuesta cuando se cumplen los criterios dentro de HttpRouteRuleMatch.

    • Reglas de ruta de acceso (PathRule): el balanceo de cargas HTTP(S) interno admite objetos de regla de ruta de acceso en los comparadores de rutas para mantener la compatibilidad con las asignaciones de URL existentes. Puedes ingresar reglas de ruta de acceso en cualquier orden. El balanceo de cargas HTTP(S) interno intenta hacer coincidir la ruta de acceso de la solicitud con cada una de las que se encuentran en las reglas de ruta de acceso dentro de ese comparador de rutas, según el principio de hacer coincidir primero la ruta de acceso más larga. Si se produce una coincidencia de ruta de acceso, el tráfico se enruta al servicio de backend de la regla de ruta de acceso correspondiente.

Esta es la jerarquía de la asignación de URL para las características de enrutamiento avanzadas:

  • Servicio de backend predeterminado
  • Solo balanceo de cargas HTTP(S) interno: acción de enrutamiento predeterminada
  • Solo balanceo de cargas HTTP(S) interno: redireccionamiento predeterminado
  • Solo balanceo de cargas HTTP(S) interno: acción de encabezado
  • Lista de reglas de host
  • Lista de comparadores de rutas, cada uno contiene lo siguiente:
    • Solo balanceo de cargas HTTP(S) interno: acción de enrutamiento predeterminada
    • Solo balanceo de cargas HTTP(S) interno: redireccionamiento predeterminado
    • Solo balanceo de cargas HTTP(S) interno: acción de encabezado
    • Servicio de backend predeterminado para el comparador de rutas
    • Lista de reglas de ruta de acceso
    • Solo balanceo de cargas HTTP(S) interno: lista de reglas de enrutamiento
      • Solo balanceo de cargas HTTP(S) interno: lista de reglas de coincidencia
      • Solo balanceo de cargas HTTP(S) interno: servicio de backend
      • Solo balanceo de cargas HTTP(S) interno: acción de enrutamiento
      • Solo balanceo de cargas HTTP(S) interno: redireccionamiento
      • Solo balanceo de cargas HTTP(S) interno: acción de encabezado

Recurso de servicio de backend

El balanceo de cargas HTTP(S) interno usa un servicio de backend con un esquema de balanceo de cargas de INTERNAL_MANAGED. Un servicio de backend con este esquema admite la configuración que implementa la mayor parte de las políticas de tráfico. Se pueden especificar los siguientes atributos para un servicio de backend con administración interna:

  • Política de balanceo de cargas (LocalityLoadBalancingPolicy): para un servicio de backend con administración interna, la distribución de tráfico usa un modo de balanceo de cargas y una política de balanceo de cargas. El servicio de backend primero dirige el tráfico a un grupo de backend (grupo de instancias, grupo de instancias administrado o grupo de extremos de red) según el modo de balanceo. Después de que se selecciona un grupo de backend, el balanceador de cargas distribuye el tráfico según la política de balanceo de cargas. El modo de balanceo permite que el balanceo de cargas HTTP(S) interno seleccione primero una localidad, como una zona de GCP; luego, la política de balanceo de cargas se usa para seleccionar una VM o un extremo de backend específicos en un NEG.

  • Afinidad de sesión (SessionAffinity): los servicios de backend con administración interna admiten cuatro afinidades de sesión: dirección IP de cliente, basada en cookies HTTP, basada en encabezado HTTP y afinidad de cookie generada.

  • El hash coherente (ConsistentHashLoadBalancerSettings) define criterios para compilar hashes coherentes a partir de cookies y encabezados a fin de que el balanceo de cargas HTTP(S) interno enrute solicitudes nuevas a las mismas VM o extremos de backend en los NEG de forma coherente.

  • Los interruptores de circuitos (CircuitBreakers) definen parámetros para limitar el volumen de tráfico a cualquier VM o extremo de backend particular del servicio de backend. Esto evita la sobrecarga de servicios con solicitudes que no pueden manejar de manera significativa.

  • La detección de valores atípicos (OutlierDetection) define los criterios para determinar cuándo una VM o extremo de backend en un NEG se considera en mal estado y se excluye de las consideraciones de balanceo de cargas, además de las condiciones que deben cumplirse con el fin de reconsiderar la VM o extremos de backend para el balanceo de cargas. Una VM o extremo de backend en un NEG se consideran en mal estado cuando la verificación de estado vinculada al servicio de backend lo indica.

Configura el control de tráfico

En las siguientes secciones, se proporciona información sobre la configuración del control de tráfico.

Antes de configurar el control de tráfico

Sigue las instrucciones en la preparación para la configuración del balanceo de cargas HTTP(S) interno y configura los hosts de VM o clústeres de GKE que necesites. Crea los recursos de GCP necesarios.

Configura la división de tráfico

En este ejemplo, se muestran los siguientes pasos:

  1. Crear plantillas distintas para servicios diferentes

  2. Crear grupos de instancias para esas plantillas

  3. Crear reglas de enrutamiento que establezcan una detección de fallos del 95% y 5%

  4. Enviar comandos curl que muestren que los porcentajes de división de tráfico coinciden de forma aproximada con la configuración

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 HTTP (l7-ilb-basic-check). Consulta las instrucciones en la sección sobre cómo configurar el balanceo de cargas HTTP(S) interno para las VM de Compute Engine.

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=l7-ilb-tag,http-server \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  sudo apt-get update
  sudo apt-get install apache2 -y
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee $www_dir/index.html
  sudo service apache2 restart
  "; \
  gcloud beta compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud beta compute backend-services create "${name}-service" \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud beta compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

Crea los servicios

Ahora llama a la función para crear tres servicios: red, green y blue. El servicio red actúa como el servicio predeterminado para solicitudes a /. Los servicios green y blue están configurados en /prefix para manejar el 95% y el 5% del tráfico, de forma respectiva.

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 archivo de asignación de URL

Escribe un archivo de asignación de URL canary.yaml con la configuración de detección de fallos deseada.

En estas instrucciones, se supone lo siguiente:

  • La región es us-west1.
  • Tu implementación de balanceo de cargas HTTP(S) interno tiene una asignación de URL llamada l7-ilb-map.
  • Se crearon un proxy de destino y una regla de reenvío.
  • La regla de reenvío tiene la dirección 10.1.2.9.

    Consulta las instrucciones en la sección sobre cómo configurar el balanceo de cargas HTTP(S) interno para las VM de Compute Engine.

  • La asignación de URL envía todo el tráfico a un servicio de backend llamado red-service, que es el predeterminado.

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

  • Se usa un comparador de rutas.

  • Usas Cloud Shell o algún otro entorno con bash instalada.

Debes reemplazar project-id por el ID de tu proyecto de GCP.

defaultService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/red-service
hostRules:
- description: ''
  hosts:
  - '*'
  pathMatcher: matcher1
kind: compute#urlMap
name: l7-ilb-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /prefix
    routeAction:
      weightedBackendServices:
      - backendService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/green-service
        weight: 95
      - backendService: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/backendServices/blue-service
        weight: 5
region: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1
selfLink: https://www.googleapis.com/compute/beta/projects/project-id/regions/us-west1/urlMaps/l7-ilb-map

Importa la asignación de URL

gcloud beta compute url-maps import l7-ilb-map \
    --region=us-west1 \
    --source=canary.yaml

Prueba la configuración

Para probar la configuración de detección de fallos, primero asegúrate de que las solicitudes a 10.1.2.9/ (la dirección IP del balanceador de cargas configurada antes) se manejen con la configuración de red predeterminada.

Luego, asegúrate de que las solicitudes enviadas a 10.1.2.9/prefix estén divididas como se esperaba.

Crea una VM de cliente

Consulta la sección sobre cómo crear una instancia de VM en la zona para probar la conectividad.

Envía solicitudes a 10.1.2.9

Establece una conexión SSH con el cliente y ejecuta el siguiente comando:

for LB_IP in 10.1.2.9; 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 10.1.2.9:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Envía solicitudes a 10.1.2.9/prefix

Envía solicitudes a 10.1.2.9/prefix y observa la división del tráfico.

for LB_IP in 10.1.2.9; 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 10.1.2.9/prefix:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

La configuración de detección de fallos envía con éxito el 95% de las solicitudes /prefix al servicio green y el 5% al servicio blue.

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

Para configurar la afinidad de sesión con HTTP_COOKIE, sigue estos pasos:

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

    gcloud beta compute backend-services export red-service \
        --destination=red-service-config.yaml \
        --region=us-west1
    
  2. Actualiza el archivo red-service-config.yaml de la siguiente manera:

    sessionAffinity: 'HTTP_COOKIE'
    localityLbPolicy: 'RING_HASH'
    consistentHash:
     httpCookie:
      name: 'http_cookie'
      path: '/cookie_path'
      ttl:
        seconds: 100
        nanos: 30
     minimumRingSize: 10000
    
  3. En el archivo red-service-config.yaml, borra la línea que contiene esto:

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

    gcloud beta 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, el balanceo de cargas HTTP(S) interno solo seleccionará 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.

Limitaciones

  • UrlMap.defaultRouteAction y UrlMap.defaultUrlRedirect no funcionan como deberían. Debes especificar UrlMap.defaultService para manejar el tráfico que no coincide con ninguno de los hosts en UrlMap.hostRules[] en esa UrlMap. Del mismo modo, UrlMap.pathMatchers[].defaultRouteAction y UrlMap.pathMatchers[].defaultUrlRedirect no funcionan en este momento. Debes especificar UrlMap.pathMatchers[].defaultService para manejar el tráfico que no coincide con ninguna de las routeRules de ese pathMatcher.
  • RouteRule.service no funciona como debería por el momento. La solución alternativa es usar RouteRule.weightedBackendServices con un solo WeightedBackendService.
  • El comando gcloud import no borra los campos de nivel superior del recurso, como el servicio de backend y la asignación de URL. Por ejemplo, si se crea un servicio de backend con configuración para circuitBreakers, esa configuración puede actualizarse mediante un comando gcloud import posterior. Sin embargo, no se puede borrar del servicio de backend. El recurso se puede borrar y volver a crear sin la configuración de circuitBreakers.
  • El comando gcloud export exporta campos int64 como strings en el archivo exportado, no como números enteros. Debes quitar de forma manual las comillas del campo para importar el archivo exportado.