Service-Mesh-Grundlagen: Istio und Linkerd in der Praxis
Service-Mesh-Architektur mit Istio und Linkerd: Traffic-Management, mutual TLS, Observability, Circuit Breaking — und wann es sich nicht lohnt.
Ein Service Mesh verlagert Netzwerkbelange – Retries, Timeouts, Verschlüsselung, Observability – aus dem Anwendungscode in die Infrastruktur. Statt dass jeder Dienst seine eigene HTTP-Retry-Logik und TLS-Zertifikatsverwaltung implementiert, übernimmt ein Sidecar-Proxy das transparent. Das Versprechen ist überzeugend: einheitliches Netzwerkverhalten über alle Dienste hinweg, ohne den Anwendungscode anzufassen.
Die Realität ist differenzierter. Service Meshes bringen operative Komplexität, zusätzlichen Ressourcenverbrauch und eine weitere Abstraktionsschicht mit sich, die im Fehlerfall analysiert werden muss. Für zehn Microservices ist ein Service Mesh wahrscheinlich übertrieben. Für hundert Dienste, die von dreißig Teams mit jeweils eigener Retry-Logik gepflegt werden, ist es ein echter Wendepunkt. Wer versteht, wann und wie man eines einsetzt, vermeidet sowohl zu wenig als auch zu viel Engineering.
Wie Sidecar-Proxys funktionieren
Jeder Pod erhält einen Sidecar-Proxy (Envoy bei Istio, linkerd2-proxy bei Linkerd), der den gesamten Netzwerkverkehr abfängt. Die Anwendung spricht mit localhost; alles Weitere übernimmt der Proxy.
# What happens when you add a service mesh:
# Before: Service A → Network → Service B
# After: Service A → Sidecar Proxy A → Network →
# Sidecar Proxy B → Service B
# Istio sidecar injection: add label to namespace
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
istio-injection: enabled
# Every pod in this namespace gets an Envoy sidecar
---
# Your deployment doesn't change — sidecar is injected automatically
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
namespace: production
spec:
replicas: 3
selector:
matchLabels:
app: order-service
template:
metadata:
labels:
app: order-service
spec:
containers:
- name: order-service
image: myregistry/order-service:v2.1
ports:
- containerPort: 8080
# No TLS config, no retry logic, no circuit breakers
# The sidecar handles all of it# Linkerd injection: annotate the deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
annotations:
linkerd.io/inject: enabled
spec:
template:
spec:
containers:
- name: order-service
image: myregistry/order-service:v2.1
ports:
- containerPort: 8080Traffic-Management: Canary-Deployments und Routing
Das Feature, das sich am schnellsten bezahlt macht: Traffic anhand von Regeln zu routen, ohne den Anwendungscode zu ändern. Das ermöglicht Canary-Deployments, A/B-Tests und schrittweise Rollouts.
# Istio: canary deployment — route 5% of traffic to v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
- route:
- destination:
host: order-service
subset: v1
weight: 95
- destination:
host: order-service
subset: v2
weight: 5
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order-service
spec:
host: order-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2# Istio: header-based routing for testing
# Route requests with X-Debug: true header to v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
- match:
- headers:
x-debug:
exact: "true"
route:
- destination:
host: order-service
subset: v2
- route:
- destination:
host: order-service
subset: v1Mutual TLS: Verschlüsselung ohne Codeänderungen
Die Verschlüsselung der Kommunikation zwischen Diensten erfordert normalerweise, dass jeder Dienst seine eigenen Zertifikate verwaltet. Ein Service Mesh automatisiert den gesamten Lebenszyklus dieser Zertifikate.
# Istio: enforce mTLS for all services in the mesh
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT
# STRICT: only accept mTLS connections
# PERMISSIVE: accept both plain and mTLS (migration mode)
---
# Authorization: only allow specific services to communicate
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"
- "cluster.local/ns/production/sa/admin-service"
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/orders/*"]# Linkerd: mTLS is enabled by default when injected
# Verify with:
# linkerd viz edges deployment -n production
#
# Output:
# SRC DST SRC_NS DST_NS SECURED
# api-gateway order-service production production √
# order-service payment-service production production √
# order-service inventory-svc production production √Observability: Metriken ohne Instrumentierung
Der Sidecar-Proxy sieht jede einzelne Anfrage und kann Metriken, Traces und Zugriffsprotokolle liefern, ohne dass sich am Anwendungscode etwas ändert.
# Istio gives you these metrics automatically:
# - Request rate (requests/second per service)
# - Error rate (percentage of 5xx responses)
# - Latency distribution (p50, p90, p99)
# - Connection pool metrics
# - Circuit breaker trip counts
# Query with Prometheus:
# Request rate:
# rate(istio_requests_total{destination_service="order-service"}[5m])
# Error rate:
# rate(istio_requests_total{destination_service="order-service",
# response_code=~"5.."}[5m])
# /
# rate(istio_requests_total{destination_service="order-service"}[5m])
# P99 latency:
# histogram_quantile(0.99,
# rate(istio_request_duration_milliseconds_bucket{
# destination_service="order-service"}[5m]))# Linkerd: built-in dashboard with golden signals
# Install viz extension:
# linkerd viz install | kubectl apply -f -
# linkerd viz dashboard
#
# Shows per-route metrics:
# Route Success Rate RPS P50 P99
# POST /api/orders 99.8% 245 12ms 89ms
# GET /api/orders/:id 100% 1.2k 3ms 15ms
# GET /api/orders 99.9% 890 8ms 45msCircuit Breaking und Retries
Resilienzmuster werden auf Infrastrukturebene konfiguriert, statt sie in jedem Dienst einzeln zu implementieren.
# Istio: circuit breaker configuration
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: payment-service
spec:
host: payment-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
http1MaxPendingRequests: 50
http2MaxRequests: 100
outlierDetection:
# Eject hosts that fail too frequently
consecutive5xxErrors: 3
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
---
# Istio: retry policy
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: payment-service
spec:
hosts:
- payment-service
http:
- route:
- destination:
host: payment-service
retries:
attempts: 3
perTryTimeout: 2s
retryOn: 5xx,reset,connect-failure,retriable-4xx
timeout: 10sIstio vs. Linkerd: die richtige Wahl treffen
## Linkerd
- Lighter resource footprint (~10MB RAM per sidecar)
- Simpler configuration — fewer knobs to turn
- Faster startup time
- Written in Rust (linkerd2-proxy)
- Best for: teams that want automatic mTLS,
observability, and basic traffic management
without deep configuration
## Istio
- More features (Wasm extensibility, complex routing)
- Heavier resource usage (~50MB+ RAM per sidecar)
- Steeper learning curve
- Envoy-based (C++)
- Best for: teams that need fine-grained traffic
control, complex authorization policies, or
multi-cluster mesh
## When to use neither:
- Fewer than 10 services
- Team doesn't have Kubernetes operational experience
- Networking concerns are handled well by application
libraries (if you already have consistent retry/TLS)
- Latency budget is extremely tight (sidecar adds
~1ms P99)Das Wichtigste in Kürze
Ein Service Mesh verlagert Retries, Timeouts, Verschlüsselung und Observability aus dem Anwendungscode in Sidecar-Proxys: Jeder Pod bekommt einen Proxy, der das Netzwerk transparent verwaltet, sodass Ihre Dienste mit localhost sprechen, während das Mesh alles jenseits der Pod-Grenze übernimmt. Fangen Sie mit mTLS und Observability an – das bringt sofortigen Nutzen, weil der gesamte Service-zu-Service-Traffic automatisch verschlüsselt wird und Sie pro Route Erfolgsraten, Latenz-Perzentile und Fehlerraten erhalten, ohne eine einzige Zeile Anwendungscode zu ändern. Traffic-Management ermöglicht Canary-Deployments und headerbasiertes Routing über Konfiguration statt Code – leiten Sie 5 % des Traffics auf eine neue Version, beobachten Sie die Fehlerraten im Mesh-Dashboard und befördern oder verwerfen Sie die Version, ohne neu zu deployen. Wählen Sie Linkerd für einfacheren Betrieb und geringeren Ressourcenverbrauch, Istio für komplexes Routing und feingranulare Autorisierungsrichtlinien, und keins von beiden, wenn Sie weniger als zehn Dienste haben – die operative Komplexität eines Service Mesh muss durch die Konsistenz- und Observability-Probleme gerechtfertigt sein, die es löst.
