---
title: Request Routing
weight: 50
---
:icons: font
:sectlinks:
:linkattrs:

The Travel Demo application has several portals deployed on the *travel-portal* namespace consuming the *travels* service deployed on the *travel-agency* namespace.

The *travels* service is backed by a single workload called *travels-v1* that receives requests from all portal workloads.

At a moment of the lifecycle the business needs of the portals may differ and new versions of the *travels* service may be necessary.

This step will show how to route requests dynamically to multiple versions of the *travels* service.

NOTE: *Step 1:* Deploy *travels-v2* and *travels-v3* workloads

To deploy the new versions of the *travels* service execute the following commands:

[source,bash]
----
kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travels-v2.yaml) -n travel-agency
kubectl apply -f <(curl -L https://raw.githubusercontent.com/kiali/demos/master/travels/travels-v3.yaml) -n travel-agency
----

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-travels-v2-v3.png" title="Travels-v2 and travels-v3">
    <img src="/images/tutorial/05-01-travels-v2-v3.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
As there is no specific routing defined, when there are multiple workloads for *travels* service the requests are uniformly distributed.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-travels-before-routing.png" title="Travels graph before routing">
    <img src="/images/tutorial/05-01-travels-before-routing.png" style="display:block;margin: 0 auto;" />
</a>
++++

NOTE: *Step 2:* Investigate the http headers used by the Travels Demo application

The https://istio.io/latest/docs/concepts/traffic-management/#routing-rules[Traffic Management, window="_blank"] features of Istio allow you to define https://istio.io/latest/docs/concepts/traffic-management/#match-condition[Matching Conditions, window="_blank"] for dynamic request routing.

In our scenario we would like to perform the following routing logic:

- All traffic from *travels.uk* routed to *travels-v1*
- All traffic from *viaggi.it* routed to *travels-v2*
- All traffic from *voyages.fr* routed to *travels-v3*

Portal workloads use HTTP/1.1 protocols to call the *travels* service, so one strategy could be to use the HTTP headers to define the matching condition.

But, where to find the HTTP headers ? That information typically belongs to the application domain and we should examine the code, documentation or dynamically trace a request to understand which headers are being used in this context.

There are multiple possibilities. The Travel Demo application uses an https://istio.io/latest/docs/reference/config/annotations/[Istio Annotation, window="_blank"] feature to add an annotation into the Deployment descriptor, which adds additional Istio configuration into the proxy.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-deployment-istio-config.png" title="Istio Config annotations">
    <img src="/images/tutorial/05-01-deployment-istio-config.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
In our example the https://github.com/kiali/demos/blob/master/travels/travels-v2.yaml#L15[HTTP Headers, window="_blank"] are added as part of the trace context.

Then tracing will populate custom tags with the *portal*, *device*, *user* and *travel* used.

NOTE: *Step 3:* Use the Request Routing Wizard on *travels* service to generate a traffic rule

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-travels-request-routing.png" title="Travels Service Request Routing">
    <img src="/images/tutorial/05-01-travels-request-routing.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
In the first rule, we will add a "Request Matching" for *portal* header equals to *travels.uk* value.

Use "Add Match" button to update the "Matching selected" for this rule.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-add-match.png" title="Add Request Matching">
    <img src="/images/tutorial/05-01-add-match.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
Move to "Route To" tab to update the destination for this "Request Matching".

Use the "Add Rule" to create the first rule.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-route-to.png" title="Route To">
    <img src="/images/tutorial/05-01-route-to.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
Add similar rules to route traffic from *viaggi.it* to *travels-v2* workload and from *voyages.fr* to *travels-v3* workload.

When the three rules are defined you can use "Create" button to generate all Istio configurations needed for this scenario.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-rules-defined.png" title="Rules Defined">
    <img src="/images/tutorial/05-01-rules-defined.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
All the Istio config linked to a given service are also listed under the "Istio" tab in the Service Details page.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-service-istio-config.png" title="Service Istio Config">
    <img src="/images/tutorial/05-01-service-istio-config.png" style="display:block;margin: 0 auto;" />
</a>
++++

NOTE: *Step 4:* Verify that the Request Routing is working from the *travels-portal* Graph

Once the Request Routing is working we can verify that outbound traffic from every portal goes to the single *travels* workload.

If you use the "Find.../Hide..." filter, graph can hide old traffic grey edges for a clear graph.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-request-routing-graph.png" title="Travels Portal Namespace Graph">
    <img src="/images/tutorial/05-01-request-routing-graph.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
Examining the "Inbound Traffic" for any of the *travels* workloads will show a similar pattern in the telemetry.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-travels-v1-inbound-traffic.png" title="Travels v1 Inbound Traffic">
    <img src="/images/tutorial/05-01-travels-v1-inbound-traffic.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
Using a large interval we can see how the workload initially received traffic from all portals but then only a single portal after the Request Routing scenarios were defined.

NOTE: *Step 5:* Update or delete Istio Configuration

Kiali Wizards allow you to define high level Service Mesh scenarios and will generate the Istio Configuration needed for its implementation (VirtualServices, DestinationRules, Gateways and PeerRequests).

These scenarios can be updated or deleted from the "Actions" menu of a given service. The relevant Istio configuration will be modified or removed, as needed.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-01-update-or-delete.png" title="Update or Delete">
    <img src="/images/tutorial/05-01-update-or-delete.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
As part of the tutorial step, when you have finished experimenting with Routing Requests scenarios then use the *travels* service "Actions" menu to delete the generated Istio config.



