This chapter covers:
- Traffic routing basics
- Traffic shifting when doing a new release
- Mirroring traffic to reduce the risk of a new release
- Controlling traffic leaving 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 does it get 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 sometimes that live outside the cluster? Lastly, 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 broker the communication between services within the service mesh cluster and gives 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’ll take a look at why you might want to do that, how to do it, and what benefits you should achieve when utilizing these capabilities.