Open Service Mesh

A service mesh in Kubernetes offers a dedicated communication layer that abstracts networking and infrastructure concerns away from application code. By injecting a lightweight proxy—called a sidecar—next to each service instance, it intercepts all inbound and outbound traffic. This approach provides consistent traffic management, mTLS security, and observability without changing your application.

Services (e.g., frontend, middle-tier, backend) run alongside their respective sidecar proxies. Although deployed together, proxies are managed independently, allowing you to update or scale them separately. The result is a clean codebase while the mesh transparently handles retries, circuit breaking, encryption, and more.

Open Service Mesh (OSM) for AKS consists of two main layers: the data plane and the control plane.

Data Plane

The data plane is responsible for the actual routing of network traffic between services. Its key functions include:

• Service discovery: Automatically finding and routing to healthy instances.
• Traffic management: Implementing retries, circuit breakers, and load balancing.
• Security: Establishing mutual TLS (mTLS) channels for encrypted, authenticated communication.

Control Plane

The control plane provides centralized orchestration and visibility. It:

• Provisions and scales service instances.
• Monitors pod health and replaces unhealthy instances.
• Enforces policies such as rate limits, access control, and routing rules.

Popular Service Mesh Implementations

On Azure Kubernetes Service (AKS), OSM was the original built-in mesh, and Istio is now available in preview. This guide will focus on deploying and using OSM on AKS.

Features of Open Service Mesh

• Simplified control plane for easy operations
• Envoy sidecars for CNCF-approved, high-performance proxying
• Traffic policies: access control, traffic splitting, telemetry
• Fine-grained mTLS for service-to-service encryption
• Integration with Prometheus, Grafana, Jaeger for monitoring and tracing
• Support for external certificate authorities in production

Demo Architecture

We’ll deploy a sample bookstore application on AKS with OSM in permissive mode. The demo includes:

• Book Buyer (client)
• Bookstore V1 (primary backend)
• Bookstore V2 (for traffic splitting)
• Book Warehouse (additional service)

The workflow covers enabling OSM, onboarding namespaces, testing default traffic, toggling permissive mode, applying explicit policies, and performing traffic splits.

Prerequisites

• Azure CLI installed
• kubectl configured locally
• osm CLI for namespace onboarding

1. Create Resource Group and AKS Cluster

# Create a resource group
az group create -l southeastasia -n kodekloud-osmdemo-rg

# Create AKS cluster with the OSM add-on
az aks create \
  -g kodekloud-osmdemo-rg \
  -n kk-aks-osmdemo \
  --enable-addons open-service-mesh

2. Configure kubectl Context

# Fetch AKS credentials
az aks get-credentials -g kodekloud-osmdemo-rg -n kk-aks-osmdemo

# Confirm the current context
kubectl config current-context

3. Create Namespaces and Onboard to OSM

# Create application namespaces
kubectl create ns bookbuyer bookstore bookwarehouse

# Add namespaces to the mesh
osm namespace add bookbuyer bookstore bookwarehouse

4. Deploy Sample Applications

# Deploy the Book Buyer client
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v0.11/docs/example/manifests/apps/bookbuyer.yaml

# Deploy Bookstore V1
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v0.11/docs/example/manifests/apps/bookstore.yaml

# Deploy the Book Warehouse
kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm/release-v0.11/docs/example/manifests/apps/bookwarehouse.yaml

Wait for the Book Buyer pod:

kubectl get pods -n bookbuyer -w

5. Port-Forward and Verify Default Traffic

# Retrieve the Book Buyer pod name
POD=$(kubectl get pod -n bookbuyer -l app=bookbuyer -o jsonpath='{.items[0].metadata.name}')

# Forward local port 8081 to the sidecar port
kubectl port-forward -n bookbuyer $POD 8081:14001

Open http://localhost:8081 to see Book Buyer successfully fetching from Bookstore V1 under OSM’s permissive policy.

6. Disable Permissive Traffic Policy

In the Azure Portal under AKS → Open Service Mesh → Configuration, update:

traffic:
  enableEgress: true
  enablePermissiveTrafficPolicyMode: false

After saving, Book Buyer will fail to reach Bookstore V1.

kubectl logs -n bookbuyer $POD
# Look for denied request errors.

7. Apply Explicit Allow Traffic Policy

kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/release-v1.2/manifests/access/traffic-access-v1.yaml

This SMI policy permits Book Buyer to call Bookstore. Reload http://localhost:8081 to confirm connectivity.

8. Demonstrate Traffic Splitting

Create traffic-split.yaml:

apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: bookstore-split
  namespace: bookstore
spec:
  service: bookstore
  backends:
    - service: bookstore-v1
      weight: 500m
    - service: bookstore-v2
      weight: 500m

Apply the split:

kubectl apply -f traffic-split.yaml

Refresh the Book Buyer page—traffic should now be distributed evenly between V1 and V2. Adjust the weight values to shift more traffic to a particular version.

References

• Kubernetes Concepts
• Open Service Mesh (OSM) Documentation
• SMI Specifications

Further Reading

• Azure Kubernetes Service Documentation
• Envoy Proxy