Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Configura la administración avanzada del tráfico con Envoy

La configuración es compatible con los clientes de la versión preliminar, pero no la recomendamos para los usuarios nuevos de Cloud Service Mesh. Para obtener más información, consulta la Descripción general del enrutamiento de servicios de Cloud Service Mesh.

En este documento, se proporciona información sobre cómo configurar la administración avanzada de tráfico para implementaciones de Cloud Service Mesh que usan Envoy.

Antes de comenzar

Antes de configurar la administración avanzada del tráfico, sigue las instrucciones de Prepárate para configurar Cloud Service Mesh con Envoy, incluida la configuración de Cloud Service Mesh y cualquier host de máquina virtual (VM) o clústeres de Google Kubernetes Engine (GKE) que necesites. Crea los recursos de Google Cloud necesarios.

La disponibilidad de la función Administración avanzada del tráfico difiere de acuerdo con el protocolo de solicitud que elijas. Este protocolo se configura cuando configuras el enrutamiento mediante el proxy HTTP o HTTPS de destino, el proxy de gRPC de destino o el recurso de proxy TCP de destino:

Con el proxy HTTP de destino y el proxy HTTPS de destino, todas las funciones que se describen en este documento están disponibles.
Existen algunas funciones disponibles con el proxy gRPC de destino.
Con el proxy TCP de destino, no hay funciones de administración de tráfico avanzadas disponibles.

Para obtener más información, consulta Funciones de Cloud Service Mesh y Administración avanzada del tráfico. Para obtener una guía de configuración de extremo a extremo, consulta Configura la administración avanzada del tráfico con servicios de gRPC sin proxy.

Configura la división del tráfico

En estas instrucciones, se supone lo siguiente:

Tu implementación de Cloud Service Mesh 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 grupo de extremos de red (NEG) asociado al servicio de backend review2.
No se usan reglas de host ni comparadores de rutas de acceso.

Si divides el tráfico a un servicio nuevo al que no se ha hecho referencia en el mapa de URL antes, primero agrega el servicio nuevo a weightedBackendServices y asígnale un peso de 0. Luego, aumenta de forma gradual el peso asignado a ese servicio.

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

Console

En la consola de Google Cloud, ve a la página Cloud Service Mesh.

Ir a Cloud Service Mesh
Haz clic en Mapas de reglas de enrutamiento.
Haz clic en Crear mapa de reglas de enrutamiento.
En la página Crear un mapa de reglas de enrutamiento, ingresa un Nombre.
En el menú Protocolo, selecciona HTTP.
Selecciona una regla de reenvío existente.
En Reglas de enrutamiento, selecciona Regla de enrutamiento, ruta de acceso y host avanzado.
En Hosts y comparadores de rutas de acceso, haz clic en Agrega hosts y comparadores de rutas de acceso. Esto agrega un comparador de rutas de acceso nuevo que puedes configurar para dividir el tráfico.

Agrega la siguiente configuración al campo 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

Haga clic en Listo.
Haz clic en Guardar.

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.

gcloud

Ejecuta 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

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

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 una actualización parcial

Usa un proceso de implementación parcial, a veces llamado canary, para lanzar una nueva versión de software a una pequeña fracción de servidores antes de lanzar la nueva versión al balanceo de tus servidores de producción.

Una versión parcial usa weightedBackendServices. Para habilitar un lanzamiento parcial, designa un servicio de backend como prueba, o versión canary, y asígnale un peso bajo, por ejemplo, 2 o 5. Implementa tu versión de software nueva solo en esos servidores. Cuando estés seguro de que la versión nueva no tiene problemas, impleméntala en el resto de los servicios.

Para habilitar una versión parcial, usa la siguiente muestra de código YAML:

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_PARTIAL_URL
            weight: 2
          - backendService: BACKEND_SERVICE_URL
            weight: 98

DEFAULT_SERVICE_URL es la URL predeterminada de tu servicio.
BACKEND_SERVICE_PARTIAL_URL es la URL para el servicio de backend que recibe el 2% del tráfico.
BACKEND_SERVICE_URL es la URL para el servicio de backend que recibe el 98% del tráfico.

Configura implementaciones azul-verde

Las implementaciones azul-verde son modelos de actualización que reducen el tiempo necesario para cambiar el tráfico de producción a una versión nueva de un servicio o a una reversión de una versión anterior del servicio. Estas implementaciones mantienen ambas versiones del servicio disponibles en producción y cambian el tráfico de una a otra.

Las implementaciones azul-verde usan weightedBackendServices. En el ejemplo de YAML que aparece a continuación, los backends en SERVICE_BLUE_URL se implementan por completo con la versión de producción actual y los backends en SERVICE_GREEN_URL se implementan por completo con la versión nueva. En la configuración del ejemplo, la implementación de GREEN recibe el 100% del tráfico de producción. Si encuentras problemas, puedes revertir los pesos para las dos implementaciones, lo que revierte de manera efectiva la versión GREEN defectuosa y restablece la versión BLUE buena conocida. En cualquier caso, el tráfico puede cambiarse rápidamente porque ambas versiones están disponibles para recibir tráfico.

Para habilitar una implementación azul-verde, usa la siguiente muestra de código YAML:

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_BLUE_URL
            weight: 0
          - backendService: BACKEND_SERVICE_GREEN_URL
            weight: 100

DEFAULT_SERVICE_URL es la URL predeterminada de tu servicio.
BACKEND_SERVICE_BLUE_URL es la URL del servicio de backend que no recibe nada de tráfico.
BACKEND_SERVICE_GREEN_URL es la URL del servicio de backend que recibe el 100% de tu tráfico.

Configura la duplicación de tráfico

Usa la duplicación de tráfico cuando desees que el tráfico se dirija a dos servicios de backend diferentes para depurar o probar servicios nuevos.

En el siguiente ejemplo, todas las solicitudes se envían a SERVICE_URL y a MIRROR_SERVICE_URL. Solo las respuestas de SERVICE_URL se envían al cliente. MIRROR_SERVICE_URL no tiene impacto en el cliente.

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

Console

En la consola de Google Cloud, ve a la página Cloud Service Mesh.

Ir a Cloud Service Mesh
Haz clic en Mapas de reglas de enrutamiento.
Haz clic en Crear mapa de reglas de enrutamiento.
En la página Crear un mapa de reglas de enrutamiento, ingresa un Nombre.
En la lista Protocolo, selecciona HTTP.
Selecciona una regla de reenvío existente.
En Reglas de enrutamiento, selecciona Regla de enrutamiento, ruta de acceso y host avanzado.
En Hosts y comparadores de rutas de acceso, haz clic en Agrega hosts y comparadores de rutas de acceso. Esto agrega un comparador de rutas de acceso nuevo que puedes configurar para duplicar el tráfico.

Agrega la siguiente configuración al campo Comparador de rutas de acceso:

    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL es la URL predeterminada de tu servicio.
BACKEND_SERVICE_URL es la URL del backend que se duplica.
BACKEND_SERVICE_MIRROR_URL es la URL del servicio de backend que duplicas.

Haga clic en Listo.
Haz clic en Guardar.

gcloud

Ejecuta 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

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

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL es la URL predeterminada de tu servicio.
BACKEND_SERVICE_URL es la URL del backend que se duplica.
BACKEND_SERVICE_MIRROR_URL es la URL del servicio de backend que duplicas.

Actualiza el mapa de URL:

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

Configura la interrupción del circuito

La interrupción de circuitos te permite establecer umbrales de fallas para evitar que las solicitudes del cliente sobrecarguen tus backends. 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.

Como resultado, 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

En la consola de Google Cloud, ve a la página Cloud Service Mesh.

Ir a Cloud Service Mesh
Haz clic en el nombre del servicio de backend que deseas actualizar.
Haz clic en Editar.
Haz clic en Configuración avanzada.
En Circuit breakers, selecciona la casilla de verificación Habilitar.
Haz clic en Editar.
1. En Máximo de solicitudes por conexión, ingresa 100.
2. En Máximo de conexiones, ingresa 1000.
3. En Máximo de solicitudes pendientes, ingresa 200.
4. En Máximo de solicitudes, ingresa 1000.
5. En Máximo de reintentos, ingresa 3.
Haz clic en Guardar y, luego, vuelve a hacer clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.
```
 gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

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/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
   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/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
 loadBalancingScheme: INTERNAL_SELF_MANAGED
 localityLbPolicy: ROUND_ROBIN
 name: BACKEND_SERVICE_NAME
 port: 80
 portName: http
 protocol: HTTP
 sessionAffinity: NONE
 timeoutSec: 30

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

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 con HTTP_COOKIE, sigue estos pasos:

Console

En la consola de Google Cloud, ve a la página Cloud Service Mesh.

Ir a Cloud Service Mesh
Haz clic en el nombre del servicio de backend que deseas actualizar.
Haz clic en Editar.
Haz clic en Configuración avanzada.
En Afinidad de sesión, selecciona Cookie HTTP.
En Política de balanceo de cargas de localidad, selecciona Anillo de hash.
1. En el campo Nombre de cookie HTTP, ingresa http_cookie.
2. En el campo Ruta de acceso de cookie HTTP, ingresa /cookie_path.
3. En el campo TTL de cookie HTTP, ingresa 100.
4. En el campo Tamaño mínimo del anillo, ingresa 10000.
Haz clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

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

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. Cloud Service Mesh 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.

Para configurar la detección de valores atípicos en el recurso de servicio de backend, sigue estos pasos:

Console

En la consola de Google Cloud, ve a la página Cloud Service Mesh.

Ir a Cloud Service Mesh
Haz clic en el nombre de un servicio.
Haz clic en Editar.
Haz clic en Configuración avanzada.
Selecciona la casilla de verificación Detección de valores atípicos.
Haz clic en Editar.
1. Establece Errores con errores en 5.
2. Establece Intervalo en 1000 milisegundos.
3. Establece el Tiempo de expulsión base en 30000 milisegundos.
Haz clic en Guardar y, luego, vuelve a hacer clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

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

name: BACKEND_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

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

Establece 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 Cloud Service Mesh. 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.

Para establecer la política de balanceo de cargas de localidad, sigue estos pasos:

Console

En la consola de Google Cloud, ve a la página Service Mesh de Cloud.

Ir a Cloud Service Mesh
Haz clic en el nombre de un servicio.
Haz clic en Editar.
Haz clic en Configuración avanzada.
En Política de tráfico, en el menú Política de balanceo de cargas de localidad, selecciona Anillo de hash.
Haz clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Reemplaza BACKEND_SERVICE_NAME por el nombre del servicio de backend.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

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

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 del recurso backendService.

Configura el redireccionamiento de la URL

En estas instrucciones, se supone lo siguiente:

Tu implementación de Cloud Service Mesh 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.
Deseas redireccionar el tráfico de un host a otro.

Para configurar el redireccionamiento de la URL, sigue estos pasos:

Console

En la consola de Google Cloud, ve a la página Cloud Service Mesh.

Ir a Cloud Service Mesh
Haz clic en Mapas de reglas de enrutamiento.
Haz clic en Crear mapa de reglas de enrutamiento.
En la página Crear un mapa de reglas de enrutamiento, ingresa un Nombre.
En el menú Protocolo, selecciona HTTP.
Selecciona una regla de reenvío existente.
En Reglas de enrutamiento, selecciona Regla de enrutamiento, ruta de acceso y host avanzado.
En Hosts y comparadores de rutas de acceso, haz clic en Agrega hosts y comparadores de rutas de acceso. Esto agrega un nuevo comparador de rutas de acceso que redirecciona el tráfico.

Agrega la siguiente configuración al campo Comparador de rutas de acceso:

    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

Haga clic en Listo.
Haz clic en Guardar.

gcloud

Ejecuta 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

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:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

Actualiza el mapa de URL:

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

Configura el direccionamiento del tráfico con reescritura de URL

El direccionamiento del tráfico te permite dirigir el tráfico a diferentes servicios de backend según los atributos de la solicitud, como los valores del encabezado. Además, puedes configurar acciones como reescribir la URL en la solicitud antes de que esta se dirija al servicio de backend.

En el siguiente ejemplo, la solicitud se dirige a SERVICE_ANDROID_URL si la ruta de la solicitud con el prefijo /mobile/ y el User-Agent de la solicitud contienen Android. Antes de enviar la solicitud al servicio de backend, el prefijo de URL se puede cambiar al REWRITE_PATH_ANDROID, por ejemplo, /android/. Sin embargo, si la ruta tiene el prefijo /mobile/ y tiene un User-Agent que contiene iPhone, el tráfico se dirige a SERVICE_IPHONE_URL y el prefijo de URL se cambia a REWRITE_PATH_IPHONE. Todas las demás solicitudes que tienen el prefijo /mobile/ y tienen un User-Agent con un valor distinto de Android o iPhone se dirigen a SERVICE_GENERIC_DEVICE_URL.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*Android.*
         service: $[SERVICE_ANDROID_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_ANDROID]
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*iPhone.*
         service: [SERVICE_IPHONE_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_IPHONE]
       - matchRules:
         - prefixMatch: /mobile/
         service: [SERVICE_GENERIC_DEVICE_URL]

Configura la inserción de errores

La inyección de fallas te permite inyectar un retraso fijo o/y una detención forzada, llamada anulación, a una ruta en particular para probar la resiliencia de una aplicación.

En el ejemplo que aparece a continuación, todas las solicitudes se envían a SERVICE_URL, con un retraso fijo de 10 segundos agregado al 100% de las solicitudes. El cliente que envía las solicitudes observa que todas las respuestas se retrasan 10 segundos. Además, una falla de detención con una respuesta Service Unavailable 503 se aplica al 50% de las solicitudes. El cliente ve que el 50% de sus solicitudes reciben una respuesta 503. Estas solicitudes no alcanzan el servicio de backend.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: [SERVICE_URL]
            weight: 100
          faultInjectionPolicy:
            delay:
              fixedDelay:
                seconds: 10
                nanos: 0
              percentage: 100
            abort:
              httpStatus: 503
              percentage: 50

Establece el filtrado de configuración según la coincidencia de `MetadataFilters`

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.

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

gcloud

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

Borra la regla de reenvío:

gcloud compute forwarding-rules delete forwarding-rule1 \
    --global

Actualiza el archivo forwarding-rule1-config.yaml:

En el siguiente ejemplo, se crea un filtro de metadatos MATCH_ALL:

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

En el siguiente ejemplo, se crea un filtro de metadatos MATCH_ANY:

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ANY'
   filterLabels:
   - name: 'app'
     value: 'review'
   - name: 'version'
     value: 'production'

Quita todos los campos de solo resultados del archivo forwarding-rule1-config.yaml. Para obtener más información, consulta la documentación de gcloud compute forwarding-rules import.

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

Usa estas instrucciones para agregar metadatos de nodo a Envoy antes de iniciar Envoy. Solo se admite un valor de string.

a. Para una implementación basada en VM, en bootstrap_template.yaml, agrega lo siguiente en la sección metadata:
```
   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 env:
```
   - name: ISTIO_META_app
     value: 'review'
   - name: ISTIO_META_version
     value: 'canary'
```

Ejemplos de 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 Cloud Service Mesh 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

Para configurar Cloud Service Mesh para aislar project1, sigue estos pasos:

gcloud

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'

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'
```
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 información sobre la verificación de que una configuración de Cloud Service Mesh funcionan 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, sigue estos pasos:

gcloud

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'
```

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'

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

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.

Bloquea el tráfico entre servicios

Si deseas bloquear el tráfico entre el servicio A y el servicio B, y la implementación está en GKE, configura la seguridad del servicio y usa una política de autorización para bloquear el tráfico entre servicios. Para obtener instrucciones completas, consulta Seguridad del servicio de la malla de servicios de Cloud y las instrucciones de configuración con Envoy y gRPC sin proxy.

¿Qué sigue?

Para ayudarte a resolver problemas de configuración de Cloud Service Mesh, consulta Soluciona problemas de implementaciones que usan Envoy.

Configura la administración avanzada del tráfico con Envoy

Antes de comenzar

Configura la división del tráfico

Console

gcloud

Configura una actualización parcial

Configura implementaciones azul-verde

Configura la duplicación de tráfico

Console

gcloud

Configura la interrupción del circuito

Console

gcloud

Configura la afinidad de sesión basada en HTTP_COOKIE

Console

gcloud

Configura la detección de valores atípicos

Console

gcloud

Establece la política de balanceo de cargas de localidad

Console

gcloud

Configura el redireccionamiento de la URL

Console

gcloud

Configura el direccionamiento del tráfico con reescritura de URL

Configura la inserción de errores

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

gcloud

Ejemplos de filtrado de metadatos

gcloud

gcloud

Soluciona problemas

Bloquea el tráfico entre servicios

¿Qué sigue?

Configura la afinidad de sesión basada en `HTTP_COOKIE`

Establece el filtrado de configuración según la coincidencia de `MetadataFilters`