Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

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.
The image illustrates service mesh components, showing a data plane with instances A, B, and C, each paired with a sidecar proxy. It also includes icons representing functions like routing network traffic, managing traffic, and establishing secure channels.

​
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.
The image is a diagram titled "Service Mesh Components," highlighting the control plane's role in managing and monitoring service mesh, health of service instances, applying policies, and streamlining operations.
ImplementationLanguage/PlatformKey Characteristics
IstioGoExtensible, full-featured, advanced policy engine
LinkerdScala (JVM)Lightweight, simplicity-first, low overhead
Open Service Mesh (OSM)GoCNCF-compliant, Envoy-based, lightweight control plane
The image shows logos of different service mesh technologies: Istio, Linkerd, and Open Service Mesh, along with their associated companies like Lyft, IBM, Google, Twitter, Microsoft Azure, and Microsoft.
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
The image lists the capabilities of an Open Service Mesh, including simplified operator experience, use of CNCF-compliant Envoy proxy, standard service mesh features, fine-grained security, and open-source tools.

​
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.
The image is a diagram illustrating a demo setup with two sections: "Azure-manage" and "Customer-managed." It shows components like a control panel, book buyer, and bookstore versions, with connections and icons representing different elements.

​
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.
Permissive mode allows all services in the mesh to communicate without explicit SMI traffic policies.

​
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.
Disabling permissive mode without defining traffic policies will block all inter-service communication.

​
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.
The image shows a webpage titled "Bookbuyer" displaying the total number of books bought (567), with 520 from bookstore V1 and 47 from bookstore V2. The current time is also shown at the bottom.

​
References

​
Further Reading

Watch Video