traffic management diagram (#72)

This commit is contained in:
Shriram Rajagopalan 2017-04-27 17:13:13 -04:00 committed by GitHub
parent 874424caf3
commit d6d9ec5283
3 changed files with 17 additions and 9 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 62 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 278 KiB

View File

@ -11,15 +11,19 @@ layout: docs
type: markdown
---
Unlike existing techniques implemented by popular platforms like
Kubernetes, Mesos, etc., Istio decouples traffic flow and infrastructure
scaling. While platforms allow operators to control when a particular set
of pods should receive traffic (e.g., by adding/removing specific labels),
Istio allows operators to control what percentage of traffic should be
routed to these pods or which requests (e.g., those containing specific
headers) should be routed. These capabilities are available for both
edge and mid-tier services, benefiting all development teams (not just those
working on user-facing services).
Existing container orchestration platforms like Kubernetes, and Mesos, and
other microservice frameworks allow operators to control when a particular
set of pods/VMs should receive traffic (e.g., by adding/removing specific
labels). Unlike existing techniques, Istio decouples traffic flow and infrastructure
scaling.
<img src="./img/manager/TrafficManagementOverview.svg" alt="Traffic Management with Istio." />
As illustrated in the figure above, Istio allows operators to control what
percentage of traffic should be routed to these pods or which requests
(e.g., those containing specific headers) should be routed. These
capabilities are available for both edge and mid-tier services, benefiting
all development teams (not just those working on user-facing services).
For instance, these capabilities allow operators to control the exact
percentage of traffic that each canary release should receive, irrespective