Configura la administración avanzada de tráfico

En este documento, se proporciona información sobre cómo configurar la administración avanzada de tráfico para tu implementación de Traffic Director.

Antes de configurar la administración avanzada de tráfico

Sigue las instrucciones en Configura Traffic Director, incluidas las instrucciones para configurar Traffic Director y cualquier host de VM o clúster de GKE que necesites. Crea los recursos de Google Cloud necesarios.

Nota: Algunas de las funciones que se describen en este documento no se admiten para los servicios de gRPC sin proxy con Traffic Director. Si deseas obtener más información, consulta Características de Traffic Director y Administración avanzada del tráfico. La configuración de servicios de gRPC sin proxy basados en VM con administración avanzada de tráfico incluye una guía completa de configuración.

Configura la división de tráfico

En estas instrucciones, se supone que se cumplen estas condiciones:

• Tu implementación de Traffic Director tiene un mapa de URL llamado review-url-map.
• El mapa de URL envía todo el tráfico a un servicio de backend, llamado review1, que también funciona como el servicio de backend predeterminado.
• Tu plan es enrutar el 5% del tráfico a una nueva versión de un servicio. Ese servicio se ejecuta en un extremo o una VM de backend en un NEG asociado con el servicio de backend review2.
• No se usan reglas de host ni comparadores de rutas de acceso.

Para configurar la división de tráfico, sigue estos pasos:

Console

1. Ve a la página de Traffic Director en Cloud Console.

   Ir a la página de Traffic Director

2. Haz clic en Create Routing rule maps.

3. Ingresa el nombre del mapa de reglas de enrutamiento.

4. Selecciona HTTP en el menú Protocolo.

5. Selecciona una regla de reenvío existente.

6. En Reglas de enrutamiento, selecciona Regla de enrutamiento, ruta de acceso y host avanzado.

7. En Comparador de rutas de acceso, selecciona Split traffic between services.

8. Haz clic en el botón YAML View.

9. Agrega la siguiente configuración al cuadro Comparador de rutas de acceso:

       - defaultService: global/backendServices/review1
         name: matcher1
         routeRules:
         - priority: 2
           matchRules:
           - prefixMatch: ''
           routeAction:
            weightedBackendServices:
            - backendService: global/backendServices/review1
              weight: 95
            - backendService: global/backendServices/review2
              weight: 5
   

10. Haz clic en Listo.

11. Haz clic en Crear.

gcloud

1. Usa el comando gcloud export para obtener la configuración del mapa de URL:

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

2. Agrega la siguiente sección al archivo review-url-map-config.yaml:

       hostRules:
       - description: ''
        hosts:
         - '*'
       pathMatcher: matcher1
       pathMatchers:
       - defaultService: global/backendServices/review1
         name: matcher1
         routeRules:
         - priority: 2
           matchRules:
           - prefixMatch: ''
           routeAction:
            weightedBackendServices:
            - backendService: global/backendServices/review1
              weight: 95
            - backendService: global/backendServices/review2
              weight: 5
   

3. Actualiza el mapa de URL:

    gcloud compute url-maps import review-url-map \
        --source=review-url-map-config.yaml
   

Una vez que estés satisfecho con la versión nueva, puedes ajustar de forma gradual los pesos de los dos servicios y, luego, enviar todo el tráfico a review2.

Configura la interrupción de circuitos

La interrupción de circuitos te permite establecer umbrales de fallas para evitar que las solicitudes del cliente sobrecarguen tus backends. Después de que las solicitudes alcanzan el límite que estableciste, el cliente deja de permitir conexiones nuevas o enviar solicitudes adicionales, lo que le da tiempo a los backends para recuperarse.

De esta manera, 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.

En el siguiente ejemplo, debes establecer los disyuntores de esta manera:

• Máximo de solicitudes por conexión: 100
• Máximo de conexiones: 1,000
• Máximo de solicitudes pendientes: 200
• Máximo de solicitudes: 1,000
• Máximo de reintentos: 3

Para configurar la interrupción del circuito, sigue estos pasos:

Console

1. En Cloud Console, ve a la página de Traffic Director.
   

   Ir a la página de Traffic Director

2. Haz clic en el nombre del servicio de backend que deseas actualizar.
3. Haz clic en Editar.
4. Haz clic en Configuración avanzada.
5. En Circuit breakers, selecciona la casilla de verificación Habilitar.
6. Haz clic en Editar .
7. En Máximo de solicitudes por conexión, ingresa 100.
8. En Máximo de conexiones, ingresa 1000.
9. En Máximo de solicitudes pendientes, ingresa 200.
10. En Máximo de solicitudes, ingresa 1000.
11. En Máximo de reintentos, ingresa 3.
12. Haz clic en Guardar.
13. Haz clic en Guardar.

gcloud

1. Usa el comando gcloud export para obtener la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Actualiza el archivo BACKEND_SERVICE_NAME.yaml de la siguiente manera:

    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
       group:https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/zones/<var>ZONE</var>/instanceGroups/<var>INSTANCE_GROUP_NAME</var>
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 300
    healthChecks:
      - https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/global/healthChecks/<var>HEALTH_CHECK_NAME</var>
    loadBalancingScheme: INTERNAL_SELF_MANAGED
    localityLbPolicy: ROUND_ROBIN
    name: <var>BACKEND_SERVICE_NAME</var>
    port: 80
    portName: http
    protocol: HTTP
    sessionAffinity: NONE
    timeoutSec: 30
   ```
   

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

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
      --source=BACKEND_SERVICE_NAME-config.yaml --global
   

El siguiente ejemplo de disyuntor para un caso de uso en el que un servicio de carrito de compras tiene un grupo de instancias como backend. La configuración del disyuntor indica los límites de los siguientes valores:

• Cantidad máxima de solicitudes paralelas por conexión
• Cantidad máxima de conexiones paralelas
• Cantidad máxima de solicitudes pendientes
• Cantidad máxima de solicitudes paralelas
• Cantidad máxima de reintentos paralelos

Para configurar este ejemplo de interrupción de circuito, sigue estos pasos:

Console

1. En Cloud Console, ve a la página de Traffic Director.
   

   Ir a la página de Traffic Director

2. Haz clic en el nombre del servicio de backend que deseas actualizar.
3. Haz clic en Editar.
4. Haz clic en Configuración avanzada.
5. En Circuit breakers, selecciona la casilla de verificación Habilitar.
6. Haz clic en Editar .
7. En Máximo de solicitudes por conexión, ingresa 100.
8. En Máximo de conexiones, ingresa 1000.
9. En Máximo de solicitudes pendientes, ingresa 200.
10. En Máximo de solicitudes, ingresa 20000.
11. En Máximo de reintentos, ingresa 3.
12. Haz clic en Guardar.
13. Haz clic en Guardar.

gcloud

1. Usa el comando gcloud export para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

Configura la afinidad de sesión basada en HTTP_COOKIE

La administración avanzada 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, sigue estas instrucciones.

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

Console

1. En Cloud Console, ve a la página de Traffic Director.
   

   Ir a la página de Traffic Director

2. Haz clic en el nombre del servicio de backend que deseas actualizar.

3. Haz clic en Editar .

4. Haz clic en Configuración avanzada.

5. En Afinidad de sesión, selecciona Cookie HTTP.

6. En Política de balanceo de cargas de localidad, selecciona Anillo de hash.

7. En el campo Nombre de cookie HTTP, ingresa http_cookie.

8. En el campo Ruta de acceso de cookie HTTP, ingresa /cookie_path.

9. En el campo TTL de cookie HTTP, ingresa 100.

10. En el campo Tamaño mínimo del anillo, ingresa 10000.

11. Haz clic en GUARDAR.

gcloud

1. Usa el comando gcloud export para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
       --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Actualiza el archivo 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. Importa el archivo de configuración del servicio de backend:

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
      --source=BACKEND_SERVICE_NAME-config.yaml --global
   

Configura la detección de valores atípicos

La detección de valores atípicos controla la expulsión de hosts en mal estado del grupo de balanceo de cargas. Traffic Director hace esto mediante un conjunto de políticas que especifican los criterios para la expulsión de extremos o VM de backend en mal estado en los NEG, junto con criterios que definen cuándo se considera que un backend o extremo tienen el estado adecuado para recibir tráfico otra vez.

En el siguiente ejemplo, el servicio de backend tiene un grupo de instancias como su backend. La configuración de la detección de valores atípicos especifica que el análisis de detección de valores atípicos se ejecuta cada segundo. Si un extremo muestra cinco errores 5xx consecutivos, se expulsa de la consideración del balanceo de cargas durante 30 segundos por primera vez. El tiempo de expulsión real para el mismo extremo es de 30 segundos por cada vez que se expulsa.

La detección de valores atípicos se configura en el recurso de servicio de backend.

Console

1. En Cloud Console, ve a la página de Traffic Director.
   

   Ir a la página de Traffic Director

2. Haz clic en el nombre de un servicio.

3. Haz clic en Editar .

4. Haz clic en Configuración avanzada.

5. Selecciona la casilla de verificación Detección de valores atípicos.

6. Haz clic en Editar .

7. Establece Errores con errores en 5.

8. Establece Intervalo en 1000 milisegundos.

9. Establece el Tiempo de expulsión base en 30000 milisegundos.

10. Haz clic en Guardar.

11. Haz clic en Guardar.

gcloud

1. Usa el comando gcloud export para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Actualiza el archivo YAML de la siguiente manera y sustituye el nombre del servicio de backend por your_service_name:

   name: your_service_name
   loadBalancingScheme: INTERNAL_SELF_MANAGED
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: $[INSTANCE_GROUP_URL]
   healthChecks:
   - $[HEALTH_CHECK_URL]
   port: 80
   portName: http
   protocol: HTTP
   outlierDetection:
     consecutiveErrors: 5,
     interval:
         seconds: 1,
         nanos: 0
     baseEjectionTime:
         seconds: 30,
         nanos: 0
     ````
   

3. Importa el archivo de configuración del servicio de backend:

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
     --source=BACKEND_SERVICE_NAME-config.yaml --global
   

Configura la política de balanceo de cargas de localidad

Usa la política de balanceo de cargas de localidad para elegir un algoritmo de balanceo de cargas según el peso de la localidad y la prioridad que proporciona Traffic Director. Por ejemplo, puedes usar un round robin ponderado entre extremos en buen estado o realizar un hash coherente.

En el siguiente ejemplo, el servicio de backend tiene un grupo de instancias como su backend. La política de balanceo de cargas de localidad se establece en RING_HASH.

Console

1. En Cloud Console, ve a la página de Traffic Director.
   

   Ir a la página de Traffic Director

2. Haz clic en el nombre de un servicio.

3. Haz clic en Editar .

4. Haz clic en Configuración avanzada.

5. En Política de tráfico, en el menú Política de balanceo de cargas de localidad, selecciona Anillo de hash.

6. Haz clic en Guardar.

gcloud

1. Usa el comando gcloud export para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME-config.yaml --global
   

2. Actualiza el archivo BACKEND_SERVICE_NAME.yaml de la siguiente manera:

   name: shopping-cart-service
   loadBalancingScheme: INTERNAL_SELF_MANAGED
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: $[INSTANCE_GROUP_URL]
   healthChecks:
   - $[HEALTH_CHECK_URL]
   port: 80
   portName: http
   protocol: HTTP
   localityLbPolicy: RING_HASH
   ````
   

3. Importa el archivo de configuración del servicio de backend:

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
     --source=BACKEND_SERVICE_NAME-config.yaml --global
   

Para obtener más información sobre cómo funciona la política de balanceo de cargas de localidad, consulta la documentación sobre el recurso backendService.

Establece el filtrado de configuración según la coincidencia de MetadataFilter

Los MetadataFilters están habilitados con las reglas de reenvío y HttpRouteRuleMatch. Usa esta función para controlar una regla de reenvío o regla de enrutamiento en particular, de modo que el plano de control envíe la regla de reenvío o la regla de enrutamiento solo a los proxies cuyos metadatos de nodo coincidan con la configuración del filtro de metadatos. Si no especificas MetadataFilters, la regla se envía a todos los proxies de Envoy.

Esta función facilita la operación de una implementación publicada en etapa de pruebas de una configuración. Por ejemplo, crea una regla de reenvío llamada forwarding-rule1, que deseas que se envíe solo a Envoys cuyos metadatos de nodo contengan “app: review” y “version: canary”.

Sigue los pasos a continuación para agregar MetadataFilters a la regla de reenvío.

Nota: Existe una limitación en la importación de reglas de reenvío. Para obtener más información, consulta la sección Limitaciones de este documento.

Para agregar MetadataFilter a una regla de reenvío, sigue estos pasos:

gcloud

1. Usa el comando gcloud export para obtener el archivo de configuración de la regla de reenvío.

   gcloud compute forwarding-rules export forwarding-rule1 \
       --destination=forwarding-rule1-config.yaml --global
   

2. Actualiza el archivo forwarding-rule1-config.yaml:

   metadataFilters:
   - filterMatchCriteria: 'MATCH_ALL'
     filterLabels:
     - name: 'app'
       value: 'review'
     - name: 'version'
       value: 'canary'
   

3. Usa el comando gcloud import para actualizar el archivo forwarding-rule1-config.yaml.

   gcloud compute forwarding-rules import forwarding-rule1 \
       --source=forwarding-rule1-config.yaml --global
   

4. Usa estas instrucciones para agregar metadatos de nodo a Envoy antes de iniciar Envoy. Ten en cuenta que solo se admite el valor de string.

   a. Para una implementación basada en VM, en bootstrap_template.yaml, agrega lo siguiente en la sección de metadatos:

       app: 'review'
       version: 'canary'
   

   b. Para una implementación basada en Google Kubernetes Engine o en Kubernetes, en trafficdirector_istio_sidecar.yaml, agrega lo siguiente en la sección del entorno:

       - name: ISTIO_META_app
         value: 'review'
       - name: ISTIO_META_version
         value: 'canary'
   

Ejemplos con filtrado de metadatos

Usa las siguientes instrucciones para una situación en la que varios proyectos se encuentren en la misma red de VPC compartida y quieras que los recursos de Traffic Director de cada proyecto de servicio sean visibles para los proxies del mismo proyecto.

La configuración de la VPC compartida es la siguiente:

• Nombre del proyecto host: vpc-host-project
• Proyectos de servicio: project1 y project2
• Servicios de backend con extremos o instancias de backend que ejecutan un proxy que cumple con xDS en project1 y project2

Si deseas configurar Traffic Director para aislar project1, haz lo siguiente:

gcloud

1. Crea todas las reglas de reenvío en project1 con el siguiente filtro de metadatos:

       metadataFilters:
       - filterMatchCriteria: 'MATCH_ALL'
         filterLabels
         - name: 'project_name'
           value: `project1
         - name: 'version'
           value: 'production'
   

2. Cuando configures los proxies implementados en instancias o extremos en project1, incluye los siguientes metadatos en la sección de metadatos de nodo del archivo de arranque:

      project_name: 'project1'
      version: 'production'
   

3. Verifica que los proxies que ya estén implementados en project2 no hayan recibido la regla de reenvío creada en el primer paso. Para ello, intenta acceder a los servicios en project1 desde un sistema que ejecuta un proxy en project2. Para obtener información sobre cómo verificar que una configuración de Traffic Director funcione de forma correcta, consulta Verifica la configuración.

Para probar una configuración nueva en un subconjunto de proxies antes de ponerla a disposición de todos los proxies, haz lo siguiente:

gcloud

1. Inicia los proxies que usas para realizar pruebas con los siguientes metadatos de nodo. No incluyas estos metadatos de nodo para proxies que no usas con el fin de realizar pruebas.

    version: 'test'
   

2. En cada regla de reenvío nueva que quieras probar, incluye el siguiente filtro de metadatos:

    metadataFilters:
    - filterMatchCriteria: 'MATCH_ALL'
      filterLabels:
      - name: 'version'
        value: 'test'
   

3. Prueba la configuración nueva mediante el envío del tráfico a los proxies de prueba y realiza los cambios necesarios. Si la configuración nueva funciona de forma adecuada, solo los proxies que pruebes recibirán esta configuración. Los proxies restantes no reciben la configuración nueva y no pueden usarla.

4. Cuando confirmes que la configuración nueva funciona de forma adecuada, quita el filtro de metadatos asociado a ella. Esto permite que todos los proxies reciban la configuración nueva.

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.

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: Revisa la prioridad asignada a cada regla, ya que las reglas de enrutamiento se interpretan en orden de prioridad.

Cuando definas reglas de enrutamiento, asegúrate de que las reglas con mayor prioridad (es decir, con números de prioridad más bajos) no enruten de forma inadvertida el tráfico que, de lo contrario, habría sido enrutado por una regla de enrutamiento posterior. Considera el siguiente ejemplo:

• Primera regla de enrutamiento

  • La ruta de acceso coincide con pathPrefix = '/shopping/';
  • Acción de redireccionamiento: envía tráfico al servicio de backend service-1
  • Prioridad de la regla: 4

• Segunda regla de enrutamiento

  • La ruta de acceso coincide con regexMatch = '/shopping/cart/ordering/.*';
  • Acción de redireccionamiento: envía tráfico al servicio de backend service-2
  • Prioridad de la regla: 8

En este caso, una solicitud con la ruta “/shopping/cart/ordering/cart.html” se enruta a service-1. Aunque la segunda regla coincida, se ignora porque la primera regla tiene prioridad.

Limitaciones

• Si el valor de BackendService.sessionAffinity no es NONE, y BackendService.localityLbPolicy se establece en una política de balanceo de cargas distinta de MAGLEV o RING_HASH, la configuración de afinidad de sesión no se aplicará.
• Con el comando gcloud import, no se borran los campos de nivel superior del recurso, como el servicio de backend y el mapa de URL. Por ejemplo, si se crea un servicio de backend con configuración de circuitBreakers, esa configuración puede actualizarse mediante un comando gcloud import posterior. Sin embargo, esa configuración no se puede borrar del servicio de backend. El recurso se puede borrar y volver a crear sin la configuración de circuitBreakers.
• La importación de reglas de reenvío no funciona de forma adecuada. Un archivo YAML exportado no se puede volver a importar. La solución alternativa es exportar el archivo de configuración, realizar cambios, borrar la regla de reenvío y, luego, importar el archivo de configuración.