Service Meshes like Istio are becoming essential as microservices architectures grow increasingly popular. They provide vital capabilities like service-to-service communication, traffic management, and observability, all in a seamless and automated manner. In this blog, we’ll explore key concepts of Istio, explain how it fits into a microservices environment, and cover practical steps to set up Istio on Amazon EKS, deploy a demo microservice application, and visualize tracing through Kiali.
Why Istio? The Need for a Service Mesh in Microservices
In modern microservices-based applications, services interact with each other, often leading to complex connectivity, management, and monitoring challenges. While Kubernetes offers a way to orchestrate containers and facilitates service-to-service connections, it does not provide built-in capabilities for observability, traffic management, security, and monitoring across services. This lack of insight can hinder debugging, monitoring, and managing services effectively.
This is where Istio comes in. It provides a comprehensive solution to manage service-to-service communication, observability, and security. Essentially, Istio acts as a service mesh, which is a network of microservices connected together to handle communication, routing, security, and monitoring in a consistent manner.
Kubernetes: Basic Service Communication and Its Limitations
Kubernetes provides fundamental service discovery and communication via its built-in networking model. However, as your system grows, there are major limitations:
- Lack of Observability: Kubernetes doesn’t provide an out-of-the-box way to observe or trace communication between services. Monitoring traffic between services, gathering metrics, and understanding service behavior requires additional tools.
- Visibility Issues: As microservices grow in scale, it becomes harder to visualize the traffic flow between services.
- Security Concerns: Kubernetes does not offer fine-grained control over service-to-service communication or encryption out-of-the-box.
These limitations necessitate the use of a service mesh like Istio, which provides features like traffic management, service discovery, security, and observability.
Service Mesh Concept: Connecting Microservices
A service mesh is a dedicated infrastructure layer that enables microservices to communicate with each other. Instead of each service connecting to others directly, they communicate through the mesh, which handles routing, monitoring, and security.
In Istio, this is achieved through the proxy concept, typically using Envoy proxy. Each service in a microservices architecture is paired with a proxy container that intercepts all incoming and outgoing traffic. These proxies communicate with each other to route traffic, enforce policies, and capture metrics.
The Sidecar Pattern
Istio employs the sidecar design pattern, where every application pod in Kubernetes contains an additional container (the sidecar) alongside the main app container. This proxy container is responsible for controlling the communication between services, and therefore this container need to be initialize before main app container and hence it is also known as init container.
For example, in a pod running a web application, Istio injects an Envoy proxy container. The proxy container manages all network traffic, while the main container remains unaware of the network routing, traffic security, or observability.
This design is called the sidecar pattern, and it allows Istio to handle service-to-service communication seamlessly while the application continues to run independently.
Proxies and Service Communication
In Istio, communication between services is routed through proxies. Every time a service needs to communicate with another, the request goes through the local proxy, which then routes it to the appropriate destination.
The proxies communicate with each other to share updates about the services they represent. Whenever a new pod is created, its proxy automatically registers itself with the Istio service discovery system, ensuring the proxies are always aware of one another.
Istio Architecture
Istio’s architecture consists of two primary layers: the data plane and the control plane.
Data Plane
The data plane is where the proxies (Envoy) live. These proxies intercept all network traffic and enforce policies, such as routing, load balancing, retries, and security. Every microservice in your application has a corresponding Envoy proxy that sits in front of it.
Control Plane
The control plane is responsible for managing and configuring the proxies. It consists of several components:
- Pilot: This component handles service discovery, traffic routing, and policy configuration. It ensures that each Envoy proxy knows about other services and how to route traffic.
- Citadel: For security, Istio uses Citadel to implement authentication protocols, such as mTLS (mutual TLS), OAuth, and other secure communication mechanisms between proxies. Citadel ensures that data shared between services remains encrypted and authenticated.
- Galley: Configuration management in Istio is handled by Galley, which translates user-defined configurations into Istio’s internal language. When users apply configuration changes in YAML format, Galley processes these configurations and relays them to Pilot or Citadel to implement the updates across the proxies.
The Shift to Istiod: Simplified Architecture
Earlier Istio versions relied on separate pods for Pilot, Citadel, and Galley. However, the latest architecture merges these components into a single service called istiod. This consolidation simplifies Istio’s setup and resource management while providing the same functionalities. Istiod handles service discovery, configuration, and security management in a streamlined manner.
Observability: Logs, Metrics, and Tracing
One of Istio’s strengths is its observability features. The Envoy proxies embedded in each service capture logs, metrics, and tracing information for every request, which istiod then processes. Depending on the configured add-ons, Istio can store and visualize these data. For instance:
- Prometheus: for storing and analyzing metrics.
- Grafana: for visualizing metrics.
- Jaeger: for tracing requests through the mesh.
- Kiali: for service mesh visualization and tracing.
In the following sections, we’ll set up an Istio environment on AWS EKS, deploy a sample microservice, and visualize its data with Kiali.
Setting Up Istio on Amazon EKS
Prerequisites:
- An AWS account and a AWS CLI
- A Kubernetes cluster running on Amazon EKS.
- Kubectl & eksctl installed.
Step 1: Create an EKS Cluster
Login to AWS CLI & Use eksctl to create an EKS cluster with Kubernetes:
Step 2: Install Istio
Run the following command to install Istio using the YAML files:
- To create CRD (Custom Resource Definitions)
kubectl apply -f https://raw.githubusercontent.com/harsh2478/istio_data/refs/heads/master/istio_test_code/1-istio-init-complete-CRD.yaml
- To set up Istio.
kubectl apply -f https://raw.githubusercontent.com/harsh2478/istio_data/refs/heads/master/istio_test_code/2-istio-setup-full.yaml
- To create a secret file for kiali credentials.
kubectl apply -f https://raw.githubusercontent.com/harsh2478/istio_data/refs/heads/master/istio_test_code/3-kiali-secret.yaml
- Change the service type of kiali to LoadBalancer, because in EKS by
default NodePort doesn’t work, LoadBalancer will create ELB Load Balancer.
kubectl edit svc kiali -n istio-system
- Access the kiali Dashboard at 20001 port no.
- Label the namespace for automatic sidecar injection:
- Now launch any application in default ns.
- Expose the deployment.
- Now proxy collects the metrics, logs, etc. Go to -> Kiali service
Deploying a Sample Microservice Application
To test Istio’s functionality, deploy a sample microservice application. Istio includes a sample Bookinfo app that can serve as a demonstration.
kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml
Once deployed, confirm that the services are running:
kubectl get pods
kubectl get svc
- For accessing the product page, you can attach an ingress
gateway.
kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/networking/bookinfo-gateway.yamlOr you can also change its type from ClusterIP to LoadBalancer.
In the Kiali dashboard, you’ll see visualizations of your microservices, traffic flows, and dependencies.
Conclusion
Istio plays a pivotal role in microservices architectures by providing features like traffic management, security, and observability. By deploying Istio on Amazon EKS and running a demo microservice application, you can observe its capabilities in action, from traffic routing to tracing with Kiali. Understanding these components will give you the knowledge to manage complex microservices systems effectively.
