Service Mesh (Istio/Linkerd) for Microservices

Service Mesh (Istio/Linkerd) Implementation for Microservices

Service Mesh is an infrastructure layer for managing inter-service traffic in Kubernetes. Instead of each microservice independently implementing retry, timeout, mTLS, and tracing, these functions are offloaded to sidecar proxy, transparent to service code.

What Service Mesh Provides

Traffic Management:

• Canary deployment (5% traffic → new version)
• A/B testing by headers
• Circuit breaker at infrastructure level
• Retry and timeout without code changes

Observability:

• Automatic tracing of all inter-service requests
• Metrics: latency, error rate, throughput for each service pair
• Service dependency graph (Service Graph)

Security:

• mTLS between all services without code changes
• Certificate rotation
• Authorization Policies

Istio vs Linkerd

Linkerd for teams needing mTLS, observability, and basic traffic management without learning hundreds of Istio CRDs.

Linkerd Installation

# Install CLI
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh

# Check cluster
linkerd check --pre

# Install control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

# Verify
linkerd check

Sidecar injection (namespace annotation):

apiVersion: v1
kind: Namespace
metadata:
  name: production
  annotations:
    linkerd.io/inject: enabled

After this, all pods in namespace automatically get linkerd-proxy container.

Istio Traffic Management

Canary Deployment — gradual rollout of new version:

Use VirtualService and DestinationRule for traffic splitting, header-based routing, and progressive traffic shift.

Circuit Breaker through DestinationRule:

Configure consecutive error thresholds, ejection times, and connection pools.

mTLS

In Istio, enable mTLS per-namespace or globally:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # only mTLS, plaintext forbidden

Authorization Policy — who can call whom:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: order-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: order-service
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/api-gateway"]
      to:
        - operation:
            methods: ["GET", "POST"]

Observability via Kiali

Kiali is UI for Istio showing Service Graph:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/jaeger.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/grafana.yaml

istioctl dashboard kiali

Implementation Timeline

• Linkerd installation + basic observability — 3–5 days
• Istio installation + canary routing + mTLS — 1–2 weeks
• Authorization policies + full observability stack — 1 more week