Istio Service Mesh Simplified — Introduction to Istio
Why Service Mesh?
We are moving towards the microservices architecture from the traditional monolithic architecture. When you use the monolithic architecture for your application development, you only have a single application to manage and the ecosystem is built around your application.
When moving towards microservices architecture, instead of a single application, now you have several microservices. Managing these microservices is not an easy task. You have to do the following for your microservices.
- End to end authentication
- Load balancing
- Service discovery
- Metrics and monitoring
- Rate limiting
- Canary rollouts
- Resiliency for microservices
- Access control
To address these above-mentioned aspects, service meshes are introduced. Istio is one of the service mesh orchestration platforms. There are few others in this domain as follows.
- Linkerd
- Conduit (Joined Linkerd)
- SuperGloo
- AWS App Mesh
In these service meshes, the main similarity is that they have two logical layers called data plane and the control plane. The data plane collects data from the proxies and provide those data to the control plane to take policy decision and for telemetry.
Istio
Istio is an open platform-independent service mesh. This project is developed as an open source project and this is started by teams from Google, IBM, and Envoy from Lyft. Envoy is a well-known proxy specially designed for cloud-native applications.
Istio is designed as an independent-platform where you can run on Kubernetes (K8s) and Nomad (with Consul).
Let’s look at the architecture of Istio.
Istio also has two virtual layers called control plane and data plane like other service meshes.
The Data Plane: Contains set of intelligent proxies and deployed as sidecars. An extended version of Envoy is used as the proxy in Istio and it is used to mediate and control all the network communication between microservices.
The Control Plane: Manages and configures the proxies to route traffic and enforce policies and collect telemetry from Mixer.
Istio contains five main components as below.
Envoy:
In K8s, when you deploy an application where Istio injection is enabled, the envoy proxy will be deployed in the same pod as a sidecar without any changes to the deployed application. It automatically programs the networking layer to route traffic which comes to the application via the envoy proxy. This is done by programming iptable rules in K8s.
Mixer:
The mixer does the policy check and collects telemetry data from the Envoy proxy and other services. When a request comes to the envoy, it extracts request level attributes and sends that information to the mixer to take any access control decisions. If this check request fails, then the request does not reach the microservice.
The mixer has a plugin model where you can plug adapters which allows interacting with different backends. This is an extension point where you can integrate with any other service provides.
The mixer policy check call has a direct implication of the latency of the request. Hence, from Istio 1.1.0 release onwards, the default profile which is the production recommended has not enabled the mixer policy check by default. i.e Envoy does not do the policy check for the request. But it sends the telemetrics for the mixer. If you need the policy check enforcement, you can enable it explicitly.
Pilot:
The pilot provides the configuration data to the proxies. As a result, the pilot provides service discovery for Envoy sidecars, traffic management capabilities for intelligent routing and resiliency. For example, you can deploy a policy to do the JWT token validation in service level or gateway level. When you deploy the policy, the pilot calls the JWKS endpoint and get the keys and push that signature-related information to the Envoy proxies.
Citadel:
Basic idea is that Citadel provides TLS information to the proxies which enable to do service to service and end-user authentication with built-in identity and credential management. Also with Citadel, you can upgrade the service mesh to allow unencrypted traffic.
Galley:
Galley is Istio’s configuration validation, ingestion, processing, and distribution component. It is responsible for insulating the rest of the Istio components from the details of obtaining user configuration from the underlying platform (e.g. Kubernetes).
In K8s, you have the capability to extend the K8s API by using the custom resource definitions and custom controllers. Istio has used this extension point and developed Istio for K8s. When you are deploying Istio in K8s, you are deploying these custom resource definitions along with custom controllers.
In the next tutorials, I will cover how to do an Istio deployment in a Kubernetes cluster and deploy your first application in Istio.
