Service Mesh

Advanced service mesh implementation with Istio, Linkerd, traffic management, mTLS, and observability.

Overview

Service mesh provides infrastructure-level features for service-to-service communication including traffic management, security, and observability without changing application code.

Key Concepts

Traffic Management

Virtual Services: Route traffic based on rules
Destination Rules: Configure load balancing, connection pools
Gateways: Manage ingress/egress traffic
Service Entries: Add external services to mesh

Security

mTLS: Mutual TLS between services
Authorization Policies: Fine-grained access control
Peer Authentication: Identity verification
Request Authentication: JWT validation

Observability

Distributed Tracing: Automatic trace propagation
Metrics: Automatic metric collection
Access Logging: Request/response logging
Service Graph: Visualization of dependencies

Istio Patterns

Traffic Routing

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
    - reviews
  http:
    - match:
        - headers:
            end-user:
              exact: jason
      route:
        - destination:
            host: reviews
            subset: v2
    - route:
        - destination:
            host: reviews
            subset: v1

Canary Deployment

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
            subset: v1
          weight: 90
        - destination:
            host: my-service
            subset: v2
          weight: 10

Circuit Breaker

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 100
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

mTLS Configuration

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Linkerd Patterns

Service Profile

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service.default.svc.cluster.local
spec:
  routes:
    - name: GET /api/users
      condition:
        method: GET
        pathRegex: /api/users
      responseClasses:
        - condition:
            status:
              min: 500
              max: 599
          isFailure: true

Traffic Split

apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: my-service-split
spec:
  service: my-service
  backends:
    - service: my-service-v1
      weight: 900m
    - service: my-service-v2
      weight: 100m

Best Practices

Start with Observability: Enable tracing before traffic management
Gradual mTLS Rollout: Use permissive mode first
Circuit Breaker Tuning: Start conservative, adjust based on data
Avoid Mesh Complexity: Don't over-engineer routing rules
Resource Limits: Set appropriate proxy resource limits

Anti-Patterns

Putting business logic in routing rules
Ignoring sidecar resource consumption
Not monitoring mesh control plane
Over-complicating traffic policies
Skipping gradual rollout of mesh features

When to Use

Multiple services needing consistent traffic management
Zero-trust security requirements
Need for advanced observability without code changes
Complex deployment strategies (canary, blue-green)

When NOT to Use

Simple applications with few services
When latency is extremely critical (adds ~1ms)
Teams without Kubernetes expertise
Tight resource constraints

service-mesh