Istio Service Mesh in Kubernetes
Hello and thanks for your interest in knowing more about service mesh and specifically istio. This is my third blog article about Service Mesh, and probably more to come ..
This is the first in-depth in the series that will cover service mesh mechanics and how it works. If you feel this is too deep or you need a refresher feel free to check the previous articles.
In this article we will focus on istio architecture and components and how istio is integrated with kubernetes work flows and benefit from it.
What is Service Mesh?
Service Mesh is a technology that manages the way different services communicate. It relies on layer seven (L-7) proxies, managed by a control plane, running alongside each of the application services. The proxies intercepts traffic, inspecting it according to the given configuration, manipulating it if needed and deciding whether it should reach the original service or not.
As a result of the traffic interception and application protocol (such as HTTP) understanding, Service Mesh can provide a lot of observability and tracing capabilities that are separate from the code base and provided by just participating in the mesh.
Istio Service Mesh Architecture and Components
As in the diagram from from Istio website, you can separate it into three layers:
Control Plane: The control plane acts as the brain of the mesh, it has the main service (istiod) running which can be broken into the 3 main services:
Pilot: It serves 2 main purpose:
Provides service discovery service to envoy proxies running as sidecars to provide features like Canary Deployments, Circuit Breakers, timeouts etc.
Receive high level routing rules for traffic control in configuration files, convert them to Envoy configuration and send them to the proxies using Envoy APIs
Citadel: has built-in identity and credential management and provides features like:
- Service-to-Service Authentication
- End-User Authentication
- mTLS certificate generation.
Galley: works as a validator, ingestor, processor and distributor for incoming configurations, so it isolates the rest of the control plane from the outside world.
There is a fourth member of the plane that is now separated and is shipped separately as part of the ecosystem which is the Mixer.
The Mixer: collects metrics and telemetry data, and it is extensible with adapters and handlers to extend the capabilities of istio integration with other systems.
Envoy: Envoy is actually not part of the control plane but it's a crucial part of the mesh and probably one of the reasons that the service mesh idea is successful depends on the success of Envoy.
Envoy plays the proxy role. It is injected next to each of your services as we will see in the next section. Envoy is configured and keeps connected to the control plane through Pilot.
Istio has gone through major architectural and delivery model changes starting from Istio 1.5. The team decided to combine all components (microservices) into a one shippable component Istiod. The decision is actually an anti-microservices form, but it helped to make the release and delivery easier, especially since those components are already dependent on each other. This is an example of when microservices is not the better architecture to use. Istio team has already wrote a blog Introducing Istiod and describing their reasons behind this decision
How does it work within Kubernetes?
The core functionalities of istio are dependent on Envoy injected side car proxies. Those proxies extract signals about traffic behavior to help enforce policies.
Envoy supports advanced load balancing features including automatic retries, circuit breaking, rate limiting, traffic mirroring, load balancing and it is shipped with APIs for easy management, and with Layer 7 support Envoy has deep observability features to capture traffic signals, and allow for distributed tracing.
Let's assume that you have istio installed and configured for automatic injection.
Istio relies on a mutating webhook admission controller to inject it's sidecar into the service pod. When a new deployment is created and is part of the mesh, an API call is sent to kubernetes's api-server, this call is first authenticated and then intercepted by istio's mutating webhook.
The webhook injects istio needed containers:
istio-init:
An init-container that runs, finishes it's job and is removed (as init-containers job) before the application starts.
The function of the init container is to setup iptables rules to make all incoming and outgoing traffic pass through the proxy
istio-proxy:
This is the actual envoy proxy that will be intercepting the traffic and communicating with the control plane for configuration.
Once the service is up the workflow happens as follow:
- The new service notifies the Platform adapter in Pilot
- The Platform adapter register the new service using the abstract Model
- Pilot distributes the new traffic rules and configurations to all the mesh proxies as a notification of the new service.
From now on the traffic to and from the application pod is intercepted and controlled by the mesh.
I guess this is already a lot of info, and probably it’s a good step to break this article into two.
Next time we will speak about how the traffic is handled within the mesh for both incoming and outgoing traffic. Till then stay safe and healthy !