Service Mesh Learning Demo

This repository contains a small Kubernetes + Istio demo for learning service mesh basics.

The demo has three HTTP services:

• web: public entry point that calls catalog
• catalog-v1: stable catalog response that calls inventory
• catalog-v2: alternate catalog response used for traffic shifting
• inventory: downstream dependency used to demonstrate retries, timeouts, and auth policy

The application code has no framework dependencies. Each service uses Python's standard library so the mesh behavior stays easy to see.

What You Will Learn

• Automatic sidecar injection with Istio
• Service-to-service calls through Kubernetes service discovery
• Mesh traffic routing with VirtualService and DestinationRule
• Canary traffic splitting between catalog-v1 and catalog-v2
• Fault injection and retry behavior
• Strict mTLS inside the namespace
• Service-level access control with AuthorizationPolicy

Prerequisites

• Docker
• kubectl
• A Kubernetes cluster, such as kind, Docker Desktop Kubernetes, or Minikube
• Istio CLI, istioctl

Example local cluster setup with kind:

kind create cluster --name mesh-demo
istioctl install --set profile=demo -y

Build And Load Images

For kind:

docker build -t mesh-demo/web:local services/web
docker build -t mesh-demo/catalog:local services/catalog
docker build -t mesh-demo/inventory:local services/inventory

kind load docker-image mesh-demo/web:local --name mesh-demo
kind load docker-image mesh-demo/catalog:local --name mesh-demo
kind load docker-image mesh-demo/inventory:local --name mesh-demo

For Docker Desktop Kubernetes or Minikube, build the images in the Docker environment used by your cluster.

Deploy The Demo

kubectl apply -f k8s/00-namespace.yaml
kubectl apply -f k8s/10-apps.yaml
kubectl apply -f k8s/20-istio-routing.yaml
kubectl apply -f k8s/30-security.yaml

Wait for the workloads:

kubectl -n mesh-demo rollout status deploy/web
kubectl -n mesh-demo rollout status deploy/catalog-v1
kubectl -n mesh-demo rollout status deploy/catalog-v2
kubectl -n mesh-demo rollout status deploy/inventory

Call The App

Port-forward the Istio ingress gateway:

kubectl -n istio-system port-forward svc/istio-ingressgateway 8080:80

In another terminal:

curl http://localhost:8080/

You should see JSON showing the web, catalog, and inventory responses.

Experiments

1. Observe Traffic Splitting

The default route sends 90% of traffic to catalog-v1 and 10% to catalog-v2.

for i in {1..20}; do curl -s http://localhost:8080/ | jq -r '.catalog.version'; done

Change the weights in k8s/20-istio-routing.yaml, then re-apply:

kubectl apply -f k8s/20-istio-routing.yaml

2. Demonstrate Retries

The inventory service can fail when ?fail=true is passed. The catalog service calls inventory with that query when you call:

curl "http://localhost:8080/?fail_inventory=true"

The VirtualService for inventory allows retries, so check Envoy/Istio metrics or pod logs to see repeated attempts.

3. Inject Delay

Enable the commented fault injection block in k8s/20-istio-routing.yaml under the inventory VirtualService, then apply it:

kubectl apply -f k8s/20-istio-routing.yaml
curl http://localhost:8080/

The request should slow down, showing how the mesh can shape downstream behavior without changing app code.

4. Verify mTLS

Strict mTLS is enabled in k8s/30-security.yaml for the mesh-demo namespace:

kubectl -n mesh-demo get peerauthentication

5. Test Authorization Policy

Only the catalog service account can call inventory.

This should be denied:

kubectl -n mesh-demo run curl-test --rm -it --image=curlimages/curl --restart=Never -- \
  curl -s -o /dev/null -w "%{http_code}\n" http://inventory:8080/

The application path still works because web calls catalog, and catalog is allowed to call inventory.

Cleanup

kubectl delete namespace mesh-demo