OMNI52
Service Mesh Cheatsheet OMNI52™ GmbH

Service Mesh
im Vergleich.

Tool-agnostisches Sheet: Istio (Sidecar + Ambient), Linkerd, Cilium Service Mesh. Welches Tool wann, mTLS-Implementierung, Multi-Cluster, Performance-Sizing, Migration ohne Produktions-Riss. Für Senior Platform Engineers und SREs.

Vorschau (1 Seite A4 quer + Brand-Rückseite)

Service Mesh Cheatsheet Seite 1: Tools-Vergleich, Traffic Management, Security
Service Mesh Cheatsheet Brand-Rueckseite: QR-Code, Lizenz, Trademarks

PDF herunterladen

Direkter Download, keine Mail-Adresse nötig. CC BY-SA 4.0 — kopieren, drucken, weiterverteilen ist ausdrücklich erlaubt, solange die Quellenangabe sichtbar bleibt.

Service Mesh Cheatsheet (PDF, ~100 KB)

Was drin steht

3 Patterns

Sidecar (Istio classic, Linkerd), eBPF/Datapath (Cilium), Sidecarless/Ambient (Istio 1.30+ GA). Auswahl-Matrix und Datapath-Latenz pro Pattern.

Traffic Management

Routing-APIs im Vergleich, Konvergenz auf Gateway API v1, Traffic-Split, Egress, Circuit-Breaking pro Tool.

Security & Identity

mTLS-Implementierung (SPIFFE bei Istio + Cilium, ServiceAccount bei Linkerd), AuthorizationPolicy-Vergleich, default-deny-Pattern.

Observability

Out-of-the-box-Stack je Tool, Pflicht-Metriken (Golden Signals + Saturation), Tracing-Header-Propagation als häufigste Falle.

Multi-Cluster

Istio Primary-Remote / Multi-Primary, Linkerd multicluster, Cilium ClusterMesh. Trust-Domain-Falle bei mTLS zwischen Clustern.

Migration

Sidecar → Ambient inkrementell, mTLS STRICT ohne Riss (PERMISSIVE-Brueck), Tool-Wechsel namespace-weise.

Cheatsheet im Volltext

Derselbe Inhalt wie im PDF — zum Mitlesen, Durchsuchen und direkten Kopieren der YAML-Snippets. Tool-agnostischer Vergleich: Istio (Sidecar + Ambient), Linkerd, Cilium. Stand 2026.07.

Tools im Vergleich

Die drei Patterns

Sidecar (Istio classic, Linkerd): Envoy/linkerd2-proxy neben jedem App-Container. Mature, transparent, Memory-Kosten.

Sidecar-less / eBPF (Cilium): L3/L4 im Kernel, Identity per Pod-Label, kein per-Pod-Datenpfad. L7 via Envoy als shared proxy (cilium-envoy DaemonSet).

Ambient (Istio 1.30+ GA): ztunnel als Node-Agent (L4/mTLS), Waypoint-Proxy on-demand (L7). Sidecarless ohne Kernel-Pfad.

Auswahl: was wann

Istio (Sidecar): grösstes Ecosystem, alle L7-Features, Multi-Cluster mature, hohe Memory-Last (50–150 MiB/Pod).

Istio (Ambient): deutlich weniger Overhead, weniger Migration-Reibung, Multi-Cluster jung.

Linkerd: schlank, Rust-Proxy, geringere CPU, weniger L7-Features (kein Wasm), kein Native Multi-Cluster ohne SMI.

Cilium Service Mesh: wenn CNI eh Cilium ist. Identity am Kernel, eBPF-Observability. L7-Features via Envoy-Sidecar (kein Sidecar-less L7).

Datapath / Hop-Latenz

Sidecar (Istio/Linkerd): ∼0,5–2 ms p99 pro Hop. Linkerd-Proxy ist 2–3× leichter als Envoy bei einfachem Routing.

Cilium L4: kernel-bypass-frei, Mikrosekunden-Range.

Ambient L4 (ztunnel): unter Sidecar bei reinem mTLS-Forwarding; Waypoint-Hop nur wenn L7-Policy greift.

Traffic Management

Routing-APIs im Vergleich

Istio: VirtualService + DestinationRule (eigene CRDs) — mächtig, aber zwei Konzepte: Match/Route vs. Subset/LB/CB.

Linkerd: HTTPRoute (Gateway API native), ServiceProfile für Per-Route-Settings.

Cilium: CiliumNetworkPolicy (L3–L7) + HTTPRoute (Gateway API) — Routing und Policy in einer CRD-Familie.

Konvergenz-Punkt: Gateway API v1.x. Alle drei implementieren sie. Reines Routing → Gateway API, proprietaere CRDs nur für Tool-Spezifika (z.B. Wasm).

# Gateway API HTTPRoute (alle drei verstehen das)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: {name: api}
spec:
  parentRefs: [{name: web-gw, namespace: ingress}]
  hostnames: ["api.example.com"]
  rules:
  - matches: [{path: {type: PathPrefix, value: /v1}}]
    backendRefs: [{name: api, port: 8080}]

Traffic-Split / Canary

Istio: VirtualService.http[].route[].weight.

Linkerd: HTTPRoute backendRefs[].weight.

Cilium: HTTPRoute mit weighted backends, alternativ mit Flagger/Argo-Rollouts auf allen drei.

Egress & Circuit-Breaking

Istio: ServiceEntry für externes DNS-Routing, DestinationRule.trafficPolicy.outlierDetection + Connection-Pool.

Linkerd: keine ServiceEntry-Aequivalent, kein eingebauter CB — Retries + Timeouts in ServiceProfile, Resilience-Pattern in der App.

Cilium: FQDN-Policy für Egress, keine native Outlier-Detection.

Security & Identity

mTLS & Identity

Istio: SPIFFE-Identity (spiffe://td/ns/X/sa/Y), istiod als CA, automatische Cert-Rotation. PeerAuthentication STRICT pro Namespace.

Linkerd: identity-Service als CA, Identity per ServiceAccount, mTLS by default ohne Opt-in (sobald beide Pods im Mesh sind).

Cilium: SPIFFE-Identity (1.14+), mTLS optional pro CiliumNetworkPolicy. Pod-Identity per Labels, nicht ServiceAccount.

Authorization-Policy

Istio: AuthorizationPolicy mit action: ALLOW | DENY | AUDIT | CUSTOM. JWT-Claims via when oder RequestAuthentication.

Linkerd: ServerAuthorization (per Server), HTTPRoute + AuthorizationPolicy. Schlanker, weniger Match-Optionen.

Cilium: L7-Rules in CiliumNetworkPolicy (HTTP-Method, Path, Header). JWT nicht nativ.

# Istio: default-deny + selektive Erlaubnis
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: {name: deny-all, namespace: prod}
spec: {}                       # leere Rules = deny
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: {name: allow-api, namespace: prod}
spec:
  selector: {matchLabels: {app: api}}
  rules:
  - from: [{source: {principals:
      ["cluster.local/ns/web/sa/frontend"]}}]

Observability

Was du out-of-the-box bekommst

Istio: Telemetry-API (Metriken, Tracing, Logs) mit Provider-Konfiguration. Prometheus + Kiali + Jaeger als Standard-Stack.

Linkerd: eingebautes Dashboard, Tap (live-traffic), Prometheus-Federation möglich. Tracing extern via OpenCensus.

Cilium: Hubble (eBPF-basiertes Flow-Logging), Hubble UI für Service-Map. Metriken in Prometheus, Tracing extern.

Pflicht-Metriken

Golden Signals: Requests/s, Errors/s, Latency-p50/p95/p99 (istio_requests_total, request_duration_milliseconds, linkerd: response_latency_ms_bucket).

Saturation: Sidecar-CPU/Memory, xDS-Push-Latenz (Istio: pilot_xds_push_time), Hubble: hubble_drop_total.

Tracing-Falle

Alle drei brauchen App-Header-Propagation (b3, traceparent). Ohne das zerreisst der Span-Tree beim ersten App-zu-App-Hop. Kein Mesh kann das auf L7 simulieren.

Multi-Cluster

Topologien

Istio: Primary-Remote (ein istiod, Workload-Cluster ohne Control-Plane) | Multi-Primary (istiod pro Cluster, gemeinsame Root-CA) | External Control-Plane. Pflicht: gemeinsame trustDomain oder trustDomainAliases.

Linkerd: multicluster extension, Gateway-basiert (Service-Mirror), eine TrustAnchor.

Cilium: ClusterMesh, eBPF-direct-routing zwischen Clustern (kein Gateway-Hop) bei Cilium-CNI auf allen Clustern.

Trust-Domain-Falle

Verschiedene Trust-Domains ⇒ mTLS-Reject zwischen Clustern. Migration: trustDomainAliases im Quell-Cluster setzen, bevor neue Workloads deployt werden, dann switchen.

Performance & Tuning

Sidecar-Sizing (Faustregel)

Envoy (Istio): 50–150 MiB pro Sidecar bei mittlerer Mesh-Grösse, abhängig von Sidecar-Scope. Pflicht: Sidecar-Resource pro Namespace, sonst bekommt jeder Proxy jede Service-Config (Push-Storm bei >500 Services).

linkerd2-proxy (Rust): 10–30 MiB.

ztunnel (Ambient): ∼1 ztunnel pro Node, deutlich unter Sidecar-Summe.

Push-Storm-Vermeidung

Istio: Sidecar.egress.hosts einschränken, optional ISTIO_DELTA_XDS=true (Delta-xDS).

Linkerd: Endpoints-Slicing, kein vergleichbares Push-Problem.

Cilium: keine xDS-Pushes (Kernel/Maps), aber cilium-agent-CPU bei vielen Identities prüfen.

Migration & Co-Existence

Sidecar → Ambient (Istio)

Per Namespace: Sidecar-Injection aus, Label istio.io/dataplane-mode: ambient. Waypoint-Proxy nur deployen, wenn der Namespace L7-Policies braucht (istioctl waypoint apply). Migration ist inkrementell, kein Big-Bang nötig.

mTLS-STRICT-Migration

Pattern für alle drei: (1) mTLS PERMISSIVE/optional aktivieren, beide Seiten injizieren. (2) Telemetry: alle Verbindungen mTLS? (Istio: security_policy aus Telemetry). (3) Erst dann STRICT.

Ohne Schritt 2 brechen Jobs, externe Health-Checks, Legacy-Clients.

Tool-Wechsel

Co-Existence im selben Cluster ist möglich, schmerzhaft: unterschiedliche Pod-Labels, getrennte Namespaces, kein Mesh-zu-Mesh-mTLS. In der Praxis: neuen Mesh in neuem Namespace einführen, Workloads namespace-weise migrieren, alten Mesh am Ende entfernen.

Anti-Patterns

Was du nicht tun solltest

Mesh für kleine Cluster (<20 Services): Komplexität > Nutzen, NetworkPolicy + cert-manager reichen.

mTLS STRICT vor Telemetry-Verify: bricht Jobs, externe Health-Checks, alte Clients.

EnvoyFilter / Wasm als Default-Tool (Istio): erst Telemetry-API + AuthorizationPolicy. EnvoyFilter bricht zwischen Istio-Minors.

Mesh-Routing auf Ingress-Layer: VirtualService an Mesh-Gateway ist ok; HTTPRoute am Ingress-Gateway + VirtualService Ost-West nicht mischen.

Tracing ohne App-Header-Propagation: Spans zerreissen.

Linkerd ohne ServerAuthorization: per-Server- Default ist allow-all — ein einfaches Pattern wie Istio's deny-all fehlt.

Cilium L7-Policy auf Multi-Tenant-Cluster ohne eBPF-Auditing: debugging schwer, Hubble-Logs aktivieren.

Aus der OMNI52 Cheatsheet-Fabrik

Verwandte Sheets in dichter Senior-Qualität:
istio-cheatsheet.de — Istio in der Tiefe
kubernetes-cheatsheet.de — Kubernetes-Plattform-Layer
k8s-cheatsheet.de — Kubernetes (Kurz-Domain)

Lizenz & Weiterverteilung

CC BY-SA 4.0. Du darfst dieses Cheatsheet kopieren, weiterverteilen, ausdrucken und in eigenen Materialien zitieren. Bedingung: Quellenangabe „Service Mesh Cheatsheet — OMNI52 GmbH, service-mesh-cheatsheet.de“ bleibt sichtbar, und abgeleitete Werke stehen unter der gleichen Lizenz (Share-Alike).

Nicht erlaubt: Logo, Marken oder den Eindruck zu vermitteln, dass der Inhalt von dir/euch stammt oder dass OMNI52 GmbH die Weiterverwendung sponsort.

Volltext der Lizenz: creativecommons.org/licenses/by-sa/4.0/deed.de.

Istio is a trademark of The Linux Foundation. Linkerd, Cilium and eBPF are trademarks of their respective owners. OMNI52™ is a trademark of OMNI52 GmbH (filed, not yet registered). This website is operated by OMNI52 GmbH and is not affiliated with, endorsed by, or sponsored by The Linux Foundation, the CNCF, the Istio project, Buoyant, Inc., the eBPF Foundation, Isovalent, or any of the named projects.