Architecture

An Istio service mesh is logically split into a data plane and a controlplane.

• The data plane is composed of a set of intelligent proxies(Envoy) deployed as sidecars. These proxiesmediate and control all network communication between microservices alongwith Mixer, a general-purposepolicy and telemetry hub.

• The control plane manages and configures the proxies to route traffic.Additionally, the control plane configures Mixers to enforce policies andcollect telemetry.

The following diagram shows the different components that make up each plane:

Istio Architecture

Traffic in Istio is categorized as data plane traffic and control plane traffic.Data plane traffic refers to the messages that the business logic of the workloadssend and receive. Control plane traffic refers to configuration and control messages sentbetween Istio components to program the behavior of the mesh. Traffic managementin Istio refers exclusively to data plane traffic.

Components

The following sections provide a brief overview of each of Istio’s core components.

Envoy

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

Envoy proxies are deployed as sidecars to services, logicallyaugmenting 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 asattributes.Istio can, in turn, use these attributes in Mixerto enforce policy decisions, and send them to monitoring systems to provideinformation about the behavior of the entire mesh.

The sidecar proxy model also allows you to add Istio capabilities to anexisting deployment with no need to rearchitect or rewrite code. You can readmore about why we chose this approach in ourDesign Goals.

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

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

• Network resiliency features: setup retries, failovers, circuit breakers, andfault injection.

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

Mixer

Mixer is a platform-independentcomponent. Mixer enforces access control and usage policies across the servicemesh, and collects telemetry data from the Envoy proxy and other services. Theproxy extracts request levelattributes, and sends themto Mixer for evaluation. You can find more information on this attributeextraction and policy evaluation in our Mixer Configurationdocumentation.

Mixer includes a flexible plugin model. This model enables Istio to interfacewith a variety of host environments and infrastructure backends. Thus, Istioabstracts the Envoy proxy and Istio-managed services from these details.

Pilot

Pilot providesservice discovery for the Envoy sidecars, traffic management capabilitiesfor 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 intoEnvoy-specific configurations, and propagates them to the sidecars at runtime.Pilot abstracts platform-specific service discovery mechanisms and synthesizesthem into a standard format that any sidecar conforming with theEnvoy API can consume.

The following diagram shows how the platform adapters and Envoy proxiesinteract.

Service discovery

• The platform starts a new instance of a service which notifies its platformadapter.

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

• Pilot distributes traffic rules and configurations to the Envoy proxiesto 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 trafficmanagement.

You can use Istio’sTraffic Management APIto instruct Pilot to refine the Envoy configuration to exercise more granular controlover the traffic in your service mesh.

Citadel

Citadel enables strong service-to-service andend-user authentication with built-in identity and credential management. Youcan use Citadel to upgrade unencrypted traffic in the service mesh. UsingCitadel, operators can enforce policies based on service identity rather thanon relatively unstable layer 3 or layer 4 network identifiers. Starting fromrelease 0.5, you can use Istio’s authorization featureto control who can access your services.

Galley

Galley is Istio’s configuration validation, ingestion, processing anddistribution component. It is responsible for insulatingthe rest of the Istio components from the details of obtaining userconfiguration from the underlying platform (e.g. Kubernetes).

Design goals

A few key design goals informed Istio’s architecture. These goals are essentialto making the system capable of dealing with services at scale and with highperformance.

• Maximize Transparency: To adopt Istio, an operator or developer isrequired to do the minimum amount of work possible to get real value from thesystem. To this end, Istio can automatically inject itself into all thenetwork paths between services. Istio uses sidecar proxies to capture trafficand, where possible, automatically program the networking layer to routetraffic through those proxies without any changes to the deployed applicationcode. In Kubernetes, the proxies are injected into pods and traffic iscaptured by programming iptables rules. Once the sidecar proxies areinjected and traffic routing is programmed, Istio can mediate all traffic.This principle also applies to performance. When applying Istio to adeployment, operators see a minimal increase in resource costs for thefunctionality being provided. Components and APIs must all be designed withperformance and scale in mind.

• Extensibility: As operators and developers become more dependent on thefunctionality that Istio provides, the system must grow with their needs.While we continue to add new features, the greatest need is the ability toextend the policy system, to integrate with other sources of policy andcontrol, and to propagate signals about mesh behavior to other systems foranalysis. The policy runtime supports a standard extension mechanism forplugging in other services. In addition, it allows for the extension of itsvocabulary to allow policies to be enforced based on new signals that themesh produces.

• Portability: The ecosystem in which Istio is used varies along manydimensions. Istio must run on any cloud or on-premises environment withminimal effort. The task of porting Istio-based services to new environmentsmust be trivial. Using Istio, you are able to operate a single servicedeployed into multiple environments. For example, you can deploy on multipleclouds for redundancy.

• Policy Uniformity: The application of policy to API calls betweenservices provides a great deal of control over mesh behavior. However, it canbe equally important to apply policies to resources which are not necessarilyexpressed at the API level. For example, applying a quota to the amount ofCPU consumed by an ML training task is more useful than applying a quota tothe call which initiated the work. To this end, Istio maintains the policysystem as a distinct service with its own API rather than the policy systembeing baked into the proxy sidecar, allowing services to directly integratewith it as needed.