Istio Service Mesh Control Plane

Istio is a very popular Service Mesh Framework which uses Lyft’s Envoy as the sidecar proxy. Sidecar application is deployed alongside each service instance and provides an interface to handle functionalities like service discovery, load balancing, traffic management, inter-service communication, monitoring etc. Service Mesh gives you the freedom of not having to worry about the service to service communication as part of your application code. Instead of bloating your microservice with similar functionalities, you can let the Service Mesh handle that complexity for you.

The Istio Service Mesh is comprised of a Data Plane and a Control Plane. In this article, we will understand the various components which make up the Istio Control Plane and its functionality.

Why Service Mesh?
Service Mesh encapsulates all the complexities related to the infrastructure away from the services, by implementing an interface. Your application code becomes lightweight and less complicated since you no longer need to embed multiple 3rd party libraries to implement the required features.

Extending the functionality of the current services by injecting a sidecar alongside your application provides 2 primary advantages —

  • Loose coupling
  • Segregation of responsibilities

Check out my earlier blog posts to learn more about the Sidecar Design Pattern and its benefits —

Sidecar Design Pattern in your Microservices Ecosystem
Simplifying Microservice Architecture with Envoy and Istio

Service to Service Communication

In my previous post, I discussed about the fallacies of Distributed Computing and how service calls made over the network are not reliable and might fail —

Eight Fallacies of Distributed Computing

Segregating the functionalities of an application into a separate process can be viewed as a Sidecar pattern. The Sidecar design pattern allows you to add a number of capabilities to your application without the need of additional configuration code for 3rd party components. It shifts the complexity associated with the Microservice architecture to a separate infrastructure layer and provides a lot of functionalities like Load Balancing, Service Discovery, Traffic Management, Circuit Breaking, Telemetry, Fault Injection and more.

Istio Sidecar Proxy

Istio Control Plane Components

The primary responsibility of Galley is centralized configuration management and distribution. Galley insulates rest of the Istio components from the underlying platform like Kubernetes. Galley ingests the user supplied configuration and validates it before distributing across pods.

Istio Galley

Pilot configures all the Envoy proxy instances deployed in the Istio service mesh.

Pilot provides service discovery for the Envoy sidecars.
Pilot is also the core component used for traffic management Canary, Dark etc in Istio.

Pilot fetches the configuration from Galley and lets you specify which rules you want to use to route traffic between Envoy proxies and configure failure recovery features such as timeouts, retries, and circuit breakers. As a result, it helps to keep the configuration in sync between the underlying platform and Istio Data Plane.

Istio Pilot

Mixer is the Istio component responsible for Policy Enforcement and Telemetry Collection.

The Envoy sidecar proxy logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry. The sidecar has local caching such that a large percentage of precondition checks can be performed from the cache. Additionally, the sidecar buffers outgoing telemetry such that it only actually needs to call Mixer once for every several thousand requests. Whereas precondition checks are synchronous to request processing, telemetry reports are done asynchronously with a fire-and-forget pattern.

Envoy gets a request and asks Mixer if it should allow the request. This is where you can plug in functionalities like Rate Limiting, Authentication and more. Mixer also sends these metrics to Prometheus.

Istio Mixer

Citadel provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and credential management.

Istio Citadel

To summarize, in this article 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. Please note that the Control Plane does not touch any requests in the system – that is the responsibility of the Istio Data Plane.

Istio Integrated Control Plane

Additional Istio Resources for reference —

Istio: Up and Running

Istio Service Mesh Day 2019

Istio Architecture


Categories: Architecture, Istio, Microservices, Service Mesh

3 replies


  1. Istio Service Mesh Data Plane – dotnetvibes
  2. Microservices Journey from Netflix OSS to Istio Service Mesh – dotnetvibes
  3. Speaking at O’Reilly Software Architecture Conference 2019 – dotnetvibes

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: