En este documento, se proporciona información sobre cómo configurar la administración avanzada de tráfico para tu implementación de Traffic Director.
Antes de configurar la administración avanzada de tráfico
Sigue las instrucciones en Configura Traffic Director, incluidas las instrucciones para configurar Traffic Director y cualquier host de VM o clúster de GKE que necesites. Crea los recursos de Google Cloud necesarios.
Configura la división de tráfico
En estas instrucciones, se supone que se cumplen estas condiciones:
- Tu implementación de Traffic Director tiene un mapa de URL llamado
review-url-map
. - El mapa de URL envía todo el tráfico a un servicio de backend, llamado
review1
, que también funciona como el servicio de backend predeterminado. - Tu plan es enrutar el 5% del tráfico a una nueva versión de un servicio. Ese servicio se ejecuta en un extremo o una VM de backend en un NEG asociado con el servicio de backend
review2
. - No se usan reglas de host ni comparadores de rutas de acceso.
Para configurar la división de tráfico, sigue estos pasos:
Console
Ve a la página de Traffic Director en Cloud Console.
Haz clic en Create Routing rule maps.
Ingresa el nombre del mapa de reglas de enrutamiento.
Selecciona HTTP en el menú Protocolo.
Selecciona una regla de reenvío existente.
En Reglas de enrutamiento, selecciona Regla de enrutamiento, ruta de acceso y host avanzado.
En Comparador de rutas de acceso, selecciona Split traffic between services.
Haz clic en el botón YAML View.
Agrega la siguiente configuración al cuadro Comparador de rutas de acceso:
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
Haz clic en Listo.
Haz clic en Crear.
gcloud
Usa el comando
gcloud export
para obtener la configuración del mapa de URL:gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
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 la interrupción de circuitos
La interrupción de circuitos te permite establecer umbrales de fallas para evitar que las solicitudes del cliente sobrecarguen tus backends. Después de que las solicitudes alcanzan el límite que estableciste, el cliente deja de permitir conexiones nuevas o enviar solicitudes adicionales, lo que le da tiempo a los backends para recuperarse.
De esta manera, la interrupción de circuitos evita errores en cascada, ya que muestra un error al cliente en vez de sobrecargar un backend. Esto permite que se entregue parte del tráfico mientras se proporciona tiempo para administrar la situación de sobrecarga, como controlar un aumento repentino de tráfico mediante el aumento de la capacidad a través del ajuste de escala automático.
En el siguiente ejemplo, debes establecer los disyuntores de esta manera:
- Máximo de solicitudes por conexión: 100
- Máximo de conexiones: 1,000
- Máximo de solicitudes pendientes: 200
- Máximo de solicitudes: 1,000
- Máximo de reintentos: 3
Para configurar la interrupción del circuito, sigue estos pasos:
Console
- En Cloud Console, ve a la página de Traffic Director.
- 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
. - Haz clic en Guardar.
- Haz clic en Guardar.
gcloud
Usa el comando
gcloud export
para obtener la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Actualiza el archivo BACKEND_SERVICE_NAME.yaml de la siguiente manera:
affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group:https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/zones/<var>ZONE</var>/instanceGroups/<var>INSTANCE_GROUP_NAME</var> maxUtilization: 0.8 circuitBreakers: maxConnections: 1000 maxPendingRequests: 200 maxRequests: 1000 maxRequestsPerConnection: 100 maxRetries: 3 connectionDraining: drainingTimeoutSec: 300 healthChecks: - https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/global/healthChecks/<var>HEALTH_CHECK_NAME</var> loadBalancingScheme: INTERNAL_SELF_MANAGED localityLbPolicy: ROUND_ROBIN name: <var>BACKEND_SERVICE_NAME</var> port: 80 portName: http protocol: HTTP sessionAffinity: NONE timeoutSec: 30 ```
Actualiza el archivo de configuración del servicio de backend:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
El siguiente ejemplo de disyuntor para un caso de uso en el que un servicio de carrito de compras tiene un grupo de instancias como backend. La configuración del disyuntor indica los límites de los siguientes valores:
- Cantidad máxima de solicitudes paralelas por conexión
- Cantidad máxima de conexiones paralelas
- Cantidad máxima de solicitudes pendientes
- Cantidad máxima de solicitudes paralelas
- Cantidad máxima de reintentos paralelos
Para configurar este ejemplo de interrupción de circuito, sigue estos pasos:
Console
- En Cloud Console, ve a la página de Traffic Director.
- 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
20000
. - En Máximo de reintentos, ingresa
3
. - Haz clic en Guardar.
- Haz clic en Guardar.
gcloud
Usa el comando
gcloud export
para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Configura la afinidad de sesión basada en HTTP_COOKIE
La administración avanzada de tráfico te permite configurar la afinidad de sesión en función de una cookie proporcionada. Para configurar la afinidad de sesión basada en HTTP_COOKIE, sigue estas instrucciones.
Para configurar la afinidad de sesión con HTTP_COOKIE
, sigue estos pasos:
Console
En Cloud Console, ve a la página de Traffic Director.
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
.Haz clic en GUARDAR.
gcloud
Usa el comando
gcloud export
para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
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. Traffic Director hace esto mediante un conjunto de políticas que especifican los criterios para la expulsión de extremos o VM de backend en mal estado en los NEG, junto con criterios que definen cuándo se considera que un backend o extremo tienen el estado adecuado para recibir tráfico otra vez.
En el siguiente ejemplo, el servicio de backend tiene un grupo de instancias como su backend. La configuración de la detección de valores atípicos especifica que el análisis de detección de valores atípicos se ejecuta cada segundo. Si un extremo muestra cinco errores 5xx
consecutivos, se expulsa de la consideración del balanceo de cargas durante 30 segundos por primera vez. El tiempo de expulsión real para el mismo extremo es de 30 segundos por cada vez que se expulsa.
La detección de valores atípicos se configura en el recurso de servicio de backend.
Console
En Cloud Console, ve a la página de Traffic Director.
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.Haz clic en Guardar.
Haz clic en Guardar.
gcloud
Usa el comando
gcloud export
para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Actualiza el archivo
YAML
de la siguiente manera y sustituye el nombre del servicio de backend por your_service_name:name: your_service_name loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $[INSTANCE_GROUP_URL] healthChecks: - $[HEALTH_CHECK_URL] port: 80 portName: http protocol: HTTP outlierDetection: consecutiveErrors: 5, interval: seconds: 1, nanos: 0 baseEjectionTime: seconds: 30, nanos: 0 ````
Importa el archivo de configuración del servicio de backend:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Configura la política de balanceo de cargas de localidad
Usa la política de balanceo de cargas de localidad para elegir un algoritmo de balanceo de cargas según el peso de la localidad y la prioridad que proporciona Traffic Director. Por ejemplo, puedes usar un round robin ponderado entre extremos en buen estado o realizar un hash coherente.
En el siguiente ejemplo, el servicio de backend tiene un grupo de instancias como su backend. La política de balanceo de cargas de localidad se establece en RING_HASH
.
Console
En Cloud Console, ve a la página de Traffic Director.
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
Usa el comando
gcloud export
para exportar la configuración del servicio de backend. En este comando, BACKEND_SERVICE_NAME es el nombre del servicio de backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
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 sobre el recurso backendService.
Establece el filtrado de configuración según la coincidencia de MetadataFilter
Los MetadataFilters
están habilitados con las reglas de reenvío y HttpRouteRuleMatch
.
Usa esta función para controlar una regla de reenvío o regla de enrutamiento en particular, de modo que el plano de control envíe la regla de reenvío o la regla de enrutamiento solo a los proxies cuyos metadatos de nodo coincidan con la configuración del filtro de metadatos. Si no especificas MetadataFilters
, la regla se envía a todos los proxies de Envoy.
Esta función facilita la operación de una implementación publicada en etapa de pruebas de una configuración.
Por ejemplo, crea una regla de reenvío llamada forwarding-rule1
, que deseas que se envíe solo a Envoys cuyos metadatos de nodo contengan “app: review” y “version: canary”.
Sigue los pasos a continuación para agregar MetadataFilters
a la regla de reenvío.
Para agregar MetadataFilter
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
Actualiza el archivo
forwarding-rule1-config.yaml
:metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'canary'
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. Ten en cuenta que solo se admite el valor de string.
a. Para una implementación basada en VM, en bootstrap_template.yaml, agrega lo siguiente en la sección de metadatos:
app: 'review' version: 'canary'
b. Para una implementación basada en Google Kubernetes Engine o en Kubernetes, en trafficdirector_istio_sidecar.yaml, agrega lo siguiente en la sección del entorno:
- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
Ejemplos con filtrado de metadatos
Usa las siguientes instrucciones para una situación en la que varios proyectos se encuentren en la misma red de VPC compartida y quieras que los recursos de Traffic Director de cada proyecto de servicio sean visibles para los proxies del mismo proyecto.
La configuración de la VPC compartida es la siguiente:
- Nombre del proyecto host:
vpc-host-project
- Proyectos de servicio:
project1
yproject2
- Servicios de backend con extremos o instancias de backend que ejecutan un proxy que cumple con xDS en
project1
yproject2
Si deseas configurar Traffic Director para aislar project1
, haz lo siguiente:
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 obtener información sobre cómo verificar que una configuración de Traffic Director funcione de forma correcta, consulta Verifica la configuración.
Para probar una configuración nueva en un subconjunto de proxies antes de ponerla a disposición de todos los proxies, haz lo siguiente:
gcloud
Inicia los proxies que usas para realizar pruebas con los siguientes metadatos de nodo. No incluyas estos metadatos de nodo para proxies que no usas con el fin de realizar pruebas.
version: 'test'
En cada regla de reenvío nueva que quieras probar, incluye el siguiente filtro de metadatos:
metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'version' value: 'test'
Prueba la configuración nueva mediante el envío del tráfico a los proxies de prueba y realiza los cambios necesarios. Si la configuración nueva funciona de forma adecuada, solo los proxies que pruebes recibirán esta configuración. Los proxies restantes no reciben la configuración nueva y no pueden usarla.
Cuando confirmes que la configuración nueva funciona de forma adecuada, quita el filtro de metadatos asociado a ella. Esto permite que todos los proxies reciban la configuración nueva.
Soluciona problemas
Usa esta información para solucionar problemas cuando el tráfico no se enruta de acuerdo con las reglas de enrutamiento y las políticas de tráfico que configuraste.
Síntomas:
- Mayor tráfico a los servicios en reglas que se encuentran por encima de la regla en cuestión
- Aumento inesperado en las respuestas HTTP 4xx y 5xx para una regla de enrutamiento determinada
Solución: Revisa la prioridad asignada a cada regla, ya que las reglas de enrutamiento se interpretan en orden de prioridad.
Cuando definas reglas de enrutamiento, asegúrate de que las reglas con mayor prioridad (es decir, con números de prioridad más bajos) no enruten de forma inadvertida el tráfico que, de lo contrario, habría sido enrutado por una regla de enrutamiento posterior. Considera el siguiente ejemplo:
Primera regla de enrutamiento
- La ruta de acceso coincide con pathPrefix = '/shopping/';
- Acción de redireccionamiento: envía tráfico al servicio de backend
service-1
- Prioridad de la regla: 4
Segunda regla de enrutamiento
- La ruta de acceso coincide con regexMatch = '/shopping/cart/ordering/.*';
- Acción de redireccionamiento: envía tráfico al servicio de backend
service-2
- Prioridad de la regla: 8
En este caso, una solicitud con la ruta “/shopping/cart/ordering/cart.html” se enruta a service-1
. Aunque la segunda regla coincida, se ignora porque la primera regla tiene prioridad.
Limitaciones
- Si el valor de
BackendService.sessionAffinity
no es NONE, yBackendService.localityLbPolicy
se establece en una política de balanceo de cargas distinta deMAGLEV
oRING_HASH
, la configuración de afinidad de sesión no se aplicará. - Con el comando
gcloud import
, no se borran los campos de nivel superior del recurso, como el servicio de backend y el mapa de URL. Por ejemplo, si se crea un servicio de backend con configuración decircuitBreakers
, esa configuración puede actualizarse mediante un comandogcloud import
posterior. Sin embargo, esa configuración no se puede borrar del servicio de backend. El recurso se puede borrar y volver a crear sin la configuración decircuitBreakers
. - La importación de reglas de reenvío no funciona de forma adecuada. Un archivo YAML exportado no se puede volver a importar. La solución alternativa es exportar el archivo de configuración, realizar cambios, borrar la regla de reenvío y, luego, importar el archivo de configuración.