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

Esta página se ha traducido con Cloud Translation API.

Configurar la gestió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 nuevos usuarios de Cloud Service Mesh. Para obtener más información, consulta la información general sobre el enrutamiento de servicios de Cloud Service Mesh.

En este documento se explica cómo configurar la gestión avanzada del tráfico en implementaciones de Cloud Service Mesh que usan Envoy.

Antes de empezar

Antes de configurar la gestión avanzada del tráfico, sigue las instrucciones de Preparar la configuración de Cloud Service Mesh con Envoy, que incluyen la configuración de Cloud Service Mesh y los hosts de máquinas virtuales o los clústeres de Google Kubernetes Engine (GKE) que necesites. Crea los recursosGoogle Cloud necesarios.

La disponibilidad de las funciones avanzadas de gestión del tráfico varía en función del protocolo de solicitud que elijas. Este protocolo se configura cuando se configura el enrutamiento mediante el proxy HTTP o HTTPS de destino, el proxy 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 descritas en este documento están disponibles.
Con el proxy gRPC de destino, algunas funciones están disponibles.
Con el proxy TCP de destino, no hay funciones de gestión avanzada del tráfico disponibles.

Para obtener más información, consulta las funciones de Cloud Service Mesh y la gestión avanzada del tráfico. Para consultar una guía de configuración completa, consulta Configurar la gestión avanzada del tráfico con servicios de gRPC sin proxy.

Configurar la división del tráfico

En estas instrucciones se presupone lo siguiente:

Tu implementación de Cloud Service Mesh tiene un mapa de URLs llamado review-url-map.
El mapa de URLs envía todo el tráfico a un servicio de backend llamado review1, que actúa como servicio de backend predeterminado.
Quieres dirigir el 5% del tráfico a una nueva versión de un servicio. Ese servicio se ejecuta en una VM o un endpoint de backend de un grupo de endpoints de red (NEG) asociado al servicio de backend review2.
No se usan reglas de host ni matchers de ruta.

Si vas a dividir el tráfico a un nuevo servicio al que no se ha hecho referencia en el mapa de URLs, primero añade el nuevo servicio a weightedBackendServices y asigna un peso de 0. Después, aumenta gradualmente el peso asignado a ese servicio.

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

Consola

En la Google Cloud consola, 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, introduce un nombre.
En el menú Protocolo, selecciona HTTP.
Selecciona una regla de reenvío.
En Reglas de direccionamiento, selecciona Regla de host, ruta y direccionamiento avanzadas.
En Hosts and path matchers (Hosts y comparadores de rutas), haga clic en Add hosts and path matcher (Añadir hosts y comparador de rutas). De esta forma, se añade un nuevo elemento de coincidencia de ruta que puedes configurar para dividir el tráfico.

Añada los siguientes ajustes al campo Path matcher (Coincidencia de ruta):

    - 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

Haz clic en Listo.
Haz clic en Guardar.

Cuando estés satisfecho con la nueva versión, podrás ajustar gradualmente los pesos de los dos servicios y, finalmente, enviar todo el tráfico a review2.

gcloud

Ejecuta el comando gcloud export para obtener la configuración del mapa de URLs:

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

Añade 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 URLs:

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

Cuando estés satisfecho con la nueva versión, podrás ajustar gradualmente los pesos de los dos servicios y, finalmente, enviar todo el tráfico a review2.

Configurar una publicación parcial

Usa un proceso de implementación parcial, a veces denominado canarying, para lanzar una nueva versión de software a una pequeña parte de los servidores antes de lanzar la nueva versión al resto de los servidores de producción.

Una versión parcial usa weightedBackendServices. Para habilitar una versión parcial, designa un servicio de backend como servicio de prueba o Canary y asigna un peso bajo, por ejemplo, 2 o 5. Implementa la nueva versión del software solo en esos servidores. Cuando estés seguro de que la nueva versión no tiene problemas, despliégala en el resto de tus servicios.

Para habilitar un lanzamiento parcial, usa el siguiente código YAML de ejemplo:

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 del servicio backend que recibe el 2% del tráfico.
BACKEND_SERVICE_URL es la URL del servicio backend que recibe el 98% del tráfico.

Configurar despliegues azul-verde

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

Los despliegues azul-verde usan weightedBackendServices. En el ejemplo de YAML que se muestra a continuación, los backends de SERVICE_BLUE_URL se despliegan por completo con la versión de producción actual, mientras que los de SERVICE_GREEN_URL lo hacen con la versión nueva. En la configuración del ejemplo, la implementación GREEN recibe el 100% del tráfico de producción. Si detectas algún problema, puedes invertir los pesos de las dos implementaciones, lo que revertirá de forma eficaz la versión defectuosa GREEN y restaurará la versión BLUE que funciona correctamente. En cualquiera de los dos casos, el tráfico puede cambiar rápidamente, ya que ambas versiones están disponibles para recibirlo.

Para habilitar un despliegue azul-verde, usa el siguiente código YAML de ejemplo:

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 backend que no recibe tráfico.
BACKEND_SERVICE_GREEN_URL es la URL del servicio backend que recibe el 100% de tu tráfico.

Configurar la replicación del tráfico

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

En el siguiente ejemplo, todas las solicitudes se envían a SERVICE_URL y a MIRROR_SERVICE_URL. Solo se vuelven a enviar al cliente las respuestas de SERVICE_URL. MIRROR_SERVICE_URL no afecta al cliente.

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

Consola

En la Google Cloud consola, 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, introduce un nombre.
En la lista Protocol (Protocolo), selecciona HTTP.
Selecciona una regla de reenvío.
En Reglas de direccionamiento, selecciona Regla de host, ruta y direccionamiento avanzadas.
En Hosts and path matchers (Hosts y comparadores de rutas), haga clic en Add hosts and path matcher (Añadir hosts y comparador de rutas). De esta forma, se añade un nuevo comparador de rutas que puedes configurar para replicar el tráfico.

Añada los siguientes ajustes al campo Path matcher (Coincidencia de ruta):

    - 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 refleja.
BACKEND_SERVICE_MIRROR_URL es la URL del servicio backend que quieres replicar.

Haz clic en Listo.
Haz clic en Guardar.

gcloud

Ejecuta el comando gcloud export para obtener la configuración del mapa de URLs:

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

Añade 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 refleja.
BACKEND_SERVICE_MIRROR_URL es la URL del servicio backend que quieres replicar.

Actualiza el mapa de URLs:

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

Configurar la interrupción de circuitos

La interrupción de circuitos te permite definir umbrales de errores para evitar que las solicitudes de los clientes sobrecarguen tus back-ends. Cuando las solicitudes alcancen el límite que hayas definido, el cliente dejará de permitir nuevas conexiones o de enviar solicitudes adicionales, lo que dará tiempo a tus back-ends para recuperarse.

Por lo tanto, el patrón de interrupción de circuitos evita que se produzcan errores en cascada devolviendo un error al cliente en lugar de sobrecargar un backend. De esta forma, se puede servir parte del tráfico y, al mismo tiempo, se dispone de tiempo para gestionar la situación de sobrecarga, como gestionar un pico de tráfico aumentando la capacidad mediante el escalado automático.

En el ejemplo siguiente, los disyuntores se definen de la siguiente manera:

Número máximo de solicitudes por conexión: 100
Número máximo de conexiones: 1000
Número máximo de solicitudes pendientes: 200
Número máximo de solicitudes: 1000
Número máximo de reintentos: 3

Para configurar la interrupción de circuitos, sigue estos pasos:

Consola

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

Ir a Cloud Service Mesh
Haga clic en el nombre del servicio backend que quiera actualizar.
Haz clic en Editar.
Haz clic en Configuraciones avanzadas.
En Disyuntores, marca la casilla Habilitar.
Haz clic en Editar.
1. En Número máximo de solicitudes por conexión, introduce 100.
2. En Número máximo de conexiones, introduce 1000.
3. En Número máximo de solicitudes pendientes, introduzca 200.
4. En Número máximo de solicitudes, introduce 1000.
5. En Reintentos máximos, introduce 3.
Haz clic en Guardar y, a continuación, vuelve a hacer clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Sustituye 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

Configurar la afinidad de sesión en función de `HTTP_COOKIE`

La gestión avanzada del tráfico te permite configurar la afinidad de sesión en función de una cookie proporcionada.

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

Consola

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

Ir a Cloud Service Mesh
Haga clic en el nombre del servicio backend que quiera actualizar.
Haz clic en Editar.
Haz clic en Configuraciones avanzadas.
En Afinidad de sesión, selecciona Cookie HTTP.
En Política de balanceo de carga según ubicación, seleccione Hash de anillo.
1. En el campo Nombre de la cookie HTTP, introduce http_cookie.
2. En el campo Ruta de la cookie HTTP, introduce /cookie_path.
3. En el campo TTL de cookie HTTP, introduce 100.
4. En el campo Tamaño mínimo del anillo, introduce 10000.
Haz clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Sustituye 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
```

Modifica el archivo YAML del siguiente modo:

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

Configurar la detección de valores atípicos

La detección de valores atípicos controla la expulsión de los hosts que no están en buen estado del grupo de balanceo de carga. Cloud Service Mesh lo hace mediante un conjunto de políticas que especifican los criterios para la expulsión de las VMs o los endpoints de backend no saludables 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.

En el siguiente ejemplo, el servicio de backend tiene un grupo de instancias como backend. El ajuste de detección de valores atípicos especifica que el análisis de detección de valores atípicos se ejecuta cada segundo. Si un endpoint devuelve cinco errores 5xx consecutivos, se excluye del balanceo de carga durante 30 segundos la primera vez. El tiempo de expulsión real del mismo endpoint es de 30 segundos multiplicado por el número de veces que se expulsa.

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

Consola

En la Google Cloud consola, 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 Configuraciones avanzadas.
Selecciona la casilla Detección de valores atípicos.
Haz clic en Editar.
1. Define Errores consecutivos en 5.
2. Asigna a Intervalo el valor 1000 milisegundos.
3. Define Tiempo base de expulsión en 30000 milisegundos.
Haz clic en Guardar y, a continuación, vuelve a hacer clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Sustituye 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 del siguiente modo. 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

Definir la política de balanceo de carga según la ubicación

Usa la política de balanceo de carga según ubicación para elegir un algoritmo de balanceo de carga basado en el peso y la prioridad de la ubicación que proporciona Cloud Service Mesh. Por ejemplo, puedes realizar un round robin ponderado entre los endpoints correctos o un hash coherente.

En el siguiente ejemplo, el servicio de backend tiene un grupo de instancias como backend. La política de balanceo de carga según ubicación se ha definido como RING_HASH.

Para definir la política de balanceo de carga según la ubicación, sigue estos pasos:

Consola

En la Google Cloud consola, 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 Configuraciones avanzadas.
En Política de tráfico, en el menú Política de balanceo de carga según ubicación, selecciona Hash de anillo.
Haz clic en Guardar.

gcloud

Ejecuta el comando gcloud export para exportar la configuración del servicio de backend. Sustituye 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 carga de localidad, consulta la documentación del recurso backendService.

Configurar redirección de URL

En estas instrucciones se presupone lo siguiente:

Tu implementación de Cloud Service Mesh tiene un mapa de URLs llamado review-url-map.
El mapa de URLs envía todo el tráfico a un servicio de backend llamado review1, que actúa como servicio de backend predeterminado.
Quieres redirigir el tráfico de un host a otro.

Para configurar la redirección de URL, sigue estos pasos:

Consola

En la Google Cloud consola, 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, introduce un nombre.
En el menú Protocolo, selecciona HTTP.
Selecciona una regla de reenvío.
En Reglas de direccionamiento, selecciona Regla de host, ruta y direccionamiento avanzadas.
En Hosts and path matchers (Hosts y comparadores de rutas), haga clic en Add hosts and path matcher (Añadir hosts y comparador de rutas). De esta forma, se añade un nuevo matcher de ruta que redirige el tráfico.

Añada los siguientes ajustes al campo Path matcher (Coincidencia de ruta):

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

Haz clic en Listo.
Haz clic en Guardar.

gcloud

Ejecuta el comando gcloud export para obtener la configuración del mapa de URLs:

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

Añade 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 URLs:

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

Configurar la dirección de tráfico con reescritura de URLs

La dirección de tráfico te permite dirigir el tráfico a diferentes servicios de backend en función de los atributos de las solicitudes, como los valores de encabezado. Además, puedes configurar acciones como reescribir la URL de la solicitud antes de que se dirija al servicio de backend.

En el siguiente ejemplo, la solicitud se dirige a SERVICE_ANDROID_URL si la ruta de la solicitud contiene el prefijo /mobile/ y el User-Agent de la solicitud incluye Android. Antes de enviar la solicitud al servicio de backend, se puede cambiar el prefijo de la URL a REWRITE_PATH_ANDROID, por ejemplo, /android/. Sin embargo, si el prefijo de la ruta es /mobile/ y tiene un User-Agent que contiene iPhone, el tráfico se dirige a SERVICE_IPHONE_URL y el prefijo de la URL se cambia por REWRITE_PATH_IPHONE. El resto de las solicitudes que tengan el prefijo /mobile/ y 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]

Configurar la inyección de fallos

La inyección de fallos te permite introducir un retraso fijo o una parada forzada (llamada anulación) en una ruta concreta para poner a prueba la resistencia de una aplicación.

En el ejemplo que se indica a continuación, todas las solicitudes se envían a SERVICE_URL, con un retraso fijo de 10 segundos añadido al 100% de las solicitudes. El cliente que envía las solicitudes verá que todas las respuestas se demoran 10 segundos. Además, se aplica un fallo de detención que mostrará un error 503 en el 50% de las solicitudes.Service Unavailable El cliente verá que la mitad de sus solicitudes reciben una respuesta 503. Estas solicitudes no llegan al 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

Configurar el filtrado de configuraciones en función de la coincidencia de `MetadataFilters`

MetadataFilters están habilitados con reglas de reenvío y HttpRouteRuleMatch. Usa esta función para controlar una regla de reenvío o una regla de ruta concretas de forma que el plano de control envíe la regla de reenvío o la regla de ruta solo a los proxies cuyos metadatos de nodo coincidan con el ajuste del filtro de metadatos. Si no especifica ningún MetadataFilters, la regla se envía a todos los proxies de Envoy.

Esta función facilita el funcionamiento de una implementación por fases de una configuración. Por ejemplo, crea una regla de reenvío llamada forwarding-rule1 que solo quieras enviar a los Envoys cuyo metadato de nodo contenga app: review y version: canary.

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

gcloud

Ejecuta el comando gcloud export para obtener la configuración de la regla de reenvío:

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

Elimina 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 salida del archivo forwarding-rule1-config.yaml. Para obtener más información, consulta la documentación de gcloud compute forwarding-rules import.

Ejecuta 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

Sigue estas instrucciones para añadir metadatos de nodos a Envoy antes de iniciar Envoy. Solo se admite un valor de cadena.

a. En una implementación basada en VMs, en bootstrap_template.yaml, añade lo siguiente en la sección metadata:
```
   app: 'review'
   version: 'canary'
```
b. En el caso de un despliegue basado en Google Kubernetes Engine o Kubernetes, en trafficdirector_istio_sidecar.yaml, añade lo siguiente en la sección env:
```
   - name: ISTIO_META_app
     value: 'review'
   - name: ISTIO_META_version
     value: 'canary'
```

Ejemplos de filtrado de metadatos

Sigue estas instrucciones en un caso práctico en el que haya varios proyectos 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, project2
Servicios de backend con instancias de backend o puntos finales que ejecutan un proxy compatible con xDS en project1 y project2

Para configurar Cloud Service Mesh de forma que aísle 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 endpoints de 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 se han implementado en project2 no hayan recibido la regla de reenvío creada en el primer paso. Para ello, intenta acceder a los servicios de project1 desde un sistema que ejecute un proxy en project2. Para obtener información sobre cómo verificar que una configuración de Cloud Service Mesh funciona correctamente, consulta Verificar la configuración.

Para probar una nueva configuración en un subconjunto de proxies antes de que esté disponible para todos los proxies, sigue estos pasos:

gcloud

Inicia los proxies que vas a usar para las pruebas con los siguientes metadatos de nodo. No incluyas los metadatos de este nodo en los proxies que no utilices para las pruebas.
```
  version: 'test'
```

Por cada regla de reenvío que quieras probar, incluye el siguiente filtro de metadatos:

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

Prueba la nueva configuración enviando tráfico a los proxies de prueba y haz los cambios necesarios. Si la nueva configuración funciona correctamente, solo los proxies que pruebes recibirán la nueva configuración. Los proxies restantes no reciben la nueva configuración y no pueden usarla.
Cuando confirmes que la nueva configuración funciona correctamente, quita el filtro de metadatos asociado. De esta forma, todos los proxies recibirán la nueva configuración.

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.

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 las respuestas HTTP 4xx y 5xx de una regla de ruta determinada.

Solución: Como las reglas de ruta se interpretan por orden de prioridad, revise la prioridad asignada a cada regla.

Cuando defina reglas de ruta, compruebe que las reglas con mayor prioridad (es decir, con números de prioridad más bajos) no enruten por error el tráfico que, de lo contrario, se habría enrutado mediante una regla de ruta posterior. Veamos un ejemplo:

Regla de primera ruta
- Ruta de coincidencia de la regla de ruta = /shopping/
- Acción de redirección: enviar tráfico al servicio de backend service-1
- Prioridad de la regla: 4
Segunda regla de ruta
- Regla de ruta match regexMatch = /shopping/cart/ordering/.*
- Acción de redirección: enviar 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 dirige a service-1. Aunque la segunda regla habría coincidido, se ignora porque la primera regla tenía prioridad.

Bloquear el tráfico entre servicios

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

Siguientes pasos

Para ayudarte a resolver los problemas de configuración de Cloud Service Mesh, consulta el artículo Solucionar problemas de implementaciones que usan Envoy.

Configurar la gestión avanzada del tráfico con Envoy

Antes de empezar

Configurar la división del tráfico

Consola

gcloud

Configurar una publicación parcial

Configurar despliegues azul-verde

Configurar la replicación del tráfico

Consola

gcloud

Configurar la interrupción de circuitos

Consola

gcloud

Configurar la afinidad de sesión en función de HTTP_COOKIE

Consola

gcloud

Configurar la detección de valores atípicos

Consola

gcloud

Definir la política de balanceo de carga según la ubicación

Consola

gcloud

Configurar redirección de URL

Consola

gcloud

Configurar la dirección de tráfico con reescritura de URLs

Configurar la inyección de fallos

Configurar el filtrado de configuraciones en función de la coincidencia de MetadataFilters

gcloud

Ejemplos de filtrado de metadatos

gcloud

gcloud

Solución de problemas

Bloquear el tráfico entre servicios

Siguientes pasos

Configurar la afinidad de sesión en función de `HTTP_COOKIE`

Configurar el filtrado de configuraciones en función de la coincidencia de `MetadataFilters`