Chapter 3. Traffic Control
As we’ve seen in previous chapters, Istio consists of a control plane and a data plane. The data plane is made up of proxies that live in the application architecture. We’ve been looking at a proxy-deployment pattern known as the sidecar, which means each application instance has its own dedicated proxy through which all network traffic travels before it gets to the application. These sidecar proxies can be individually configured to route, filter, and augment network traffic as needed. In this chapter, we take a look at a handful of traffic-control patterns that you can take advantage of via Istio. You might recognize these patterns as some of those practiced by the big internet companies like Netflix, Amazon, or Facebook.
The concept of the canary deployment has become fairly popular in the last few years. The name “canary deployment” comes from the “canary in the coal mine” concept. Miners used to take a canary in a cage into the mines to detect whether there were any dangerous gases present because the canaries are more susceptible to poisonous gases than humans. The canary would not only provide nice musical songs to entertain the miners, but if at any point it collapsed off its perch, the miners knew to get out of the coal mine rapidly.
The canary deployment has similar semantics. With a canary deployment, you deploy a new version of your code to production, but you allow only a subset of traffic to reach it. Perhaps only beta ...
Get Introducing Istio Service Mesh for Microservices now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.