Linkerd vs. Istio: Mesh-Vergleich fürs Interview

“Welches Service Mesh würdest du empfehlen?” ist eine Fangfrage. Die ehrliche Antwort beginnt mit einer Gegenfrage: Was sind eure konkreten Anforderungen?

Beide Projekte lösen ähnliche Grundprobleme — mTLS zwischen Services, Observability auf Layer 7, Traffic-Splitting — aber mit grundverschiedenen Philosophien, und die fangen schon beim Proxy an.

Zwei Proxys, zwei Weltanschauungen

Linkerd setzt auf einen eigens entwickelten Micro-Proxy in Rust (linkerd2-proxy), der genau eine Aufgabe hat: Linkerds Datenpfad. Er ist nicht konfigurierbar im Sinne von “schreib deine eigene Routing-Logik”, dafür klein, schnell und mit minimalem Memory-Footprint — typischerweise ein Bruchteil dessen, was ein Envoy-Sidecar belegt. mTLS ist ab Installation an, ohne dass du eine einzige Policy schreibst: Workloads mit injiziertem Proxy sprechen untereinander automatisch verschlüsselt, die Identität kommt aus dem ServiceAccount.

Istio benutzt Envoy, einen General-Purpose-Proxy mit riesigem Funktionsumfang: feingranulares L7-Routing, Fault Injection, JWT-Validierung am Proxy, Rate-Limiting-Integration, WASM-Erweiterungen. VirtualServices, DestinationRules und AuthorizationPolicies geben dir Kontrolle über praktisch jedes Detail — wie das konkret aussieht, steht in Istio: mTLS und Traffic Management. Der Preis ist ein größeres CRD-Portfolio, mehr Ressourcenverbrauch und eine Lernkurve, die real ist.

Auch die Control Planes spiegeln das wider. Linkerds besteht aus einer Handvoll Komponenten — Destination (Service Discovery und Routing-Infos), Identity (stellt die mTLS-Zertifikate aus), Proxy-Injector (Sidecar-Injection per Webhook) — und die Observability-Werkzeuge wie das Dashboard und linkerd viz tap (Live-Mitschnitt von Requests eines Workloads) kommen als optionale Extension dazu. Istiod bündelt zwar inzwischen alles in einem Binary, aber die Konfigurationsfläche dahinter bleibt um ein Vielfaches größer.

Diese Architektur-Entscheidung erklärt fast alle Unterschiede: Linkerd kann weniger, weil sein Proxy bewusst weniger kann. Istio kostet mehr, weil Envoy alles können soll.

Die Faktoren, an denen du die Entscheidung festmachst

Anforderungsprofil: Braucht ihr mTLS, goldene Metriken (Success Rate, Latenz, RPS pro Service) und einfache Retries/Timeouts? Linkerd liefert das mit minimalem Konfigurationsaufwand. Braucht ihr Header-basiertes Routing, Egress-Kontrolle, JWT-Prüfung am Mesh-Rand oder Multi-Cluster-Traffic-Steuerung auf Anwendungsebene? Dann seid ihr im Istio-Territorium.

Teamkapazität: Linkerd kann ein kleines Platform-Team nebenbei betreiben; die Anzahl der Konzepte ist überschaubar, und linkerd check diagnostiziert die häufigsten Probleme selbst. Istio braucht realistisch jemanden, der Envoy-Debugging beherrscht und Upgrades mit Canary-Revisionen plant. “Wir installieren Istio, weil wir es vielleicht mal brauchen” ist das teuerste Mesh-Argument überhaupt.

Ressourcen und Latenz: Linkerds Rust-Proxy ist messbar sparsamer bei Memory und CPU pro Pod und addiert auch bei der Tail-Latenz weniger. Bei 50 Pods ist das egal, bei 2000 ist es ein Budget-Posten — Sidecar-Overhead skaliert schließlich mit der Pod-Anzahl, nicht mit dem Traffic. Beide Projekte arbeiten an Sidecar-Alternativen — Istio mit dem Ambient Mode (per-Node-ztunnel für L4, optionale Waypoints für L7) —, was die Rechnung verschiebt, aber das Grundmuster bleibt: Istio kauft Features mit Komplexität.

Lizenz- und Distributionsfragen: Hier hat sich bei Linkerd etwas getan, das in Interviews gern getestet wird. Buoyant, die Firma hinter Linkerd, liefert seit 2024 keine fertigen Stable-Releases mehr frei aus — stabile Builds gibt es über die kommerzielle Buoyant-Distribution, das Open-Source-Projekt selbst veröffentlicht Edge-Releases. Der Code bleibt offen (Linkerd ist CNCF-Graduated), aber wer im Unternehmen Stable-Artefakte will, muss das Thema Lizenzkosten oder Selbst-Builds einplanen. Das gehört in jede ehrliche Empfehlung.

Der Punkt, der in Interviews unterscheidet

Ein Mesh installieren ist ein Nachmittag. Es über Jahre gesund zu halten, ist die eigentliche Arbeit: Control-Plane-Upgrades synchron zu Kubernetes-Versionen, Proxy-Versionen in allen Pods aktuell halten (jeder Sidecar-Update heißt Pod-Restart!), Zertifikats-Trust-Anchors rotieren, und bei jedem mysteriösen Latenz-Problem ist das Mesh ab sofort Verdächtiger Nummer eins. Diese Dauerlast ist bei beiden real, bei Istio größer.

Deshalb gehört vor die Tool-Frage die Bedarfsfrage. Wenn ich “Welches Mesh?” im Interview höre, frage ich zurück: “Habt ihr heute konkrete Pain Points — Compliance-Anforderung für Service-zu-Service-Verschlüsselung, fehlende einheitliche Metriken, Canary-Bedarf — oder ist das ein Nice-to-have?” Wer keinen konkreten Pain Point nennen kann, braucht wahrscheinlich noch kein Mesh. Für reines Nord-Süd-Traffic-Management reicht oft schon die Gateway API, und mTLS für eine Handvoll Services geht auch ohne Mesh.

Die Interview-Antwort, die funktioniert, hat drei Teile: erst die Anforderung qualifizieren, dann die Architektur-Differenz erklären (Spezial-Proxy vs. Envoy, und was daraus folgt), dann eine konkrete Empfehlung mit Trade-off — etwa: “Für mTLS plus Observability bei einem Drei-Personen-Platform-Team würde ich Linkerd nehmen und auf L7-Routing-Features verzichten; sobald JWT-Validierung am Proxy oder komplexes Traffic-Splitting gefordert ist, würde ich den Istio-Betriebsaufwand akzeptieren.” Das zeigt Urteilsvermögen statt Tool-Fandom.

Beide Meshes kannst du dir systematisch erarbeiten: Lernpfad Linkerd und Lernpfad Istio.