Traffic Management

On the TRAFFIC MANAGEMENT tab you can view and apply traffic routing rules within a service. These rules allow you to define the criteria you can use to route the traffic of requests within the different deployed versions of the same service. To access it, select a service from the Services screen list (or after clicking on a mesh in the Meshes screen).

traffic management
"Traffic Management" Tab

On this tab you can manage the release of service versions following the traffic settings you specify. This mitigates the risks associated with the release of a new version, as well as the operation downtime, since you can both implement tests or gradually shift real traffic from an old version to a new one.

Sensedia Service Mesh offers two types of traffic routing rules, which are:

  • Traffic Routing: It allows the traffic routing of requests to other service versions according to previously defined criteria.

  • Shadow Traffic: It allows specifically testing a new version. Instead of routing part of the requests to be responded by the new version, a portion of requests that have already been treated by the old service is routed to the new version, which no longer needs to respond to these requests. This will enable testing the new version with real requests, but without any impact on the productive traffic of the service.

Throughout this page, you will see how to configure each one of these routing rule types.

Keep in mind that Sensedia Service Mesh is a Kubernetes-native application. This means you can also configure these rules from the command line using kubectl. “Creating a rule from the command line” board brings an example of how to do that with a .yaml file.

Access permissions

The actions you can perform on this screen depend on the permissions set for your user in Sensedia Access Control.

The following table shows the possible permissions and the corresponding actions:

Permission Description

List Traffic Routings

It allows the visualization in the rule list of the basic information of a Traffic Routing rule created for a service.

List Shadow Traffics

It allows the visualization in the rule list of the basic information of a Shadow Traffic rule created for a service.

Read Traffic Routings

It allows the visualization of the configuration of a Traffic Routing rule created for a service. It does not, however, allow the rule to be edited.

Read Shadow Traffics

It allows the visualization of the configuration of a Shadow Traffic rule created for a service. It does not, however, allow the rule to be edited.

Write Traffic Routings

It allows editing, deleting, and creating Traffic Routing rules for services.

Write Shadow Traffics

It allows editing, deleting, and creating Shadow Traffic rules for services.

Routing rules list

The routing rules created will be listed on the tab TRAFFIC MANAGEMENT according to the corresponding service.

traffic management list
Viewing the routing rules created for a specific service

The list of routing rules created for the service includes the following information:

  • rule type (Traffic Routing or Shadow Traffic, which are identified by an icon in the TYPE column);

  • identifying name for the routing rule (column NAME);

  • rule connection type, either internal or external in the (CONNECTION TYPE column);

  • path (or URI) of the API that exposes the service — note that there may be more than one rule configured for the same service with different paths (PATH column);

  • identifying name of the service version(s) receiving traffic (DESTINATION column);

  • rule status — which can be "provisioned", "unmanaged", "disabled" or with an “error” — (STATUS column);

  • date and time when the rule was created (CREATED AT column).

The ENABLED column includes a button that allows you to disable or enable the rule.

The ACTIONS column contains two buttons that enable you to:

  • icon edit edit the rule configuration;

  • icon delete delete it.

Traffic Routing

The Traffic Routing feature allows you to route the traffic of requests to different versions of the same microservice according to a criterion.

There are two types of criteria available to define how the traffic will be routed: by Weight or by Header.

  • Traffic Routing by weight: establishes a probabilistic criterion by weight (percentage of requests) to route the traffic. For example: you can route 80% of requests to the first version of a service and the remaining 20% to a second version of the same service.

  • Traffic Routing by header: validates the presence of metadata in the request (a header) with a pre-determined name and value to route requests to the deployed versions of the service.

For these two types, it is possible to route the traffic to external connections (requests coming from outside the mesh) or internal connections (requests from other mesh services).

Creating a Traffic Routing rule by weight

If you want to create a new rule for the selected service, click the ADD NEW RULE button on the TRAFFIC MANAGEMENT tab.

A modal window to configure the rule will then open. The fields to be filled in vary according to the service connection type: external for services that are exposed externally and internal for the ones that are exposed only to other services of the mesh.

Internal services

For internal services, the fields to be filled in are the following:

  • Type: rule type (choose the Traffic Routing option).

  • Name: identifying name for the rule.

    The name must be unique to the mesh/namespace the service belongs to.

  • Port: port that exposes the service in Kubernetes.

  • Enable mTLS: checkbox that must be flagged if you want to enable connection with the mTLS security type.

  • Connection Type: may be external or internal (in this case, choose Internal).

  • Path: API path that exposes the service (optional).

  • Split by: field to specify the type of routing policy, either by percentage of requests (weight) or header validation. In this case, choose Weight.

DESTINATIONS section fields:

  • Traffic Name: identifying name for the service version.

  • Version: value of the service version.

  • Weight: choose the percentage of requests that will be forwarded to the service version informed.

The three fields indicated above are automatically replicated according to the number of versions implemented for the service.

The sum of all percentages entered in the Weight fields of the rule being configured must equal 100%.

External services

For external services (by selecting the "External" option in the Connection Type) field, besides the same fields for internal services, there is the INGRESS CONFIGURATION section, which contains the Bind to default ingress option. If this option is checked, the Istio Ingress Gateway will be used to externally expose the services present in the cluster (default).

If you want to use another ingress, the Bind to default ingress option must be unchecked. Note that in this case additional installation settings will be required.

Learn how to integrate the Ingress NGINX.
Creating a rule from the command line

To create a Traffic Routing rule by weight via kubectl, apply a .yaml file like the one in the following example:

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

The rule configuration in this file is done through the following fields:

  • .kind: specifies the type of object to be created; in this case, a TrafficRouting object;

  • .metadata.name: defines a name to identify the resource;

  • .metadata.namespace: mesh/namespace that integrates the service;

  • .spec.connectionType: rule connection type, Internal or External;

  • .spec.enabled: enables (enabled: true) or disables (enabled: false) the rule;

  • .spec.port: port that exposes the service in Kubernetes;

  • .spec.serviceName: specifies the service for which the rule will be applied;

  • .spec.traffic.name: identifying name for the traffic destination;

  • .spec.traffic.version: value of the service version to which the traffic will be routed;

  • .spec.traffic.weight: percentage of requests that will be forwarded to the service version informed.

The .yaml file in the example above sets an internal connection Traffic Routing rule for the bookinfo namespace reviews service that allocates 80% of requests to version v1 of that service, and the remaining 20% to version v2.

Creating a header-type Traffic Routing rule

The header type Traffic Routing rule uses the presence of a header with a predetermined name and value as criterion to route the requests to the configured service versions.

If you want to create a new rule for the selected service, click the ADD NEW RULE button on the TRAFFIC MANAGEMENT tab.

A modal window to configure the rule will then open. The fields to be filled in vary according to the service connection type: external for services that are exposed externally and internal for the ones that are exposed only to other services of the mesh.

Internal services

For internal services, the fields to be filled in are the following:

  • Type: rule type (choose the Traffic Routing type).

  • Name: identifying name for the rule.

    The name must be unique to the mesh/namespace the service belongs to.

  • Port: port that exposes the service in Kubernetes.

  • Enable mTLS: checkbox that must be flagged if you want to enable connection with the mTLS security type.

  • Connection Type: may be external or internal (in this case, choose Internal).

  • Path: API path that exposes the service (optional).

  • Split by: field to specify the type of routing policy, either by percentage of requests (weight) or header validation. In this case, choose Header.

DESTINATION section fields:

  • Traffic Name: identifying name of the service version (which can be the same as the Version field or more descriptive).

  • Version: value of the service version.

  • Header: insert the header name that will be validated to forward the requests.

  • Value: insert the header value that will be validated to forward the requests.

If you want, it’s possible to add more than one header to a destination. In this case, all headers inserted must be contained in a request for it to be routed to the informed version. To include an additional header, click on the + icon next to the field Value.

It’s also possible to add other destinations to the same header-type Traffic Routing. To do so, click the + ADD DESTINATION button. You can add as many headers as you wish to the new destination.

External services

For external services (by selecting the "External" option in the Connection Type) field, besides the same fields for internal services, there is the INGRESS CONFIGURATION section, which contains the Bind to default ingress option. If this option is checked, the Istio Ingress Gateway will be used to externally expose the services present in the cluster (default).

If you want to use another ingress, the Bind to default ingress option must be unchecked. Note that in this case additional installation settings will be required.

Learn how to integrate the Ingress NGINX.

As with internal services, you can add multiple destinations for the same Traffic Routing, as well as include more than one header per destination.

Creating a rule from the command line

To create a header-type Traffic Routing rule via kubectl, apply a .yaml file like the one in the following example:

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

The rule configuration in this file is done through the following fields:

  • .kind: specifies the type of object to be created; in this case, a TrafficRouting object;

  • .metadata.name: defines a name to identify the resource;

  • .metadata.namespace: mesh/namespace that integrates the service;

  • .spec.connectionType: rule connection type, Internal or External;

  • .spec.enabled: enables (enabled: true) or disables (enabled: false) the rule;

  • .spec.port: port that exposes the service in Kubernetes;

  • .spec.serviceName: specifies the service for which the rule will be applied;

  • .spec.traffic.name: identifying name for the traffic destination;

  • .spec.traffic.version: value of the service version to which the traffic will be routed;

  • .spec.traffic.headers: insert the header (exact) name and value that will be validated to forward the requests.

Shadow Traffic

Traffic shadowing is a version deployment strategy that causes no impact to the traffic a service receives. When implemented, a new service version is set to receive a portion of requests that have already been treated by the old service version, without having to respond to these requests.

You can only create a Shadow Traffic rule if there is a Traffic Routing by weight set to receive 100% of requests.

The configuration of this type of routing policy is the same regardless of the service being exposed to external traffic or not. These are the fields:

  • Type: rule type (choose the Shadow Traffic type).

  • Name: identifying name for the rule.

    The name must be unique to the mesh/namespace the service belongs to.

  • Port: port that exposes the service in Kubernetes.

Mirror traffic to section fields:

  • Traffic Name: identifying name for the service version that will receive part of the requests, without sending the responses. It can be the same as the Version field below or more descriptive.

  • Version: value of the service version.

  • Mirroring: percentage of requests to be mirrored to the indicated version.

Creating a rule from the command line

To create a Shadow Traffic rule via kubectl, apply a .yaml file like the one in the following example:

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

The rule configuration in this file is done through the following fields:

  • .kind: specifies the type of object to be created; in this case, a ShadowTraffic object type;

  • .metadata.name: defines a name to identify the resource;

  • .metadata.namespace: mesh/namespace that integrates the service;

  • .spec.enabled: enables (enabled: true) or disables (enabled: false) the rule;

  • .spec.port: port that exposes the service in Kubernetes;

  • .spec.serviceName: specifies the service for which the rule will be applied;

  • .spec.mirror.name: identifying name for the traffic copy destination;

  • .spec.mirror.version: value of the service version to which the traffic copy will be sent;

  • .spec.mirror.percentage: percentage of requests to be mirrored to the indicated version. Optional field. If omitted, the value to be considered will be 100%.

Thanks for your feedback!
EDIT

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