mirror of https://github.com/istio/istio.io.git
76 lines
3.4 KiB
Markdown
76 lines
3.4 KiB
Markdown
---
|
|
title: Request Routing
|
|
description: Describes how requests are routed between services in an Istio service mesh.
|
|
weight: 20
|
|
---
|
|
|
|
This page describes how requests are routed between services in an Istio service mesh.
|
|
|
|
## Service model and service versions
|
|
|
|
As described in [Pilot](/docs/concepts/traffic-management/pilot/), the canonical representation
|
|
of services in a particular mesh is maintained by Pilot. The Istio
|
|
model of a service is independent of how it is represented in the underlying
|
|
platform (Kubernetes, Mesos, Cloud Foundry,
|
|
etc.). Platform-specific adapters are responsible for populating the
|
|
internal model representation with various fields from the metadata found
|
|
in the platform.
|
|
|
|
Istio introduces the concept of a service version, which is a finer-grained
|
|
way to subdivide service instances by versions (`v1`, `v2`) or environment
|
|
(`staging`, `prod`). These variants are not necessarily different API
|
|
versions: they could be iterative changes to the same service, deployed in
|
|
different environments (prod, staging, dev, etc.). Common scenarios where
|
|
this is used include A/B testing or canary rollouts. Istio's [traffic
|
|
routing rules](/docs/concepts/traffic-management/rules-configuration/) can refer to service versions to provide
|
|
additional control over traffic between services.
|
|
|
|
## Communication between services
|
|
|
|
{{< image width="60%" ratio="100.42%"
|
|
link="../img/pilot/ServiceModel_Versions.svg"
|
|
alt="Showing how service versions are handled."
|
|
caption="Service Versions"
|
|
>}}
|
|
|
|
As illustrated in the figure above, clients of a service have no knowledge
|
|
of different versions of the service. They can continue to access the
|
|
services using the hostname/IP address of the service. The Envoy sidecar/proxy
|
|
intercepts and forwards all requests/responses between the client and the
|
|
service.
|
|
|
|
Envoy determines its actual choice of service version dynamically
|
|
based on the routing rules specified by the operator using Pilot. This
|
|
model enables the application code to decouple itself from the evolution of its dependent
|
|
services, while providing other benefits as well (see
|
|
[Mixer](/docs/concepts/policies-and-telemetry/overview/)). Routing
|
|
rules allow Envoy to select a version based
|
|
on criteria such as headers, tags associated with
|
|
source/destination, and/or by weights assigned to each version.
|
|
|
|
Istio also provides load balancing for traffic to multiple instances of
|
|
the same service version. You can find out more about this in [Discovery
|
|
and Load-Balancing](/docs/concepts/traffic-management/load-balancing/).
|
|
|
|
Istio does not provide a DNS. Applications can try to resolve the
|
|
FQDN using the DNS service present in the underlying platform (kube-dns,
|
|
mesos-dns, etc.).
|
|
|
|
## Ingress and egress
|
|
|
|
Istio assumes that all traffic entering and leaving the service mesh
|
|
transits through Envoy proxies. By deploying the Envoy proxy in front of
|
|
services, operators can conduct A/B testing, deploy canary services,
|
|
etc. for user-facing services. Similarly, by routing traffic to external
|
|
web services (for instance, accessing the Maps API, or a video service API)
|
|
via the sidecar Envoy, operators can add failure recovery features such as
|
|
timeouts, retries, circuit breakers, etc., and obtain detailed metrics on
|
|
the connections to these services.
|
|
|
|
{{< image width="60%" ratio="28.88%"
|
|
link="../img/pilot/ServiceModel_RequestFlow.svg"
|
|
alt="Ingress and Egress through Envoy."
|
|
caption="Request Flow"
|
|
>}}
|
|
|