Introducing Istio Ambient Mesh, contributed by Solo.io & Google. READ THE BLOG

Exit Icon

Istio Architecture

4 Key Components, Multi-Cluster and More

What is Istio?

Istio is an open source service mesh solution that enables developers to connect, control, monitor, and secure microservices architectures. It works with any microservice regardless of its platform, source or vendor, providing a unified layer between application services and the network.

Google, IBM and Lyft originally introduced Istio in May 2017 and in April 2022, Google submitted an application proposal for Istio to join the CNCF, the home of its companion projects Kubernetes and Envoy.

Istio is designed to provide observability, robust communication and control even as the number of microservices in an application increases. Instead of solving distributed system problems by changing application code or by building language-specific client libraries, developers can use Istio as a platform-agnostic middleware. 

A unique feature of Istio is that it supports workloads running in both containers and virtual machines, and can manage the interactions between them, providing support for hybrid environments.

Istio Architecture and Components

The Istio service mesh is divided into a data plane and a control plane:

  • The data plane consists of a set of intelligent proxies (based on the Envoy open source project), deployed as sidecars alongside the application. 
  • The control plane manages and configures proxies to route traffic.

Image Source: Istio

1. Istio Data Plane

The data plane consists of Envoy proxies deployed as sidecars, running alongside application instances in Kubernetes pods. The Envoy proxies manage traffic for services on the system, including managing and controlling network communication between microservices.

By deploying Envoy as a sidecar, Istio lets developers implement proxies in their application with no code changes. The Envoy proxy controls traffic by listing routing rules (supporting HTTP, gRPC, and TCP) and applying transport layer security (TLS) and traffic encryption policies.

All application traffic flows through these Envoy proxies, which collect large amounts of data and can provide valuable insights about traffic, supporting observability.

2. Istio Control Plane

The Istio control plane is built of three key components:

  • Pilot—uses the Envoy API to communicate with the Envoy sidecar. The pilot is responsible for traffic management, routing, and service inspection.
  • Citadel—provides secure communication between services by managing user authentication, certificate and credential management.
  • Galley—responsible for configuration management, distribution, and processing.

Learn more in our blog The Operational Overhead of Istio’s External Control Plane

3. Envoy

Istio employs Envoy, a high-performance proxy that mediates inbound and outbound traffic for services in a service mesh. It allows only envoy proxies to interact with data plane traffic. Istio deploys Envoy proxies as sidecar containers, running alongside services in the same pod. This logically augments services with Envoy’s built-in features, including:

  • Load balancing
  • Dynamic service discovery
  • TLS termination
  • Circuit breakers
  • HTTP/2 and gRPC proxies
  • Health checks
  • Fault injection
  • Staged rollouts with %-based traffic split
  • Rich metrics

A sidecar deployment enables Istio to enforce policies and extract rich telemetry. Istio can send this data to monitoring systems for context about an entire mesh’s behavior. Additionally, this sidecar proxy model lets you add Istio capabilities to existing deployments without re-architecting or rewriting code.

Here are key Istio features and tasks Envoy proxies enable:

  • Traffic control—lets you enforce fine-grained traffic control and rich routing rules for gRPC, HTTP, WebSocket, and TCP traffic.
  • Network resiliency—features include setup retries, circuit breakers, fault injection, and failovers.
  • Security and authentication—Envoy proxies enable Istio to enforce security policies, access control, and rate limiting. You can define it using the configuration API.
  • Pluggable extensions—this model is based on WebAssembly, which enables custom policy enforcement as well as telemetry generation for your mesh traffic.

Learn more in our blog Istio Networking In Depth

4. Istiod

Istiod provides certificate management, service discovery, and configuration. It converts the high-level routing rules controlling traffic behavior into Envoy-specific configurations, propagating them to sidecars during runtime. 

Service discovery

Pilot is responsible for abstracting platform-specific service discovery mechanisms and synthesizing them into a standard format that sidecars conforming with the Envoy API can consume. 

Istio supports discovery for several environments, including VMs and Kubernetes. Istio’s Traffic Management API can help instruct Istiod to refine an Envoy configuration to enforce more granular control over traffic in a service mesh.

Security

Istiod security provides built-in identity and credential management to achieve strong service-to-service and end-user authentication. Additionally, Istio can help you upgrade unencrypted traffic within a service mesh. 

Instead of enforcing policies based on relatively unstable layer three or layer four network identifiers, Istio lets you enforce policies according to service identity. You can also use Istio’s authorization functionality to control access to services.

Certificate management

Istiod functions as a certificate authority (CA), generating certificates to enable secure mTLS communication within the data plane.

Istio Cluster Models

An application’s workload instances can run in one or more Kubernetes clusters. Confining clusters to an availability zone or region provides high availability, performance, and isolation. A production system can run in a multi-cluster service mesh over different zones and regions, with cloud load balancers handling locality and regional or zonal failover.

Usually, a cluster forms the boundary for endpoint discovery and configuration, for instance, with an API server managing the configuration for each cluster discovery. Kubernetes supports this per-cluster configuration, so this approach minimizes the issues associated with misconfiguration.

Istio lets you configure a service mesh spanning multiple clusters.

Single-Cluster Mesh

The simplest Istio service mesh spans a single cluster, usually over a single network. A single-cluster, single-network deployment offers simplicity but lacks additional features like fault isolation and failover. For higher availability, use a multi-cluster mesh.


Image Source: Istio

Multi-Cluster Mesh

A single service mesh can encompass several clusters. A multi-cluster deployment provides the following benefits:

  • Fault isolation and failover—one cluster goes down and fails over to another.
  • Location-based routing and failover—send requests to geographically closest service.
  • Control plane options—different models have varying degrees of availability.
  • Isolation—each team or project can run in a dedicated cluster.


Image Source: Istio

A multi-cluster deployment provides higher availability and isolation but is also more complex. Systems requiring high availability usually require clusters in different zones or regions. You can test configuration changes in one cluster to limit the impact of each change. If there are problems with a cluster, you can reroute traffic from it while fixing it. 

You determine how clusters communicate with each other. For instance, firewall rules can control cross-cluster traffic within the same network. The services in a multi-cluster mesh are shared by default, with traffic policies providing granular control.

Istio Virtual Machine Architecture

A unique feature of Istio is that it supports both containerized workloads and those running in virtual machines (VMs). Istio’s VM support allows you to connect workloads outside of your Kubernetes cluster to a mesh. This setup enables you to use Istio for legacy applications and applications you cannot run in a containerized environment.

Kubernetes provides features that support workloads running on the platform, including service discovery, DNS resolution, and health check features that are usually not available in VM environments. Istio lets you use these features for workloads that run on VMs. It also lets these workloads utilize Istio functionality like rich telemetry, mutual TLS (mTLS), and advanced traffic management.

Single Network

A service mesh can operate over one fully-connected network. A single network model typically allows all workload instances to reach each other directly without using an Istio gateway. 

This model lets Istio configure service consumers uniformly across the mesh and directly address workload instances. The mesh includes a single network that allows pods and VMs to communicate directly.

The model sends control plane traffic, including certificate signing and XDS configuration, through a gateway inside the cluster. This setup ensures VMs can connect to a stable address when bootstrapping. Pods and VMs do not need an intermediate Gateway and can communicate directly.


Image Source: Istio

Multi Network

A multi-network consists of a single service mesh spanning multiple networks. Multiple networks have all the capabilities of a single network and additional functionality, including:

  • Crossing administrative boundaries.
  • Overlapping VIP or IP ranges for service endpoints.
  • Fault tolerance.
  • Compliance with standards requiring network segmentation.
  • Scaling network addresses.

This model places workload instances across different networks, allowing them to reach each other only through one or several Istio gateways. Istio provides consumers a different view of service endpoints by utilizing partitioned service discovery. This mesh includes multiple networks that do not allow pods and VMs to communicate directly.

The model sends control plane traffic, including certificate signing and XDS configuration, through a gateway within the cluster. It also sends all communication between VMs and pods through the gateway, which works as a bridge between the networks.

Image Source: Istio

The Need for an Istio Management Plane

While Istio has had many years to mature and continues to develop many new innovations with releases on a quarterly cadence, many organizations look to enhance Istio with a management plane to simplify the configuration of Istio and also get access to enhanced multi-cluster capabilities, advanced/federated security with FIPS-ready builds, software lifecycle management, backported CVEs and everything else you need for successful Day 2 operations. For a complete list of what the Gloo Mesh service mesh management plane adds to open source Istio, download this comparison sheet.

BACK TO TOP
Test drive Gloo Mesh Enterprise Istio today
REQUEST A TRIAL
Enterprise support for Istio in production
REQUEST SUPPORT
Get hands-on, developer-focused training
VISIT SOLO ACADEMY