Service Mesh und Verkehrspolitik

1) Warum Service Mesh benötigt wird

• Standard-Sicherheit: mTLS, automatische Ausgabe/Rotation von Zertifikaten, Service-Identitäten.
• Verkehrspolitik: L7-Routing, Kanarien-/AV-Tests, Degradation und Nachhaltigkeit.
• Beobachtbarkeit: Metriken, Protokolle, Traces, goldene Signale bei jedem Anruf.
• Operationen: Einheitliche Richtlinien für alle Sprachen/Frameworks.

Unterschied zum API-Gateway: Gateway - Nord-Süd-Perimeter; mesh - Ost-West innerhalb eines Clusters/einer Organisation. Sie arbeiten oft zusammen.

2) Architektur: Ebenen und Muster

Datenebene: Sidecar-Proxy (Envoy/Linkerd-proxy/haproxy), der den Herd-/VM-Verkehr abfängt.
Control Plane: verteilt Konfigurationen (Routen, Richtlinien, Zertifikate), speichert den Status, veröffentlicht Service-Discs.
Identität: in der Regel SPIFFE ID und automatische X.509-Zertifikate (SPIRE/embedded CA).
Ein-/Ausstiegspunkte: ingress/egress-gateway zur Überwachung von Grenzflüssen.
Implementierungsmodi: sidecar für jeden unter; Per-Node/Ambient-Moden in neuen Implementierungen.

3) Sicherheitspolitik und Zero-Trust

1. mTLS by default: Verschlüsselung und gegenseitige Authentifizierung von servis↔servis.

• AuthN: Vertrauen Sie nur Identitäten, die von CA mesh'a (SPIFFE) ausgestellt wurden.
• AuthZ: deklarative Regeln „wer kann zu wem und wie“ (RBAC/ABAC).

3. Isolierung und egress-Steuerung:

• Zulässige Domänen/Subnetze; erzwungener Ausstieg über das egress-gateway.
• Direkte Ergebnisse von Pods blockieren.

4. Rotation der Geheimnisse: kurzlebige Zertifikate, automatische Rekonfiguration des Proxys.

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

yaml apiVersion: security. istio. io/v1beta1 kind: AuthorizationPolicy metadata: { name: billing-allow, namespace: prod }
spec:
selector: { matchLabels: { app: billing } }
rules:
- from:
- source: { principals: ["spiffe://corp. local/ns/prod/sa/inventory"] }
to:
- operation: { ports: ["8080"], methods: ["POST"], paths: ["/proto. Billing/"] }

4) Verkehrspolitik: Nachhaltigkeit und Routing

4. 1 Timeouts und Retrays

Timeouts: Stellen Sie sicher, dass Sie auf den Anruf setzen (connect/read/overall).
Retries: nur für idempotente Operationen; backoff + jitter; Per-try-Timeout-Limits.

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: orders }
spec:
hosts: ["orders"]
http:
- route:
- destination: { host: orders, subset: v1, port: { number: 8080 } }
timeout: 5s retries:
attempts: 2 perTryTimeout: 2s retryOn: "5xx,connect-failure,reset"

4. 2 Circuit Breaker и outlier detection

CB: Schränkt gleichzeitige Anfragen/Verbindungen ein und schützt Upstreams.
Outlier: wirft „schlechte“ Instanzen auf Fehler/Latenz.

yaml apiVersion: networking. istio. io/v1beta1 kind: DestinationRule metadata: { name: orders }
spec:
host: orders trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1024, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xxErrors: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

4. 3 Kanarische und unter Bedingungen

Weighted: Aufteilung des Verkehrs nach Gewichten v1/v2.
Header-based: Flags/Cookies/tenant → in eine neue Version verschoben werden.
Session affinity: Hash nach Schlüssel (ordentlich mit Skalierung).

yaml http:
- match: [{ headers: { "x-experiment": { exact: "new" } } }]
route: [{ destination: { host: orders, subset: v2 } }]
- route:
- destination: { host: orders, subset: v1, weight: 90 }
- destination: { host: orders, subset: v2, weight: 10 }

4. 4 Fault Injection und Degradation

Latenz-/Fehlerinjektion für Stabilitätstest und SLO.

yaml fault:
delay: { fixedDelay: 300ms, percentage: { value: 10 } }
abort: { httpStatus: 503, percentage: { value: 1 } }

5) Netzwerkgrenzen: ingress/egress und externe Dienste

Ingress-Gateway: einziger Einstiegspunkt für externe Kunden in mesh; Integration mit WAF/OIDC/ratelimits.
Egress-Gateway: zentraler Ausgang mit Liste der erlaubten Hosts, TLS-Inspektion, Telemetrie-Aufzeichnung.
ServiceEntry: deklariert externe SNIs/Hosts als Teil von mesh (Richtlinien und mTLS-Origination sind anwendbar).

yaml apiVersion: networking. istio. io/v1beta1 kind: ServiceEntry metadata: { name: payments-external }
spec:
hosts: ["api. payments. com"]
ports: [{ number: 443, name: https, protocol: TLS }]
resolution: DNS location: MESH_EXTERNAL

6) Multi-Cluster, Multi-Netzwerk und Hybrid

Gemeinsame PKI/Trust-Domain: einheitliche SPIFFE-Identitäten zwischen Clustern.
Endpoint discovery: Servicebälle zwischen Regionen; lokale Priorität und Failover.
Zonale Isolation: Perregionale Politik, Grenzen und Prioritäten.
VM in mesh: Verbinden Sie Legacy/Stateful-Systeme mit Proxys und denselben Richtlinien.

7) Beobachtbarkeit, SLO und Betrieb

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
Zugriffsprotokolle: strukturell, mit 'traceparent', 'user/tenant', 'response _ flags'.
Tracing: Auto-Injection Header (W3C Trace Context), Sampling, Spans auf Hop-Ebene.
SLO: Ziele für p99/Fehler auf der Route (service→service).
Alerts: Anstieg von '5xx', Wachstum von 'reset', 'outlier _ ejections', Abbau von mTLS (handshake failures).

8) Leistung und Kosten

• Körnigkeit: Einbeziehung der Politik, wo sie benötigt wird; Schalten Sie nicht überall schwere Filter ein.
• Pools: Teilen Sie die Pfade (kritisch/Hintergrund) in verschiedene Routen und Limits auf.
• Profiling: p99 auf „kalten“ Strecken, Umfang der Telemetrie (Rate-Limit-Logs/Traces).
• Betrachten Sie ambient/sidecarless Modi, wenn unterstützt und passen die Anforderungen.

9) Sicherheit und Compliance

Minimal notwendiger Zugang: Richtungen und Methoden explizit zulassen.
Richtlinien zu Neymspaces/Tenanten: Netzwerk-/Autorisierungsgrenzen.
Schlüsselrotation/SA: geplant und Notfall; kurze TTL-Zertifikate.
PII/Secrets: Maskierung in Logs/Traces; Verschlüsselung auf Draht/in Ruhe.
Audit: Wer, wann und welche Politik geändert hat; zweistufige Apruvas.

10) Integration mit K8s-Ebene

Mesh-Richtlinien ergänzen und ersetzen NetworkPolicy nicht.
In ingress/egress-gateway können Sie PodSecurity/PSA mit einer niedrigeren Ebene aufhängen.
NRA/Auto-Scaling: Retrays/SVs berücksichtigen - sie verändern die Belastung.
Releasepläne: Kanariengewichte über VirtualService + automatische Förderung durch SLO.

11) Checkliste Umsetzung

• Vertrauensgrenzen definiert und STRICT mTLS aktiviert.
• AuthZ-Richtlinien enthalten: Wer zu wem, an welchen Ports/Methoden.
• Timeouts/retries und outlier detection konfiguriert, idempotente Pfade definiert.
• Kanarienrouten und Rollback-Plan sind vorgeschrieben; fault-injection - nur in nicht-prod.
• Externe Abhängigkeiten über egress-gateway und ServiceEntry werden übernommen.
• Metriken, Protokolle, Tracks konfiguriert; Dashboards und Alerts auf der p99/5xx/CB.
• Kontingente/Limits per-tenant/namespace sind vorgesehen.
• Vorbereitete Runbooks: Zertifikatsleck, CA-Fehler, Abbau des Upstreams, massive 503/RESET.
• Multi-Cluster-Plan (allgemeine PKI, lokale Prioritäten, DR-Szenarien).
• Testtage (Spieltage): Fallkontrollebene, Stop-Sidecar, Netzbruch, „giftiger“ Upstream.

12) Anti-Muster

Mesh „überall und sofort“ ohne Streckeninventur und SLO → teure Komplexität.
Die Standard-Retrays für alle Methoden → doppelte Effekte und Lawinenverkehr.
Deaktivierte mTLS „vorübergehend“ → bleibt für immer.
Egress ohne Gateway → Datenleck/nicht gemeldete Abhängigkeiten.
Eine globale Richtlinie für alle Dienste → falsche Sicherheit und falsche Positive.
Zero Observability: Mesh aktiviert, aber keine Metriken/Traces sammeln - wir verlieren an Bedeutung.

13) Schnelle Rezepte

Linkerd: mTLS und Server-Policy aktivieren

yaml apiVersion: policy. linkerd. io/v1beta1 kind: Server metadata: { name: billing, namespace: prod }
spec:
podSelector: { matchLabels: { app: billing } }
port: 8080 apiVersion: policy. linkerd. io/v1beta1 kind: ServerAuthorization metadata: { name: billing-allow-inventory, namespace: prod }
spec:
server: { name: billing }
client:
meshTLS:
identities: ["inventory. prod. serviceaccount. identity. linkerd. cluster. local"]

Consul (L7 intent + splitter)

hcl
Kind = "service-router"
Name = "orders"
Routes = [{
Match { HTTP { PathPrefix = "/v1" } }
Destination { Service = "orders" }
}]
Kind = "service-splitter"
Name = "orders"
Splits = [
{ Weight = 90, ServiceSubset = "v1" },
{ Weight = 10, ServiceSubset = "v2" }
]

14) FAQ

Braucht ein kleines Team Mesh?
Wenn 3-5 Dienste - öfter nicht. Beginnen Sie mit einem guten Ingress und Nachhaltigkeitsbibliotheken. Verbinden Sie mesh, wenn Sie mTLS-Standard, einheitliche Richtlinien und Ablaufverfolgung benötigen, ohne den Code zu ändern.

Wie kontrolliert man die Kosten?
Messen Sie Lieferscheine (CPU/RAM/Latenz) auf kritischen Pfaden, deaktivieren Sie zusätzliche Filter, reduzieren Sie das Volumen der Protokolle/Traces, verwenden Sie Modi ohne Sidecar, wo es sicher ist.

Können Mesh und manuell konfigurierte Proxies gestört werden?
Ja, aber vermeiden Sie doppeltes Routing/doppelte Retrays. Ein Ort ist wahr - Steuerebene.

Was ist wichtiger: Sicherheit oder Leistung?
Die Standardeinstellung ist Sicherheit (mTLS, AuthZ). Die Leistung wird durch Tuning von Verbindungspools, Outlier-Erkennung, Zielrouten erreicht.

15) Ergebnisse

Service Mesh verwandelt das Netzwerk zwischen den Diensten in eine programmierbare Schicht mit einheitlichen Richtlinien: Verschlüsselung und Identitäten, Feinrouting und Resilienz, Telemetrie und Quoten. Beginnen Sie mit kritischen Pfaden, schalten Sie STRICT mTLS und explizite AuthZ ein, stellen Sie Timeouts/Retrays/CBs ein, steuern Sie egress, messen Sie p99 und 5xx, verbringen Sie Spieltage. Dann wird Mesh ein Verstärker der Zuverlässigkeit und Geschwindigkeit von Releases sein, keine Quelle von Überraschungen.