Request Routing

This task shows you how to route requests dynamically to multiple versions of amicroservice.

Before you begin

  • Setup Istio by following the instructions in theInstallation guide.

  • Deploy the Bookinfo sample application.

  • Review the Traffic Management concepts doc. Before attempting this task, you should be familiar with important terms such as destination rule, virtual service, and subset.

About this task

The Istio Bookinfo sample consists of four separate microservices, each with multiple versions.Three different versions of one of the microservices, reviews, have been deployed and are running concurrently.To illustrate the problem this causes, access the Bookinfo app’s /productpage in a browser and refresh several times.You’ll notice that sometimes the book review output contains star ratings and other times it does not.This is because without an explicit default service version to route to, Istio routes requests to all available versionsin a round robin fashion.

The initial goal of this task is to apply rules that route all traffic to v1 (version 1) of the microservices. Later, youwill apply a rule to route traffic based on the value of an HTTP request header.

Apply a virtual service

To route to one version only, you apply virtual services that set the default version for the microservices.In this case, the virtual services will route all traffic to v1 of each microservice.

If you haven’t already applied destination rules, follow the instructions in Apply Default Destination Rules.

  • Run the following command to apply the virtual services:

Zip

  1. $ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@

Because configuration propagation is eventually consistent, wait a few secondsfor the virtual services to take effect.

  • Display the defined routes with the following command:
  1. $ kubectl get virtualservices -o yaml
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5.   name: details
  6.   ...
  7. spec:
  8.   hosts:
  9.   - details
  10.   http:
  11.   - route:
  12.     - destination:
  13.         host: details
  14.         subset: v1
  15. ---
  16. apiVersion: networking.istio.io/v1alpha3
  17. kind: VirtualService
  18. metadata:
  19.   name: productpage
  20.   ...
  21. spec:
  22.   gateways:
  23.   - bookinfo-gateway
  24.   - mesh
  25.   hosts:
  26.   - productpage
  27.   http:
  28.   - route:
  29.     - destination:
  30.         host: productpage
  31.         subset: v1
  32. ---
  33. apiVersion: networking.istio.io/v1alpha3
  34. kind: VirtualService
  35. metadata:
  36.   name: ratings
  37.   ...
  38. spec:
  39.   hosts:
  40.   - ratings
  41.   http:
  42.   - route:
  43.     - destination:
  44.         host: ratings
  45.         subset: v1
  46. ---
  47. apiVersion: networking.istio.io/v1alpha3
  48. kind: VirtualService
  49. metadata:
  50.   name: reviews
  51.   ...
  52. spec:
  53.   hosts:
  54.   - reviews
  55.   http:
  56.   - route:
  57.     - destination:
  58.         host: reviews
  59.         subset: v1
  60. ---
  • You can also display the corresponding subset definitions with the following command:
  1. $ kubectl get destinationrules -o yaml

You have configured Istio to route to the v1 version of the Bookinfo microservices,most importantly the reviews service version 1.

Test the new routing configuration

You can easily test the new configuration by once again refreshing the /productpageof the Bookinfo app.

Notice that the reviews part of the page displays with no rating stars, nomatter how many times you refresh. This is because you configured Istio to routeall traffic for the reviews service to the version reviews:v1 and thisversion of the service does not access the star ratings service.

You have successfully accomplished the first part of this task: route traffic to oneversion of a service.

Route based on user identity

Next, you will change the route configuration so that all traffic from a specific useris routed to a specific service version. In this case, all traffic from a usernamed Jason will be routed to the service reviews:v2.

Note that Istio doesn’t have any special, built-in understanding of useridentity. This example is enabled by the fact that the productpage serviceadds a custom end-user header to all outbound HTTP requests to the reviewsservice.

Remember, reviews:v2 is the version that includes the star ratings feature.

  • Run the following command to enable user-based routing:

Zip

  1. $ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
  • Confirm the rule is created:
  1. $ kubectl get virtualservice reviews -o yaml
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5.   name: reviews
  6.   ...
  7. spec:
  8.   hosts:
  9.   - reviews
  10.   http:
  11.   - match:
  12.     - headers:
  13.         end-user:
  14.           exact: jason
  15.     route:
  16.     - destination:
  17.         host: reviews
  18.         subset: v2
  19.   - route:
  20.     - destination:
  21.         host: reviews
  22.         subset: v1
  • On the /productpage of the Bookinfo app, log in as user jason.

Refresh the browser. What do you see? The star ratings appear next to eachreview.

  • Log in as another user (pick any name you wish).

Refresh the browser. Now the stars are gone. This is because traffic is routedto reviews:v1 for all users except Jason.

You have successfully configured Istio to route traffic based on user identity.

Understanding what happened

In this task, you used Istio to send 100% of the traffic to the v1 versionof each of the Bookinfo services. You then set a rule to selectively send trafficto version v2 of the reviews service based on a custom end-user header addedto the request by the productpage service.

Note that Kubernetes services, like the Bookinfo ones used in this task, mustadhere to certain restrictions to take advantage of Istio’s L7 routing features.Refer to the Requirements for Pods and Services for details.

In the traffic shifting task, youwill follow the same basic pattern you learned here to configure route rules togradually send traffic from one version of a service to another.

Cleanup

  • Remove the application virtual services:

Zip

  1. $ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
  • If you are not planning to explore any follow-on tasks, refer to theBookinfo cleanup instructionsto shutdown the application.

See also

Istio as a Proxy for External Services

Configure Istio ingress gateway to act as a proxy for external services.

Multi-Mesh Deployments for Isolation and Boundary Protection

Deploy environments that require isolation into separate meshes and enable inter-mesh communication by mesh federation.

Secure Control of Egress Traffic in Istio, part 3

Comparison of alternative solutions to control egress traffic including performance considerations.

Secure Control of Egress Traffic in Istio, part 2

Use Istio Egress Traffic Control to prevent attacks involving egress traffic.

Secure Control of Egress Traffic in Istio, part 1

Attacks involving egress traffic and requirements for egress traffic control.

Version Routing in a Multicluster Service Mesh

Configuring Istio route rules in a multicluster service mesh.