5 Traffic control: Fine-grained traffic routing

 

This chapter covers

  • Traffic routing basics
  • Shifting traffic during a new release
  • Mirroring traffic to reduce the risk of a new release
  • Controlling traffic as it leaves a cluster

In the previous chapter, we saw how to get traffic into a cluster and what considerations we needed to account for when doing so. Once a request makes it into our cluster, how is it routed to the appropriate service to handle the request? How do services that live within the cluster communicate with other services that live within the same cluster or outside the cluster? Finally, and most importantly, when we make changes to a service and introduce new versions, how do we safely expose our clients and customers to these changes with minimal disruption and impact?

As we’ve seen, Istio service proxies intercept the communication between services within the service-mesh cluster and give us a point of control for traffic. Istio allows us to finely control traffic flowing between applications down to the individual request. In this chapter, we look at why you might want to do that, how to do it, and what benefits you should achieve when utilizing these capabilities.

5.1 Reducing the risk of deploying new code

5.1.1 Deployment vs. release

5.2 Routing requests with Istio

5.2.1 Cleaning up our workspace

5.2.2 Deploying v1 of the catalog service

5.2.3 Deploying v2 of the catalog service

5.2.4 Routing all traffic to v1 of the catalog service

5.2.5 Routing specific requests to v2

5.2.6 Routing deep within a call graph

5.3 Traffic shifting

5.3.1 Canary releasing with Flagger

5.4 Reducing risk even further: Traffic mirroring

5.5 Routing to services outside your cluster by using Istio’s service discovery

Summary

sitemap