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.
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.
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.
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.- En Máximo de solicitudes por conexión, ingresa
100
. - En Máximo de conexiones, ingresa
1000
. - En Máximo de solicitudes pendientes, ingresa
200
. - En Máximo de solicitudes, ingresa
1000
. - En Máximo de reintentos, ingresa
3
.
- En Máximo de solicitudes por conexión, ingresa
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. ReemplazaBACKEND_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.
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.
- En el campo Nombre de cookie HTTP, ingresa
http_cookie
. - En el campo Ruta de acceso de cookie HTTP, ingresa
/cookie_path
. - En el campo TTL de cookie HTTP, ingresa
100
. - En el campo Tamaño mínimo del anillo, ingresa
10000
.
- En el campo Nombre de cookie HTTP, ingresa
Haz clic en Guardar.
gcloud
Ejecuta el comando
gcloud export
para exportar la configuración del servicio de backend. ReemplazaBACKEND_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.
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.- Establece Errores con errores en
5
. - Establece Intervalo en
1000
milisegundos. - Establece el Tiempo de expulsión base en
30000
milisegundos.
- Establece Errores con errores en
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. ReemplazaBACKEND_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 porBACKEND_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.
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. ReemplazaBACKEND_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.
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 degcloud compute forwarding-rules import
.Usa el comando
gcloud import
para actualizar el archivoforwarding-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ónmetadata
: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ónenv
:- 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
yproject2
- Servicios de backend con extremos o instancias de backend que ejecutan un proxy que cumple con xDS en
project1
yproject2
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 enproject1
desde un sistema que ejecuta un proxy enproject2
. 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
y5xx
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
- La ruta de acceso coincide con pathPrefix =
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
- La ruta de acceso coincide con regexMatch =
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.