service-mesh

v2026.09.24

Service mesh patterns and implementations. Istio, Linkerd, traffic management, mutual TLS, observability, circuit breaking, and canary routing at the infrastructure level. USE WHEN: user mentions "service mesh", "Istio", "Linkerd", "sidecar proxy", "mutual TLS", "mTLS", "traffic splitting", "Envoy", "mesh" DO NOT USE FOR: API gateway patterns - use `api-gateway`; in-app resilience - use `resilience-patterns`; Kubernetes basics - use `kubernetes`

GitHub
安装命令
npx skhub add claude-dev-suite/service-mesh
Markdown
SKILL.md

Service Mesh

Architecture

┌─────────────────────────────┐
│         Control Plane        │  (Istio: istiod / Linkerd: control plane)
└──────────────┬──────────────┘
               │ config push
    ┌──────────┼──────────┐
    ▼          ▼          ▼
┌────────┐ ┌────────┐ ┌────────┐
│ Sidecar│ │ Sidecar│ │ Sidecar│  (Envoy / linkerd-proxy)
│  Proxy │ │  Proxy │ │  Proxy │
├────────┤ ├────────┤ ├────────┤
│ App A  │ │ App B  │ │ App C  │
└────────┘ └────────┘ └────────┘

Istio Traffic Management

# VirtualService: route rules
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts: [order-service]
  http:
    - match:
        - headers:
            x-canary: { exact: "true" }
      route:
        - destination: { host: order-service, subset: canary }
    - route:
        - destination: { host: order-service, subset: stable }
          weight: 90
        - destination: { host: order-service, subset: canary }
          weight: 10
# DestinationRule: subsets + circuit breaker
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  trafficPolicy:
    connectionPool:
      tcp: { maxConnections: 100 }
      http: { h2UpgradePolicy: DEFAULT, http1MaxPendingRequests: 100 }
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
  subsets:
    - name: stable
      labels: { version: v1 }
    - name: canary
      labels: { version: v2 }

Mutual TLS

# PeerAuthentication: enforce mTLS
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # All traffic must be mTLS

Linkerd (simpler alternative)

# Install
linkerd install | kubectl apply -f -

# Inject sidecar into deployment
kubectl get deploy order-service -o yaml | linkerd inject - | kubectl apply -f -

# Traffic split
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: order-canary
spec:
  service: order-service
  backends:
    - service: order-service-stable
      weight: 900
    - service: order-service-canary
      weight: 100

When to Use a Service Mesh

Use WhenDon't Use When
10+ microservicesMonolith or few services
Need mTLS everywhereTLS at ingress is sufficient
Complex traffic routingSimple load balancing works
Multi-team ownershipSingle team manages all services

Anti-Patterns

Anti-PatternFix
Service mesh for 2-3 servicesOverkill; use in-app libraries
No resource limits on sidecarsConfigure proxy CPU/memory limits
mTLS in PERMISSIVE mode in prodUse STRICT mode in production
No observability dashboardsDeploy Kiali, Grafana, Jaeger with mesh
Ignoring sidecar latencyBenchmark; typically adds <1ms per hop

Production Checklist

  • mTLS in STRICT mode
  • Circuit breaker policies on critical services
  • Traffic splitting for canary deployments
  • Observability: Kiali dashboard, distributed tracing
  • Resource limits on sidecar proxies
  • Gradual rollout (inject namespace by namespace)
发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

Sep 24, 2026

分类

未分类

许可证

MIT

源路径

skills/infrastructure/service-mesh

默认分支

main

最新提交

9496306

Tree SHA

fe4e2f1