Lab 4: Service Mesh with Istio on AKS (Optional) :: Kubernetes on Azure Workshop

Exercise 1: Enable the Istio Add-on

Sat, 30 May 2026 19:52:00 +0000

In this exercise, you will remove the Application Routing Gateway API add-on, enable Istio using the AKS add-on, confirm the managed control plane is running, and enable an external Istio ingress gateway. Info This lab uses sidecar injection because it is the most widely understood Istio data plane model and is supported by the AKS Istio add-on experience. Ambient mesh is covered in the education module, but is not used in this short lab.

Exercise 2: Deploy an Application into the Mesh

Sat, 30 May 2026 19:52:00 +0000

In this exercise, you will create a namespace that participates in the mesh and deploy two versions of a simple web application. Task 1: Create a Mesh-Enabled Namespace Create a namespace for the demo application and enable sidecar injection using the installed Istio revision. AZ CLI PowerShell AZ CLI Bash kubectl create namespace istio-demo kubectl label namespace istio-demo istio.io/rev=$ISTIO_REVISION kubectl create namespace istio-demo kubectl label namespace istio-demo istio.io/rev=$ISTIO_REVISION Warning With the AKS Istio add-on you must use the revision label istio.io/rev= (for example istio.io/rev=asm-1-24), not the generic istio-injection=enabled label you may have seen in the upstream open-source Istio documentation.

Exercise 3: Manage Traffic with Istio

Sat, 30 May 2026 19:52:00 +0000

In this exercise, you will expose the demo application through the Istio ingress gateway and use Istio routing rules to shift traffic between the two application versions. Info This exercise uses an Istio Gateway because we are exposing the application to traffic from outside the cluster. The traffic splitting itself is done by the VirtualService and DestinationRule, which would also work for service-to-service traffic inside the mesh without any gateway. The Gateway is only here to provide an external entry point so you can reach the app from your browser - it is not a requirement of traffic management.

Exercise 4: Verify and Enforce mTLS

Sat, 30 May 2026 19:52:00 +0000

In this exercise, you will confirm that Istio is encrypting traffic between your meshed workloads with mutual TLS (mTLS), then move the namespace from the default permissive behaviour to strict mTLS so that only encrypted, identity-verified traffic is allowed. When you added the istio-demo namespace to the mesh, every pod received an Envoy sidecar. By default the AKS Istio add-on runs mTLS in PERMISSIVE mode: sidecars will use mTLS when both ends are in the mesh, but will still accept plaintext. This makes onboarding easy, but it means plaintext traffic is not yet blocked.

Exercise 5: Visualise the Mesh with Kiali

Sat, 30 May 2026 19:52:00 +0000

In this exercise, you will install Kiali and a lightweight Prometheus instance, generate traffic through the mesh, and use Kiali to visualise service-to-service traffic. Kiali is a dashboard for Istio service meshes. It helps you see workloads, traffic flows, health, and Istio configuration. It is commonly used during learning and troubleshooting because it makes mesh behaviour visible. Info This exercise installs Kiali with anonymous access and uses kubectl port-forward for local access. This is suitable for a workshop lab, but not a production configuration.

Exercise 6: Clean Up the Istio Demo

Sat, 30 May 2026 19:52:00 +0000

The main workshop cleanup lab will delete the full resource group. If you want to remove only the Istio demo resources now, use the commands below. Task 1: Remove Kiali, Prometheus, and the Demo Namespace Stop any active kubectl port-forward command for Kiali. Remove Kiali and Prometheus. AZ CLI PowerShell AZ CLI Bash helm uninstall kiali-server -n aks-istio-system helm uninstall prometheus -n monitoring kubectl delete namespace monitoring helm uninstall kiali-server -n aks-istio-system helm uninstall prometheus -n monitoring kubectl delete namespace monitoring Delete the demo application namespace.