Istio Service Mesh Data Plane

By Samir Behara on May 28, 2019 • ( 2 )

As enterprises transition from Monolithic to a Microservice architecture, they have found it difficult to manage the service to service communication and handle functionalities such as security, traffic control, resiliency, monitoring, metrics, and logging. More requirements like A/B testing, canary releases, rate limiting, policy enforcement, access control, and end-to-end authentication become another burden. Istio solves such complex requirements while not requiring changes to application code.

A service mesh allows applications to offload these capabilities from application-level libraries to a separate infrastructure layer and allow developers to focus on the business logic itself. Istio is one of the best implementations of a service mesh.

In my last blog, we looked at Istio Control Plane components – Galley, Pilot, Mixer and Citadel. We also discussed the responsibilities of the Istio Control Plane which is primarily the administration & configuration of the Sidecar Proxies to enforce policies and collect telemetry —

Istio Service Mesh Control Plane

In this blog post, I will explain the Istio Service Mesh Data Plane and its functionalities.

Istio Architecture

Inside a service mesh, we have the concept of a Data Plane and Control Plane —

The Control Plane responsibility is to manage and configure the sidecar proxies to enforce policies and collect telemetry.
The Data Plane responsibility is to handle the communication between the services and take care of the functionalities like Service Discovery, Load Balancing, Traffic Management, Health Check etc.

Istio Data Plane

The Istio Data Plane is primarily comprised of the Envoy proxies which are attached as dedicated sidecars to each application instance.
Istio Data Plane intercepts all incoming(Ingress) and outgoing(Egress) network traffic. This provides you the ability to apply all these required functionalities mentioned below at this separate infrastructure layer, without polluting the application code.

The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. Primary Responsibilities of the Sidecar Proxy —
Service Discovery, Load Balancing, Authentication & Authorization, Request Tracing, Traffic Management, Fault Injection, Rate Limiting, Observability

The diagram above shows how Envoy as a Sidecar Container makes the Service lightweight and compact, in the process handling all the service to service communication.

Each pod inside the service mesh must be running an Istio compatible sidecar. You can inject Istio sidecar into a pod manually using the istioctl CLI tool or automatically using the Istio sidecar injector.

Benefits of Sidecar implementation

Separation of configuration code and Business functionalities ensures loose coupling and clear segregation of responsibilities.
The configuration code is handled by a dedicated infrastructure layer and not diluted into the application code.
Envoy proxies provide a standardized implementation of functionalities in a Polyglot landscape.
No application-level code changes are required to implement the service to service communication inside the service mesh.

To summarize this blog post, here are the primary differences between the Istio Data Plane and Istio Control Plane —

The Data Plane touches every request in the system whereas the Control Plane does not.
The Data Plane is responsible for service discovery, load balancing, traffic management, authentication, observability whereas the Control Plane configures the sidecar proxies to enforce policies and collect telemetry.

Additional Istio Resources for reference —

Introducing Istio Service Mesh for Microservices
Service mesh data plane vs. control plane