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

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

    Ir a Cloud Service Mesh

  2. Haz clic en Mapas de reglas de enrutamiento.

  3. Haz clic en Crear mapa de reglas de enrutamiento.

  4. En la página Crear un mapa de reglas de enrutamiento, ingresa un Nombre.

  5. En el menú Protocolo, selecciona HTTP.

  6. Selecciona una regla de reenvío existente.

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

  8. 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.

  9. 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
    
  10. Haga clic en Listo.

  11. 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

  1. 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
    
  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 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

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

    Ir a Cloud Service Mesh

  2. Haz clic en Mapas de reglas de enrutamiento.

  3. Haz clic en Crear mapa de reglas de enrutamiento.

  4. En la página Crear un mapa de reglas de enrutamiento, ingresa un Nombre.

  5. En la lista Protocolo, selecciona HTTP.

  6. Selecciona una regla de reenvío existente.

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

  8. 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.

  9. 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.
  10. Haga clic en Listo.

  11. Haz clic en Guardar.

gcloud

  1. 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
    
  2. 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.
  3. 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

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

    Ir a Cloud Service Mesh

  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.

    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.
  7. Haz clic en Guardar y, luego, vuelve a hacer clic en Guardar.

gcloud

  1. 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
    
  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/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
    
  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
    

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

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

    Ir a Cloud Service Mesh

  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.

    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.
  7. Haz clic en Guardar.

gcloud

  1. 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
    
  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. 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

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

    Ir a Cloud Service Mesh

  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.

    1. Establece Errores con errores en 5.
    2. Establece Intervalo en 1000 milisegundos.
    3. Establece el Tiempo de expulsión base en 30000 milisegundos.
  7. Haz clic en Guardar y, luego, vuelve a hacer clic en Guardar.

gcloud

  1. 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
    
  2. 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
    
  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
    

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

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

    Ir a Cloud Service Mesh

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

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

    Ir a Cloud Service Mesh

  2. Haz clic en Mapas de reglas de enrutamiento.

  3. Haz clic en Crear mapa de reglas de enrutamiento.

  4. En la página Crear un mapa de reglas de enrutamiento, ingresa un Nombre.

  5. En el menú Protocolo, selecciona HTTP.

  6. Selecciona una regla de reenvío existente.

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

  8. 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.

  9. 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
    
  10. Haga clic en Listo.

  11. Haz clic en Guardar.

gcloud

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

  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. Borra la regla de reenvío:

    gcloud compute forwarding-rules delete forwarding-rule1 \
        --global
    
  3. 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'
    
  4. 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.

  5. 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
    
  6. 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

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

  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 4xx5xx 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?