What is service-mesh?

This Claude skill facilitates the implementation and management of advanced service mesh architectures using Istio and Linkerd. It streamlines microservices communication by providing automated configurations for traffic routing, zero-trust security through mTLS, and deep observability, enabling developers to manage complex infrastructure without modifying application code.

When should I use service-mesh?

service-mesh is useful in the following scenarios: • Implementing Canary Deployments: Gradually shifting traffic to new service versions to minimize deployment risk and ensure system stability. • Enforcing Zero-Trust Security: Automatically enabling mutual TLS (mTLS) and fine-grained authorization policies across all service-to-service communications for enhanced security. • Resilience Engineering: Configuring circuit breakers, retries, and outlier detection to prevent cascading failures in distributed microservices environments. • Enhanced Observability: Setting up distributed tracing and automated metric collection to visualize service dependencies and troubleshoot performance bottlenecks efficiently.

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

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

When & Why to Use This Skill

Use Cases