OMNI52
Service Mesh Cheatsheet OMNI52™ GmbH
Neu bei Istio, Linkerd und CiliumGCP-Hosting endet, Scream-Tests laufen · Große Ambient-Meshes reißen das gRPC-Limit früher · Nicht bereite Endpunkte gehen standardmäßig an EnvoyAlle Neuerungen →

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 (2 Seiten A4 quer + Brand-Rückseite)

Service Mesh Cheatsheet Seite 1: Tools im Vergleich, Traffic Management, Security & Identity, Observability, Multi-Cluster, Performance & Tuning
Service Mesh Cheatsheet Seite 2: Migration & Co-Existence, Anti-Patterns

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, GA seit 1.24). Auswahl-Matrix, Datapath und Ressourcen je Pattern.

Traffic Management

Routing-APIs im Vergleich, Konvergenz auf Gateway API v1 mit GAMMA für Ost-West, Traffic-Split, Egress, Circuit-Breaking pro Tool.

Security & Identity

mTLS-Implementierung (SPIFFE bei Istio, ServiceAccount bei Linkerd, Cilium: Mutual Auth abgekündigt, ztunnel als Nachfolger), 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-Brücke), 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: Oktober 2026 (Edition 2026.10).

Tools im Vergleich

Die drei Patterns

Sidecar (Istio classic, Linkerd): Envoy/linkerd2-proxy neben jedem App-Container, heute als native Sidecar (Linkerd 2.20: Default; Istio: Default ENABLE_NATIVE_SIDECARS=auto, aktiv ab Kubelet 1.33). 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, GA seit 1.24): ztunnel als Node-Agent (L4/mTLS), Waypoint-Proxy on-demand (L7). Sidecarless ohne Kernel-Pfad.

Auswahl: was wann

Stand 10/2026: Istio 1.31, Cilium 1.20, Linkerd edge-26.9.x (Meilenstein 2.20).

Istio (Sidecar): größtes Ecosystem, alle L7-Features, Multi-Cluster mature, ein Envoy je Pod.

Istio (Ambient): Multi-Cluster nur Multi-Primary mit Multi-Network (Beta seit 1.29, Single-Network ungetestet), keine VMs, kein SPIRE.

Linkerd: schlank, Rust-Proxy, kein Wasm, kein eigener Ingress. Multi-Cluster per Extension (Gateway, Flat Network, Federated).

Linkerd, Beschaffungs-Kriterium: das Open-Source-Projekt liefert seit 02/2024 keine Stable-Artefakte mehr. Frei sind nur die wöchentlichen edge-Releases; Stable-Builds kommen von Vendoren (Buoyant Enterprise for Linkerd). Für regulierte Umgebungen ist das eine Vertrags-, keine Technikfrage.

Cilium Service Mesh: wenn CNI eh Cilium ist. Identity am Kernel, eBPF-Observability. L7 über den Envoy pro Node, nicht pro Pod.

Datapath / Ressourcen

Sidecar: zwei Proxy-Durchläufe je Request (Client- und Server-Pod). Ambient: zwei ztunnel-Hops (Quell- und Ziel-Node), Waypoint nur als zusätzlicher Hop, wenn L7 greift. Cilium: L3/L4 ohne Proxy, L7-Regeln leiten über den Node-Envoy.

Istio-Benchmark (1.24, 1000 req/s, 1 KB): Sidecar ∼0,20 vCPU und 60 MB, Waypoint ∼0,25 vCPU und 60 MB, ztunnel ∼0,06 vCPU und 12 MB.

Traffic Management

Routing-APIs im Vergleich

Istio: VirtualService + DestinationRule (eigene CRDs), mächtig, aber zwei Konzepte: Match/Route vs. Subset/LB/CB. In Ambient ist VirtualService nur Alpha, dort HTTPRoute.

Linkerd: HTTPRoute/GRPCRoute; Retries und Timeouts per Annotation (retry.linkerd.io/http, timeout.linkerd.io/request) seit 2.16. ServiceProfile nur noch Legacy.

Cilium: HTTPRoute/GRPCRoute inkl. GAMMA, nur Producer-Routes (Route im Namespace des Service), Feintuning per CiliumEnvoyConfig. Policy getrennt in CiliumNetworkPolicy (L3–L7).

Konvergenz-Punkt: Gateway API v1.x, Ost-West als GAMMA (Route mit Service als parentRef). CRDs sind clusterweit: Istio 1.31 dokumentiert v1.6.0, Cilium 1.20 (mit Gateway-API-Support) verlangt ≥ v1.6.1, Linkerd 2.20 ist bis v1.5.1 freigegeben.

# GAMMA-HTTPRoute (Ost-West; Istio Ambient: nur mit Waypoint)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: {name: api, namespace: prod}
spec:
  parentRefs:
  - {group: "", kind: Service, name: api, port: 8080}
  rules:
  - matches: [{path: {type: PathPrefix, value: /v2}}]
    backendRefs: [{name: api-v2, port: 8080}]
  - 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 externe Ziele, outlierDetection und connectionPool in DestinationRule.trafficPolicy, ab 1.31 meshweite Baseline per meshConfig.defaultTrafficPolicy.

Linkerd: EgressNetwork-CRD (2.17+) für Egress-Sicht und -Policy. Circuit-Breaking (2.13+) per Service-Annotation balancer.linkerd.io/failure-accrual.

Cilium: FQDN-Policy (toFQDNs) für Egress. Circuit-Breaking nur über rohe Envoy-Konfiguration (CiliumClusterwideEnvoyConfig).

Security & Identity

mTLS & Identity

Istio: SPIFFE-Identity (spiffe://td/ns/X/sa/Y), istiod als CA, automatische Cert-Rotation. PeerAuthentication STRICT pro Namespace. FIPS 140-3 ab 1.31: COMPLIANCE_POLICY=fips-140-3 (TLS 1.2+/AES-GCM, P-256/P-384), davor als FIPS-Profil nur fips-140-2.

Linkerd: linkerd-identity als CA, Identity per ServiceAccount, mTLS by default ohne Opt-in (sobald beide Pods im Mesh sind). Trust Anchor aus linkerd install läuft nach 365 Tagen ab: selbst erzeugen, Issuer per cert-manager rotieren.

Cilium: Identity per Pod-Labels, nicht ServiceAccount. Mutual Auth (SPIFFE, Beta seit 1.14) ist seit 1.20 abgekündigt. Nachfolger: ztunnel-Encryption (Beta seit 1.19, Namespace-Label io.cilium/mtls-enabled=true, nicht mit ClusterMesh).

Authorization-Policy

Istio: AuthorizationPolicy mit action: ALLOW | DENY | AUDIT | CUSTOM. JWT: RequestAuthentication validiert, AuthorizationPolicy erzwingt (requestPrincipals, when). In Ambient greifen L7-Regeln nur am Waypoint (targetRefs). Ingress-Gateways umgehen den Waypoint per Default: L7-Policies am Waypoint greifen für Nord-Süd-Traffic erst mit istio.io/ingress-use-waypoint=true am Service (am Namespace ab 1.25).

Linkerd: AuthorizationPolicy auf Server oder HTTPRoute, ServerAuthorization ist die ältere Form. Default-deny per Annotation config.linkerd.io/default-inbound-policy: deny.

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: viz-Extension (Dashboard, tap, stat); deren Prometheus hält nur 6 h, produktiv extern. Tracing per OpenTelemetry (2.17+), Collector muss im Mesh laufen.

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, istio_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 zerreißt 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. Ambient: nur Multi-Primary.

Linkerd: multicluster extension mit Service-Mirror, Gateway-basiert, Flat Network ohne Gateway (2.14+) oder Federated Services (2.17+), ein gemeinsamer Trust Anchor.

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. Ab Istio 1.31 lässt sich in AuthorizationPolicy direkt per source.trustDomains / notTrustDomains filtern.

Performance & Tuning

Sidecar-Sizing

Envoy (Istio): Speicher wächst mit der Zahl der Listener, Cluster und Routen, also mit dem Sidecar-Scope (Messwerte: Datapath-Box). Pflicht: Sidecar-Resource pro Namespace, sonst bekommt jeder Proxy die Config aller Services.

linkerd2-proxy: keine veröffentlichten Richtwerte, selbst messen.

ztunnel (Ambient): ein Pod je Node (DaemonSet), Kosten skalieren mit Nodes statt Pods.

Push-Storm-Vermeidung

Istio: Sidecar.egress.hosts einschränken, ab 1.31 auch per Ausschluss (*/* plus ~ns1/*). Delta-xDS ist seit 1.22 Default. Ambient ab ∼40.000 Workloads: ISTIO_GPRC_MAXRECVMSGSIZE an istiod anheben.

Linkerd: kein Full-Push. Jeder Proxy abonniert je Ziel einen Stream (destination.Get) und bekommt nur Deltas aus EndpointSlices. Engpass ist der Speicher des Destination-Controllers bei hohem Pod-Churn (2.20: in Einzelfällen fast 85 % weniger).

Cilium: L3/L4 ohne xDS (BPF-Maps), L7-Konfiguration bekommt der Node-Envoy per xDS vom Agent. cilium-agent-CPU bei vielen Identities prüfen.

Migration & Co-Existence

Sidecar → Ambient (Istio)

Per Namespace, umkehrbar: bei L7-Bedarf Waypoint deployen und per istio.io/use-waypoint aktivieren, dann Label istio.io/dataplane-mode=ambient, Injection-Label entfernen, zuletzt kubectl rollout restart. Vorher VirtualService → HTTPRoute, L7-AuthorizationPolicy per targetRefs an den Waypoint. Mit L7-Policies kein Zero-Downtime: zwischen Löschen und Neuanlage greifen sie nicht. Sidecar-Clients umgehen den Waypoint, EnvoyFilter geht dort nicht.

mTLS-STRICT-Migration

Istio: PERMISSIVE, dann prüfen: reporter="destination", connection_security_policy!="mutual_tls" muss 0 sein, erst dann STRICT.

Linkerd: Default all-unauthenticated, Ziel all-authenticated per config.linkerd.io/default-inbound-policy; wirkt erst beim Pod-Neustart.

Cilium (ztunnel): kein Permissive-Modus, Verkehr zwischen enrollten und nicht enrollten Pods geht nicht. Kommunikationspartner gemeinsam enrollen.

Ohne Prüfschritt (Istio) 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: das neue Mesh in neuen Namespaces einführen, Workloads namespace-weise migrieren, das alte 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.

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

VirtualService und HTTPRoute für dieselbe Workload: in Ambient ausdrücklich nicht unterstützt (undefiniertes Verhalten). Pro Workload eine API.

Linkerd ohne Default-Policy: Cluster-Default ist all-unauthenticated. Ein Server ohne Regeln blockt dagegen alles (accessPolicy: deny), Probes nur automatisch erlaubt, solange keine Route am Server hängt.

Cilium-L7-Policy ohne Hubble: der Audit-Mode deckt nur L3/L4 ab, L7-Denies sieht man erst in den Hubble-L7-Flows.

Linkerd neben Gateway API v1.6: der Standard-Channel serviert TCPRoute/TLSRoute nur noch als v1. Linkerd liest TCPRoute nur als v1alpha2 und überspringt sie bis auf eine Log-Warnung, TLSRoute erst ab edge-26.8.4. Die CRDs aus linkerd-crds (v1.1.1; nur mit installGatewayAPI=true, seit 2.19 aus) blockt die safe-upgrades-Policy der Gateway API.

Verwandte Cheatsheets

Ebenfalls von OMNI52:
istio-cheatsheet.de, Istio in der Tiefe
cilium-cheatsheet.de, Cilium in der Tiefe
kubernetes-cheatsheet.de, Kubernetes-Plattform-Layer

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.