Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Was ist Service Mesh und wann wird es benötigt

Service Mesh ist eine Schicht der Netzwerk-Daten-/Verwaltungsebene, die End-to-End-mTLS, Routing, Fehlertoleranz und Überwachbarkeit zwischen den Diensten bietet, ohne den Code neu zu schreiben.

• Standard-Sicherheit (Zero-Trust, Service-Identitäten, Zugriffsrichtlinien).
• Verkehrsführung (Canary/Blue-Green, A/B, Shadowing).
• Zuverlässigkeit (Retrays, Timeouts, Circuit Breaking).
• Beobachtbarkeit (Metriken, Protokolle, Traces).
• Operative Standardisierung (Richtlinien als Code, GitOps).

• Viele Microservices mit Polylingualität und mTLS-Anforderung.
• Sie benötigen erweiterte Routing-/Experimentierskripte, ohne die Anwendung zu ändern.
• Es gibt Auditanforderungen/Richtlinien auf Netzwerkebene.

2) Istio vs Linkerd - ein kurzer Vergleich

3) Architektur und Bereitstellungsmodelle

3. 1 Sidecar mesh (klassisch)

Jeder Pod erhält ein Proxy-Sidecar.
Vorteile: Reife, volle L7-Kontrolle.
Nachteile: CPU/RAM Overhead, Komplikation von Deploys/Debugging.

3. 2 Istio Ambient Mesh

ztunnel (L4) auf dem Knoten + Wegpunktproxies (L7) bei Bedarf.
Vorteile: niedrigere Kosten und Komplexität, schrittweise Einbeziehung von L7.
Nachteile: Neuere, nicht alle L7-Fälle sind ohne waypoint erhältlich.

4) Identität und mTLS (Zero-Trust)

4. 1 SPIFFE/SPIRE und Zertifikate

Jeder Vorkloade ist eine SPIFFE ID zugeordnet: 'spiffe ://cluster. local/ns/NS/sa/SA`.
Authentifizierung: Gegenseitiges TLS zwischen Diensten.
Schlüsselrotation - automatisch (kurze TTL).

4. 2 Istio (PeerAuthentication + DestinationRule)

yaml apiVersion: security. istio. io/v1 kind: PeerAuthentication metadata: { name: default, namespace: payments }
spec:
mtls: { mode: STRICT }
apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments-dr, namespace: payments }
spec:
host: payments. svc. cluster. local trafficPolicy:
tls: { mode: ISTIO_MUTUAL }

4. 3 Linkerd - mTLS Standard

Aktiviert nach 'linkerd install' + 'linkerd inject'.
Cluster - eigener Trust-Anchor, automatische Rotation.

5) Verkehrsmanagement

5. 1 Istio: VirtualService (Routen, Kanarienvögel)

yaml apiVersion: networking. istio. io/v1 kind: VirtualService metadata: { name: payments }
spec:
hosts: ["payments"]
http:
- route:
- destination: { host: payments, subset: v1 } # stable weight: 90
- destination: { host: payments, subset: v2 } # canary weight: 10 retries: { attempts: 2, perTryTimeout: 300ms }
timeout: 2s

yaml apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments }
spec:
host: payments subsets:
- name: v1 labels: { version: v1 }
- name: v2 labels: { version: v2 }
trafficPolicy:
loadBalancer: { simple: LEAST_CONN }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

5. 2 Linkerd: ServiceProfile + TrafficSplit

yaml apiVersion: linkerd. io/v1alpha2 kind: ServiceProfile metadata:
name: payments. default. svc. cluster. local spec:
routes:
- name: POST /withdraw condition:
method: POST pathRegex: "/withdraw"
isRetryable: true timeout: 2s apiVersion: split. smi-spec. io/v1alpha2 kind: TrafficSplit metadata: { name: payments }
spec:
service: payments backends:
- service: payments-v1 weight: 90
- service: payments-v2 weight: 10

6) Ingress/Egress und API-Gateways

Istio Gateway (ingress/egress) - Verwaltet eingehenden/ausgehenden Datenverkehr, TLS-Terminierung, mTLS-Passthrough.
Linkerd arbeitet mit bestehenden Ingress-Controllern (NGINX/Contour/Traefik); egress - über NetworkPolicy/egress-gateway-Muster.
egress-Richtlinien: Domain-Whitelists, SNI-Richtlinien, Verbot des direkten Internets.

7) Autorisierung und Politik

7. 1 Istio AuthorizationPolicy (RBAC/ABAC)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: allow-withdraw, namespace: payments }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://cluster. local/ns/api/sa/gateway"]
to:
- operation:
methods: ["POST"]
paths: ["/withdraw"]
when:
- key: request. auth. claims[role]
values: ["cashout"]

7. 2 Linkerd policy (server + serverauthorization)

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

8) Beobachtbarkeit und Telemetrie

8. 1 Metriken

Istio Telemetry API → Prometheus: `istio_requests_total`, `istio_request_duration_milliseconds_bucket`, `istio_tcp_received_bytes_total`.
Linkerd viz: `request_total`, latency p50/p95/p99, `success_rate`.

8. 2 Traces und Protokolle

Durchbrechen Sie den W3C Trace Context.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - über Sidecar-Logger/App-SDK.

8. 3 Instanzen (Beispiele)

Fügen Sie' trace _ id 'zu den Histogrammen der Dauer für „Sprung-zu-Spur“ hinzu.

9) Rate Limits, WAF, benutzerdefinierte Filter

Istio: EnvoyFilter/WASM für lokale Rate Limits, eksternal-Rate-Limit Service (Redis) sowie WAF-Logik (Lua/WASM).
Linkerd: begrenzte native Unterstützung; rate limit - auf ingress/gateway level.

10) Multi-Cluster

Istio: Ost-West-Gateway, gemeinsame PKI oder Trust-Bundle, Service-Discovery über ServiceEntry, Federation.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-cases: Asset-Asset-Regionen, Traffic-Lokalisierung, Federed Zero-Trust.

11) Leistung und Kosten

Sidecar Mesh: Übermäßige CPU/RAM pro Pod, erhöhte Latenz (normalerweise + 1-3 ms pro Hop im Steady-State).
Ambient (Istio): weniger Verbrauch für L4, L7 wird punktweise eingeschaltet.
Linkerd: Der leichtgewichtige Proxy ist in der Regel weniger overhead, aber weniger extreme L7-Fähigkeiten.
Praxis: Messen Sie p95/CPU vorher/nachher, halten Sie SLO-Tore auf Abbau.

12) Sicherheit

mTLS überall, kurze TTL, automatische Rotation.
Politik als Code (OPA/Gatekeeper, Kyverno) für Verbote' authorizationPolicy: ALLOW all'.
Geheimnisse - durch CSI/Vault, nicht in Manifesten.
Egress-Steuerung: deny-by-default, explizite Allow-Listen.
Separate Treuhanddomänen für Umgebungen (prod/stage).

13) Integration mit Releases und SLO-Gating

Canary/Blue-Green werden durch Mesh-Routen realisiert (siehe Beispiele).
Analyse von Metriken (Prometheus/SpanMetrics) in Argo Rollouts AnalysisTemplate - Trampen/Rollback bei Burn-Rate/p95/5xx.
Anmerkungen zu den Veröffentlichungen in Grafana: Vergleich 'version = stable' canary'.

14) Anti-Muster

Mesh „überall und sofort“ einzuschalten, → den Schock der Infrastruktur.
Ignorieren Sie die Kardinalität der Metriken/Protokolle vom Proxy → Überlastung des TSDB/Logstores.
Belassen Sie mTLS im PERMISSIVE/opaque Modus für immer.
Versuchen Sie, eine komplexe WAF/Geschäftslogik innerhalb von EnvoyFilter anstelle eines Gateways/einer Anwendung zu erstellen.
Keine egress-Richtlinie - Internetlecks/Umgehung der Compliance.
Die Proxies mit': 15000 'debug sind nach außen offen.

15) Implementierung Checkliste (0-60 Tage)

0-15 Tage

Modellauswahl: Sidecar vs Ambient (Istio )/Linkerd nach Lastprofil.
Aktivieren Sie mTLS STRICT, die grundlegenden Autorisierungsrichtlinien für 1-2 kritische Dienste.
Basisrouten (Timeout/Retries), Dashboards RED/SLO.

16-30 Tage

Canary/TrafficSplit, outlier detection/circuit breaking auf heißen Pfaden.
OTEL Integration: Wege + Beispiele; alertas burn-rate.
Egress-Gateways und Domain-Whitelists; deny-by-default.

31-60 Tage

Multi-Cluster-Link (falls erforderlich), Federation Trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-Day: Simulation eines Vorfalls und Rollback von Routen/Richtlinien.

16) Reifegradkennzahlen

Die mTLS-Abdeckung (STRICT/auto-rotate) ≥ 95% der Dienste.
Der Traffic-Anteil durch kanarische/progressive Releases ≥ 80%.
Durchschnittlicher Overhead p95 <+ 5% der Basislinie (nach Optimierung).
0 offene egress ohne Erlaubnis, 100% der Dienste mit grundlegenden AuthZ.
RCA „von der Grafik zur Strecke“ ≤ 2 Minuten (p50).

17) Beispiele für „Politik als Code“

Gatekeeper (Verbot PERMISSIVE in der Produktion)

yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sIstiomTLSStrict metadata: { name: deny-permissive-prod }
spec:
match:
kinds: [{ apiGroups: ["security. istio. io"], kinds: ["PeerAuthentication"] }]
namespaces: ["prod-"]
parameters:
allowedModes: ["STRICT"]

Kyverno (erforderliche Labels für VS/DR)

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: require-mesh-labels }
spec:
rules:
- name: vs-dr-labels match:
any:
- resources:
kinds: ["VirtualService","DestinationRule"]
validate:
message: "owner and service labels required"
pattern:
metadata:
labels:
owner: "?"
service: "?"

18) Betriebsberatung

Versionieren Richtlinien und Routen (semver), Förderung durch GitOps.
Proxy-Beobachtbarkeit: einzelne „proxy saturation“ Dashboards (CPU/heap, retries, 429/503).
Budget der Kardinalität: Die Bezeichnungen 'route', 'code', 'destination' sind nur schablonenhaft.
Netzwerklimits/Kontingente pro Namespace-Ebene (NetworkPolicy/LimitRange).
Team Dokumentation: runbook „wie man mTLS Routen/Richtlinien/Schlüssel rollt“.

19) Schlussfolgerung

Istio und Linkerd lösen eine Aufgabe - die Standardisierung der Sicherheit, Zuverlässigkeit und Sichtbarkeit der dienstübergreifenden Kommunikation -, tun dies jedoch mit unterschiedlichen Tiefen und Betriebskosten.

Sie brauchen reiche L7-Fähigkeiten und flexible Richtlinien - nehmen Sie Istio (betrachten Sie Ambient, um Rechnungen zu reduzieren).
Sie brauchen Einfachheit und einen kleinen Overhead - nehmen Sie Linkerd.

Welches Mesh Sie auch wählen: Aktivieren Sie mTLS standardmäßig, steuern Sie das Routing als Code, verknüpfen Sie Metriken mit Traces, schließen Sie egress und fügen Sie SLO-Gatting zu Releases hinzu. Dann wird die Netzwerkschicht keine „Black Box“ mehr sein und zu einem vorhersehbaren Instrument für Nachhaltigkeit und Veränderungsgeschwindigkeit werden.