Traffic Management

En la pestaña TRAFFIC MANAGEMENT puede ver y aplicar reglas de enrutamiento dentro de un servicio. Las reglas permiten definir los criterios que se utilizarán para enrutar el tráfico de peticiones entre diferentes versiones implementadas del mismo servicio. Para acceder a la pestaña, seleccione un servicio de la lista de la pantalla Services (o después de hacer clic en una malla en la pantalla Meshes).

Pestaña "Traffic Management"

En esta pestaña donde puede orquestar el lanzamiento de versiones de un servicio siguiendo las configuraciones de tráfico deseadas. Esto reduce los riesgos asociados al lanzamiento de una nueva versión, así como el downtime de su operación, ya que puede implementar pruebas y configurar un cambio gradual del tráfico real de una versión antigua a una nueva.

Sensedia Service Mesh permite dos tipos de reglas de enrutamiento de tráfico, que son los siguientes:

Traffic Routing: Permite enrutar el tráfico de peticiones a otras versiones del servicio según criterios definidos.
Shadow Traffic: Permite una prueba específica de una nueva versión. En lugar de enrutar una parte de las peticiones a ser respondidas por la nueva versión, la nueva versión recibirá un porcentaje de las peticiones ya manejadas por el servicio anterior, y no tendrá que responder a esas peticiones. Esto le permite probar la nueva versión con peticiones reales, pero sin ningún impacto en el tráfico productivo del servicio.

A lo largo de esta página, verá cómo configurar cada uno de estos tipos de reglas de enrutamiento.

Dado que Sensedia Service Mesh es una aplicación Kubernetes-native, también es posible configurar estas reglas desde la línea de comando usando kubectl. El recuadro "Creando una regla desde la línea de comando" contiene un archivo .yaml de ejemplo para hacerlo.

Permisos de acceso

Las acciones que puede realizar en esta pantalla dependen de los permisos establecidos para su usuario en Sensedia Access Control.

La siguiente tabla muestra los posibles permisos y sus acciones:

Permiso	Descripción
List Traffic Routings	Permite ver en la lista de reglas la información básica de una regla de Traffic Routing creada para un servicio.
List Shadow Traffics	Permite ver en la lista de reglas la información básica de una regla de Shadow Traffic creada para un servicio.
Read Traffic Routings	Permite ver la configuración de una regla de Traffic Routing creada para un servicio. Sin embargo, no permite la edición de la regla.
Read Shadow Traffics	Permite ver la configuración de una regla de Shadow Traffic creada para un servicio. Sin embargo, no permite la edición de la regla.
Write Traffic Routings	Permite editar, eliminar y crear reglas de Traffic Routing para los servicios.
Write Shadow Traffics	Permite editar, eliminar y crear reglas de Shadow Traffic para los servicios.

Permiso

Descripción

List Traffic Routings

Permite ver en la lista de reglas la información básica de una regla de Traffic Routing creada para un servicio.

List Shadow Traffics

Permite ver en la lista de reglas la información básica de una regla de Shadow Traffic creada para un servicio.

Read Traffic Routings

Permite ver la configuración de una regla de Traffic Routing creada para un servicio. Sin embargo, no permite la edición de la regla.

Read Shadow Traffics

Permite ver la configuración de una regla de Shadow Traffic creada para un servicio. Sin embargo, no permite la edición de la regla.

Write Traffic Routings

Permite editar, eliminar y crear reglas de Traffic Routing para los servicios.

Write Shadow Traffics

Permite editar, eliminar y crear reglas de Shadow Traffic para los servicios.

Listado de reglas de enrutamiento

Las reglas de enrutamiento creadas estarán visibles en el listado de la pestaña TRAFFIC MANAGEMENT para el servicio correspondiente.

Visualización de las reglas de enrutamiento creadas para un servicio específico

La información de la lista de reglas de enrutamiento configurada para el servicio incluye:

el tipo de regla (Traffic Routing o Shadow Traffic, identificado por un icono en la columna TYPE);
nombre identificador para la regla de enrutamiento (columna NAME);
tipo de conexión, que puede ser interna (internal) o externa (external) (columna CONNECTION TYPE);
ruta (o URI) de la API que expone el servicio — señalando que el mismo servicio puede tener más de una regla configurada con diferentes paths (columna PATH);
nombre identificador de la(s) versión(es) del servicio que recibe el tráfico (columna DESTINATION);
estado de la regla, — que puede ser "aprovisionado" (Provisioned), "no administrado" (Unmanaged), "desactivado" (Disabled) o "con error" (Error) — (columna STATUS);
fecha y hora de creación de la regla (columna CREATED AT).

La columna ENABLED incluye un botón que permite desactivar o activar la regla.

La columna ACTIONS contiene dos botones que le permiten:

editar la configuración de la regla;
eliminar la regla.

Traffic Routing

La funcionalidad Traffic Routing permite enrutar el tráfico de peticiones a diferentes versiones de un mismo microservicio según un criterio.

Hay dos tipos de criterios disponibles para definir cómo será redirigido el tráfico: por Weight o por Header.

Traffic Routing por peso (weight): establece un criterio de probabilidad por peso (porcentaje de peticiones) para enrutar el tráfico. Por ejemplo: puede enrutar el 80% de las peticiones a la primera versión de un servicio y el 20% restante a una segunda versión del mismo servicio.
Traffic Routing por header: valida la presencia de metadatos en la petición (un header) con un nombre y un valor predeterminados para enrutar las peticiones a las versiones desplegadas del servicio.

Para estos dos tipos, es posible enrutar el tráfico a las conexiones externas (peticiones que provienen de fuera de la malla) o a las conexiones internas (peticiones de otros servicios de la malla).

Creación de una regla de Traffic Routing por peso (weight)

Para crear una nueva regla para el servicio seleccionado, haga clic en el botón ADD NEW RULE de la pestaña TRAFFIC MANAGEMENT.

Se abrirá una ventana modal con dos campos para configurar la regla: Los campos que se van a rellenar varían según el tipo de conexión del servicio: external en el caso de servicios expuestos externamente y internal para los servicios expuestos solo a otros servicios de la malla.

Servicios internos

En el caso de los servicios internos, los campos a rellenar son los siguientes:

Type: tipo de regla (elija el tipo Traffic Routing).
Name: nombre identificador para la regla.

El nombre debe ser único para la malla/namespace del que forma parte el servicio.
Port: puerto que expone el servicio en Kubernetes.
Enable mTLS: casilla de verificación que debe ser marcada para habilitar la conexión segura de tipo mTLS.
Connection Type: tipo de conexión del servicio, que puede ser externa o interna (en este caso, elija internal).
Path: ruta de la API que expone el servicio (opcional).
Split by: campo para definir el tipo de política de enrutamiento, ya sea por porcentaje de peticiones (weight) o por validación de encabezado (header). En este caso, elija Weight.

Campos de la sección DESTINATIONS:

Traffic Name: nombre identificador para la versión del servicio.
Version: valor de la versión del servicio.
Weight: especifica el porcentaje de peticiones que se asignarán a la versión del servicio informada.

Los tres campos mencionados anteriormente se replican automáticamente en función del número de versiones implementadas para el servicio.

La suma de todos los porcentajes incluidos en los campos Weight de la regla que se configuran debe ser igual al 100%.

Servicios externos

En el caso de los servicios externos (seleccionando la opción "External" en el campo Connection Type), además de los mismos campos que los servicios internos, existe la sección INGRESS CONFIGURATION, que contiene la opción Bind to default ingress. Si se marca esta opción, se utilizará el Istio Ingress Gateway para exponer externamente los servicios presentes en el cluster (por defecto).

Si desea utilizar otro ingress, la opción Bind to default ingress debe estar desmarcada. Tenga en cuenta que en este caso se requerirán ajustes adicionales de instalación.

Lea sobre cómo integrar el Ingress NGINX.

Creando una regla desde la línea de comando

Para crear una regla de Traffic Routing por peso a través de kubectl, aplica un archivo .yaml como el del siguiente ejemplo:

apiVersion: networking.sensedia.com/v1
kind: TrafficRouting
metadata:
  name: tr-reviews
  namespace: bookinfo
spec:
  connectionType: Internal
  enabled: true
  port: 9999
  serviceName: reviews
  traffic:
    - name: traffic-name-v1
      version: v1
      weight: 80
    - name: traffic-name-v2
      version: v2
      weight: 20

La configuración de la regla en este archivo se realiza a través de los siguientes campos:

.kind: especifica el tipo de objeto que se va a crear; en este caso, un objeto del tipo TrafficRouting;
.metadata.name: define un nombre para identificar el recurso;
.metadata.namespace: la malla/namespace del que forma parte el servicio;
.spec.connectionType: tipo de conexión de la regla, Internal o External;
.spec.enabled: habilita (enabled: true) o deshabilita (enabled: false) la regla;
.spec.port: puerto que expone el servicio en Kubernetes;
.spec.serviceName: especifica el servicio al que se aplicará la regla.
.spec.traffic.name: nombre identificador del destino del tráfico;
.spec.traffic.version: valor de la versión del servicio a la cual se enrutará el tráfico;
.spec.traffic.weight: porcentaje de peticiones que se asignarán a la versión del servicio informada.

El archivo .yaml del ejemplo anterior configura para el servicio reviews del namespace bookinfo una regla de Traffic Routing de conexión interna que puede enrutar el 80% de las peticiones a la versión v1 de ese servicio y el 20% restante a la versión v2.

Creando una regla de Traffic Routing del tipo encabezado

La regla de Traffic Routing del tipo header utiliza como criterio la presencia de un header con un nombre y un valor predeterminados para enrutar peticiones entre las versiones configuradas de los servicios.

Para crear una nueva regla para el servicio seleccionado, haga clic en el botón ADD NEW RULE de la pestaña TRAFFIC MANAGEMENT.

Servicios internos

En el caso de los servicios internos, los campos a rellenar son los siguientes:

Type: tipo de regla (elija el tipo Traffic Routing).
Name: nombre identificador para la regla.

El nombre debe ser único para la malla/namespace del que forma parte el servicio.
Port: puerto que expone el servicio en Kubernetes.
Enable mTLS: casilla de verificación que debe ser marcada para habilitar la conexión segura de tipo mTLS.
Connection Type: tipo de conexión del servicio, que puede ser externa o interna (en este caso, elija internal).
Path: ruta de la API que expone el servicio (opcional).
Split by: campo para definir el tipo de política de enrutamiento, ya sea por porcentaje de peticiones (weight) o por validación de encabezado (header). En este caso, elija Header.

Campos de la sección DESTINATION:

Traffic Name: nombre identificador para la versión del servicio (que puede ser igual al campo Version o más descriptivo).
Version: valor de la versión del servicio.
Header: campo para introducir el nombre del encabezado que se validará para enrutar las peticiones.
Value: campo para introducir el valor del encabezado que se validará para enrutar las peticiones.

Si lo desea, puede agregar más de un encabezado a un destino. En este caso, todos los encabezados insertados deben estar contenidos en una petición para que se enrute a la versión en cuestión. Para incluir un encabezado adicional, haga clic en el ícono + junto al campo Value.

También puede agregar otros destinos para la misma Traffic Routing de tipo encabezado. Para eso, haga clic en el botón + ADD DESTINATION. Puede agregar tantos encabezados como desee al nuevo destino que creó.

Servicios externos

Si desea utilizar otro ingress, la opción Bind to default ingress debe estar desmarcada. Tenga en cuenta que en este caso se requerirán ajustes adicionales de instalación.

Lea sobre cómo integrar el Ingress NGINX.

Como en los servicios internos, puede agregar varios destinos para la misma Traffic Routing, así como incluir más de un encabezado por destino.

Creando una regla desde la línea de comando

Para crear una regla de Traffic Routing del tipo de encabezado a través de kubectl, aplica un archivo .yaml como el del siguiente ejemplo:

apiVersion: networking.sensedia.com/v1
kind: TrafficRouting
metadata:
  name: tr-reviews-header-int
  namespace: bookinfo
spec:
  connectionType: Internal
  enabled: true
  port: 9999
  serviceName: reviews
  traffic:
    - name: reviews-v1
      version: v1
      headers:
        header-1:
          exact: value-1
        header-2:
          exact: value-2
    - name: reviews-v2
      version: v2
      headers:
        header-3:
          exact: value-3
        header-4:
          exact: value-4

La configuración de la regla en este archivo se realiza a través de los siguientes campos:

.kind: especifica el tipo de objeto que se va a crear; en este caso, un objeto del tipo TrafficRouting;
.metadata.name: define un nombre para identificar el recurso;
.metadata.namespace: la malla/namespace del que forma parte el servicio;
.spec.connectionType: tipo de conexión de la regla, Internal o External;
.spec.enabled: habilita (enabled: true) o deshabilita (enabled: false) la regla;
.spec.port: puerto que expone el servicio en Kubernetes;
.spec.serviceName: especifica el servicio al que se aplicará la regla.
.spec.traffic.name: nombre identificador del destino del tráfico;
.spec.traffic.version: valor de la versión del servicio a la cual se enrutará el tráfico;
.spec.traffic.headers: nombre y valor (exact) del encabezado que se validará para enrutar las peticiones.

Shadow Traffic

Traffic shadowing es una estrategia de implementación de versiones que no afecta al tráfico de un servicio. Cuando se aplica, se implementa una nueva versión del servicio que recibe una parte de las peticiones ya manejadas por la versión anterior, sin tener que responder a esas peticiones.

Solo puede crear una versión del tipo Shadow Traffic si hay una Traffic Routing de tipo peso para recibir el 100% de las peticiones.

La configuración de una política de enrutamiento de este tipo es independiente de si el servicio está expuesto al tráfico externo o no. Los campos que se completarán son los siguientes:

Type: tipo de regla (elija el tipo Shadow Traffic).
Name: nombre identificador para la regla.

El nombre debe ser único para la malla/namespace del que forma parte el servicio.
Port: puerto que expone el servicio en Kubernetes.

Campos de la sección Mirror traffic to:

Traffic Name: nombre identificador de la versión del servicio que recibirá una parte de las peticiones, sin enviar las respuestas. El nombre puede ser el mismo que el campo Version o más descriptivo.
Version: valor de la versión del servicio.
Mirroring: porcentaje de peticiones que se reflejarán a la versión indicada.

Creando una regla desde la línea de comando

Para crear una regla de Shadow Traffic a través de kubectl, aplica un archivo .yaml como el del siguiente ejemplo:

apiVersion: networking.sensedia.com/v1
kind: ShadowTraffic
metadata:
  name: st-reviews
  namespace: bookinfo
spec:
  enabled: true
  port: 9999
  serviceName: reviews
  mirror:
      name: reviews-v2
      version: v2
      percentage: 80

La configuración de la regla en este archivo se realiza a través de los siguientes campos:

.kind: especifica el tipo de objeto que se va a crear; en este caso, un objeto del tipo ShadowTraffic;
.metadata.name: define un nombre para identificar el recurso;
.metadata.namespace: la malla/namespace del que forma parte el servicio;
.spec.enabled: habilita (enabled: true) o deshabilita (enabled: false) la regla;
.spec.port: puerto que expone el servicio en Kubernetes;
.spec.serviceName: especifica el servicio al que se aplicará la regla.
.spec.mirror.name: nombre identificador del destino que recibe la copia del tráfico;
.spec.mirror.version: valor de la versión del servicio a la cual se enrutará el tráfico;
.spec.mirror.percentage: porcentaje de peticiones que se reflejarán a la versión indicada. Campo opcional. Si se omite, el valor a considerar será 100%.

Thanks for your feedback!

EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]