Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Istio Service Mesh Control Plane

DZone 's Guide to

Istio Service Mesh Control Plane

A discussion of Istio's control plane components and how they're responsible for the administration and configuration of the sidecar proxies to enforce policies and collect telemetry.

· Microservices Zone ·
Free Resource

Istio is a very popular Service Mesh Framework which uses Lyft's Envoy as the sidecar proxy. A 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 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 third-party libraries to implement the required features.

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

  • Loose coupling
  • Segregation of responsibilities

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

Service to Service Communication Over a Network

In a previous post, I discussed 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 additional configuration code for third-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.

Sidecar Deployment Using Envoy Proxy

Istio Control Plane Components

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

Configuration Validation, Management, and Distribution

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

Pilot provides service discovery for the Envoy sidecars and is 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.

Sidecar Configuration and Traffic Management Capabilities

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.

Policy Enforcement and Telemetry Collection

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

Secure TLS Communication

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 and configuration of the sidecar proxies to enforce policies and collect telemetry. Please note that the Control Plane does not touch any requests/packets in the system — that is the responsibility of the Istio Data Plane.

Istio Mesh Integrated Control Plane

Additional Istio Resources for reference -

Topics:
microservices ,service mesh ,control plane ,sidecar pattern ,microservices communication

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}