Setting up and Using Istio with Azure Kubernetes Service (AKS)
Component Overview
1. What is a Service Mesh?
A Service Mesh is a dedicated infrastructure layer for handling communication between services in a microservices architecture. It abstracts network functions such as:
Instead of embedding these functions inside each microservice, a service mesh moves them out into a separate layer, typically using sidecar proxies.
Example Analogy: Think of a service mesh as air traffic control managing multiple aeroplanes (microservices) flying in the same space.
2. What is Istio?
Istio is an open-source service mesh that helps secure, connect, and monitor microservices in Kubernetes.
It achieves this by:
Deploying Envoy proxies as sidecars in each pod Using control plane components (istiod) to manage traffic Providing mTLS security, observability, and traffic routing
Role in Service Mesh:
3. What is a Sidecar Container?
A Sidecar Container is an additional container inside a pod that enhances the main application.
In Istio, the sidecar is an Envoy proxy that:
Example Analogy: Imagine your microservice is a race car. The sidecar is the racing engineer sitting beside the driver, giving navigation and speed advice.
What Happens If Sidecar is Not Enabled?
If you do not enable automatic sidecar injection, services will communicate directly without Istio’s security and traffic control.
Can We Still Use Istio Without Sidecar?
Yes, but with limitations.
Not recommended for production if you want full service mesh features
What is an Admission Controller?
An admission controller is a Kubernetes webhook that intercepts API requests before they are applied.
Istio uses two important admission controllers:
Is Admission Controller Mandatory?
No, but it’s highly recommended.
If disabled:
How to Disable Admission Controllers?
kubectl delete mutatingwebhookconfiguration istio-sidecar-injector
But this is not recommended in production.
Final Answer: Can We Use Istio Without Admission Controllers?
Yes, but you must manually inject the sidecar and validate configs. Not recommended for production.
What is a VirtualService?
A VirtualService in Istio defines how requests are routed to a service.
Example Use Cases:
Canary Deployments (Send 80% traffic to v1, 20% to v2) Blue-Green Deployments Traffic Shifting (Route based on headers, weights, etc.)
What is a DestinationRule?
A DestinationRule configures how traffic is handled after it has been routed.
Example Use Cases:
Load Balancing (Round Robin, Least Connection) mTLS Encryption Canary Deployments (Subsets for v1, v2)
What is mTLS Authentication?
Mutual TLS (mTLS) is an encrypted communication method where:
Why Use mTLS?
Prevents man-in-the-middle (MITM) attacks Ensures only trusted services communicate
What is Canary Deployment?
Canary Deployment is a release strategy where:
How It Works with Istio?
VirtualService defines traffic routing rules DestinationRule controls subsets (v1, v2) Gradual rollout ensures a safe release
Example
Setting up and Using Istio with Azure Kubernetes Service (AKS)
Azure Kubernetes Service (AKS) provides a managed Kubernetes environment that makes it easy to deploy and manage containerized applications. Istio is a service mesh that layers transparently onto existing distributed applications, adding critical capabilities for observability, traffic management, and security without requiring changes to application code.
AKS and Istio provide a powerful platform for deploying, managing, and securing microservices architectures in the cloud.
Why Use Istio in a Kubernetes Environment?
In a Kubernetes cluster, microservices like login, catalogue, payments, and notifications can already communicate with each other using service names. So naturally, you might ask: “If these services can already talk, why do we need a service mesh like Istio?”
The answer lies in how they communicate.
1. Secure Communication with Mutual TLS
By default, Kubernetes services talk to each other without encryption. That’s a security risk in many environments.
Istio enhances this by introducing Mutual TLS (mTLS):
This is more secure than traditional TLS (where only the client proves its identity). With mTLS, the client and server validate each other, creating a trusted connection.
2. Smart Deployment Strategies
Istio enables powerful deployment patterns, like:
Canary Deployments:
Suppose the catalogue talks to payments v1, and now you want to introduce payments v2. Instead of switching entirely, you can:
This is hard to implement in vanilla Kubernetes but easy with Istio.
3. Built-in Observability
Istio provides observability out of the box using tools like Kiali.
This reduces the need for third-party observability tools.
4. How Istio Works — The Sidecar Pattern
Here’s the magic: Istio doesn’t modify your application code. Instead, it adds a sidecar container (a proxy) into each pod. This sidecar is typically an Envoy Proxy.
What it does:
So when catalogue wants to talk to payments, the request goes:
catalog → sidecar proxy → network → payments’ sidecar proxy → payments
This pattern allows Istio to manage traffic centrally and securely.
5. How Istio Adds Sidecars — Admission Controllers
Now you may ask: “How does Istio know when to inject these sidecars?”
When you create a pod:
No manual intervention is needed.
Bonus: Other Features of Istio
Summary
Istio is more than just a traffic manager — it brings security, flexibility, observability, and deployment intelligence to Kubernetes, all with minimal changes to your code.
This example deploys a sample application composed of four separate microservices used to demonstrate various Istio features
This application is polyglot, i.e., the microservices are written in different languages. It’s worth noting that these services have no dependencies on Istio, but make an interesting service mesh example, particularly because of the multitude of services, languages and versions for the reviews service.
The application displays information about a book, similar to a single catalog entry of an online bookstore. Displayed on the page is a description of the book, book details (ISBN, number of pages, and so on), and a few book reviews.
The Bookinfo application is broken into four separate microservices:
There are 3 versions of the reviews microservice:
The end-to-end architecture of the application is shown below.
Deploying the application
To run the sample with Istio requires no changes to the application itself. Instead, you simply need to configure and run the services in an Istio-enabled environment, with Envoy sidecars injected along side each service. The resulting deployment will look like this:
All of the microservices will be packaged with an Envoy sidecar that intercepts incoming and outgoing calls for the services, providing the hooks needed to externally control, via the Istio control plane, routing, telemetry collection, and policy enforcement for the application as a whole.
Prerequisites
Before getting started, ensure you have the following tools installed:
1. Prerequisites Setup
First, ensure you have the necessary tools installed:
# Install Azure CLI
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
# Install kubectl
az aks install-cli
# Install Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
# Download and install istioctl
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.17.2 sh -
export PATH=$PWD/istio-1.17.2/bin:$PATH
Creating an AKS Cluster
az group create --name istioaksrg --location eastus
az aks create --resource-group istioaksrg --name istioaks --generate-ssh-
# Get credentials for the AKS cluster
az aks get-credentials --resource-group istioaksrg --name istioaks
Deploying Istio on AKS
There are multiple ways to install Istio. We’ll cover both the Helm approach and istioctl approach:
Using Helm (Recommended for Production)
# Add Istio Helm repository
helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
# Create namespace for Istio components
kubectl create namespace istio-system
# Install Istio base chart
helm install istio-base istio/base -n istio-system
# Install Istio discovery chart (istiod)
helm install istiod istio/istiod -n istio-system --wait
# Install Istio ingress gateway
helm install istio-ingressgateway istio/gateway -n istio-system
Using istioctl
# Download Istio
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.22.0 sh -
cd istio-1.22.0
# Install Istio with the demo profile (includes core components, ingress/egress gateways, and demo add-ons)
istioctl install --set profile=demo -y
4. Enable Automatic Sidecar Injection
This ensures all deployed pods automatically get the Istio proxy sidecar:
# Create a namespace for your applications
kubectl create namespace istioaksapp-ns
# Enable automatic sidecar injection
kubectl label namespace istioaksapp-ns istio.io/rev=asm-1-22
kubectl label namespace istioaksapp-ns istio-injection=enabled --overwrite
Install mesh for existing cluster
az aks mesh enable --resource-group istioaksrg --name istioaks
az aks show --resource-group istioaksrg --name istioaks --query serviceMeshProfile
Deploying Sample Applications
Deploy the Bookinfo sample application to test your Istio installation:
# Apply the Bookinfo application
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/bookinfo/platform/kube/bookinfo.yaml -n istioaksapp-ns
# Verify pods are running with istio-proxy sidecar (2/2 containers)
kubectl get pods -n istioaksapp-ns
kubectl get services -n istioaksapp-ns
Istio Ingress Gateway
Configure an Istio Gateway and VirtualService to expose your application:
# Enable internal ingress gateway
az aks mesh enable-ingress-gateway --resource-group istioaksrg --name istioaks --ingress-gateway-type internal
# Use kubectl get svc to check the service mapped to the ingress gateway:
kubectl get svc --all-namespaces | grep -i ingress
Applications aren’t accessible outside the cluster by default after enabling the ingress gateway. To make an application accessible, map the sample deployment’s ingress to the Istio ingress gateway using the following manifest:
# Apply the Bookinfo gateway
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.17/samples/bookinfo/networking/bookinfo-gateway.yaml -n istioaksapp-ns
# Get the ingress gateway IP address
$env:INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$env:INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
$env:GATEWAY_URL = "$INGRESS_HOST`:$INGRESS_PORT"
# Access your application
echo "http://$GATEWAY_URL/productpage"
Observability Tools (Prometheus and Grafana)
Install Prometheus and Grafana to monitor your service mesh:
# Install Prometheus
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/addons/prometheus.yaml
# Install Grafana
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/addons/grafana.yaml
# Port forward to access Grafana dashboard
kubectl port-forward svc/grafana 3000:3000 -n istio-system
Access Grafana at http://localhost:3000 and explore pre-configured Istio dashboards:
Kiali
Deploy Kiali for service mesh visualization:
# Install Kiali
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.22/samples/addons/kiali.yaml
# Port forward to access Kiali dashboard
kubectl port-forward svc/kiali 20001:20001 -n istio-system
kubectl get svc -n istio-system
Istio Traffic Management
Request Routing
Route traffic based on different conditions:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
namespace: my-apps
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
Apply this configuration:
kubectl apply -f reviews-routing.yaml -n my-apps
Istio Security
Demo 1 mTLS Authentication
When you apply mutual TLS (mTLS) to your services in Istio, it enhances the security by ensuring that the communication between services is encrypted and that both the client and server authenticate each other. Here’s what happens in the Kiali dashboard when you apply mTLS:
2. Security Icons:
3. Destination Rules Visualization:
4. Traffic Policy Information:
5. Health and Metrics:
6. Istio Config:
Enable mutual TLS authentication:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: STRICT
Apply this configuration:
kubectl apply -f mtls-strict.yaml
Example Destination Rule for mTLS
The following example from the destination-rule-all-mtls.yaml file is a destination rule that enables mTLS for the productpage service:
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: productpage
spec:
host: productpage
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
subsets:
- name: v1
labels:
version: v1
Impact on Kiali Dashboard
This image from the Kiali dashboard provides a visual representation of the service mesh, specifically showing the communication between the istio-ingressgateway, productpage, and productpage-v1 services. Here’s a detailed explanation of what is shown:
1. Services and Versions: — The istio-ingressgateway service in the istio-system namespace is communicating with the productpage service. — The productpage service has a version productpage-v1.
2. Connections: — The lines between the services represent the traffic flow. The arrows indicate the direction of the traffic. — The line from istio-ingressgateway to productpage indicates traffic between these services. — Similarly, the line from productpage to productpage-v1 indicates traffic between these services.
3. Traffic Rates: — Along the lines, you see traffic rates in requests per second (rps). For example: — 0.04 rps from istio-ingressgateway to productpage. — 0.04 rps from productpage to productpage-v1.
4. mTLS Lock Icon: — The lock icon on the lines between istio-ingressgateway and productpage, and productpage and productpage-v1 indicates that mutual TLS (mTLS) is enabled for these connections, meaning the communication is encrypted.
5. Service Details: — On the left side, you see the details of the productpage service, including its labels (`app=productpage`, service=productpage), and its version productpage-v1.
6. Network Information: — At the bottom left, network information is provided, such as the cluster IP and endpoints for the productpage service.
In summary, this graph shows that the istio-ingressgateway service is making encrypted requests to the productpage service, and the productpage service is communicating with its productpage-v1 version. The presence of lock icons indicates that mTLS is enabled for these connections, confirming that these connections are encrypted.
1. Services and Versions:
- The productpage service (version v1) is communicating with the reviews service.
- The reviews service has three versions (`v1`, v2, v3), but in this graph, only reviews-v1 is shown as actively receiving traffic.
2. Connections:
- The lines between the services represent the traffic flow. The arrow indicates the direction of the traffic.
- The line from productpage-v1 to reviews indicates traffic between these services.
3. Traffic Rates:
- Along the lines, you see traffic rates in requests per second (rps). For example, 0.04 rps indicates the rate at which the productpage-v1 is sending requests to the reviews service.
4. mTLS Lock Icon:
- The lock icon on the line between productpage-v1 and reviews indicates that mutual TLS (mTLS) is enabled for this connection, meaning the communication is encrypted.
5. Latency and Bandwidth:
- The numbers 10ms and 13 bps represent the latency (time taken for a request to travel from one service to another) and bandwidth (amount of data being transferred) respectively.
6. Service Details:
- On the left side, you see the details of the reviews service, including its labels (`app=reviews`, service=reviews), and its various versions.
7. Network Information:
- At the bottom left, network information is provided, such as the cluster IP and endpoints for the reviews service.
In summary, this graph shows that the productpage-v1 service is making encrypted requests to the reviews service, specifically to its reviews-v1 version, with details about traffic rates, latency, and bandwidth, confirming that mTLS is in place.
By applying mTLS, you ensure that your services are communicating securely, and Kiali helps you visualize and manage this configuration effectively.
# To enforce mutual TLS, use the destination rules in
kubectl apply -f https://raw.githubusercontent.com/istio/istio/76765f3d9a9c0d19abc241b209f31bee64255986/samples/bookinfo/networking/destination-rule-all-mtls.yaml -n istioaksapp-ns
Verify mTLS is enabled:
kubectl get peerauthentication --all-namespaces
istioctl x describe pod <podname>.<namespace>
Demo 2 Traffic Shifting
Implement canary deployments:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
namespace: istioaksapp-ns
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 80
- destination:
host: reviews
subset: v2
weight: 20
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
namespace: istioaksapp-ns
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Applying the Configurations
1. Save the above YAML files:
- Save the DestinationRule configuration as destination-rule-reviews.yaml.
- Save the VirtualService configuration as virtual-service-reviews.yaml.
2. Apply the DestinationRule:
kubectl apply -f destination-rule-reviews.yaml
3. Apply the VirtualService:
kubectl apply -f virtual-service-reviews.yaml
Verify the Canary Deployment
1. Check the Services:
- Use Kiali or another service mesh observability tool to verify that the traffic is being routed according to the weights specified in the VirtualService.
2. Monitor the Traffic:
- Ensure that 80% of the traffic is hitting v1 and 20% is hitting v2. Adjust the weights as needed based on the performance and stability of the new version.
3. Gradually Increase Traffic:
- If v2 is stable, gradually increase the weight of v2 while decreasing v1 until all traffic is routed to v2.
By following these steps, you can implement a canary deployment strategy using Istio, allowing you to roll out new versions of your services safely.
Testing Istio VirtualService Traffic Splitting from the UI
Your VirtualService defines a weighted traffic distribution:
If you have a UI (frontend application) that interacts with the reviews service, you can test this behaviour by reloading the page multiple times and checking which version of reviews you get.
Conclusion
Integrating Istio with AKS provides powerful capabilities for managing and observing your containerized applications. By leveraging Istio’s traffic management, security, and observability features, you can build more resilient, secure, and observable microservice architectures.
Key benefits of using Istio with AKS include: