Skip to content

Introduction

Image

Istio is a completely open source service mesh that layers transparently onto existing distributed applications. It’s also a platform, including APIs, that let it integrate into any logging platform, or telemetry or policy system.

Istio works by having a small network proxy sit alongside each microservice called “sidecar”. It’s role is to intercept all of the service’s traffic, and handles it more intelligently than a simple layer 3 network can. Envoy proxy is used as the sidecar and was originally written at Lyft and is now a CNCF project.

Let’s review in more detail what each of the components that make up this service mesh are.

Envoy

Istio uses an extended version of the Envoy proxy. Envoy is a high-performance proxy developed in C++ to mediate all inbound and outbound traffic for all services in the service mesh. Envoy proxies are the only Istio components that interact with data plane traffic.

Envoy proxies are deployed as sidecars to services, logically augmenting the services with Envoy’s many built-in features, for example:

  • Dynamic service discovery
  • Load balancing
  • TLS termination
  • HTTP/2 and gRPC proxies
  • Circuit breakers
  • Health checks
  • Staged rollouts with %-based traffic split
  • Fault injection
  • Rich metrics
  • This sidecar deployment allows Istio to extract a wealth of signals about traffic behavior as attributes. Istio can use these attributes to enforce policy decisions, and send them to monitoring systems to provide information about the behavior of the entire mesh.

The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code. You can read more about why we chose this approach in our Design Goals.

Some of the Istio features and tasks enabled by Envoy proxies include:

  • Traffic control features: enforce fine-grained traffic control with rich routing rules for HTTP, gRPC, WebSocket, and TCP traffic.*

  • Network resiliency features: setup retries, failovers, circuit breakers, and fault injection.*

  • Security and authentication features: enforce security policies and enforce access control and rate limiting defined through the configuration API.*

  • Pluggable extensions model based on WebAssembly that allows for custom policy enforcement and telemetry generation for mesh traffic.

Pilot

Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary rollouts, etc.), and resiliency (timeouts, retries, circuit breakers, etc.).

Pilot converts high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime. Pilot abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that any sidecar conforming with the Envoy API can consume.

The following diagram shows how the platform adapters and Envoy proxies interact.

Image

  1. The platform starts a new instance of a service which notifies its platform adapter.

  2. The platform adapter registers the instance with the Pilot abstract model.

  3. Pilot distributes traffic rules and configurations to the Envoy proxies to account for the change.

This loose coupling allows Istio to run on multiple environments such as Kubernetes, Consul, or Nomad, while maintaining the same operator interface for traffic management.

You can use Istio’s Traffic Management API to instruct Pilot to refine the Envoy configuration to exercise more granular control over the traffic in your service mesh.

Mixer

  • Mixer enforces access control and usage policies across the service mesh, and collects telemetry data from the Envoy proxy and other services.

Citadel

  • Citadel provides strong service-to-service and end-user authentication with built-in identity and credential management.

Galley

  • Galley is Istio’s configuration validation, ingestion, processing and distribution component. It is responsible for insulating the rest of the Istio components from the details of obtaining user configuration from the underlying platform (e.g. Kubernetes).