Istio vs. Linkerd: Feature-Tiefe gegen Einfachheit.

Architektur: Envoy gegen Rust-Microproxy

Istio setzt auf Envoy, den mächtigsten und zugleich schwersten Proxy im Cloud-Native-Umfeld. Im klassischen Sidecar-Modus läuft er neben jedem Pod, im Ambient-Modus (GA seit Istio 1.24) übernimmt ein ztunnel je Node die L4-Ebene und optionale Waypoint-Proxies die L7-Verarbeitung. Damit hat Istio heute zwei Datenebenen zur Auswahl, was die Architekturfrage differenzierter macht als noch vor zwei Jahren.

Linkerd geht den entgegengesetzten Weg: ein bewusst minimaler, in Rust geschriebener Microproxy je Pod, der genau eine Aufgabe hat. Seit Linkerd 2.20 sind native Kubernetes-Sidecars GA, was alte Schmerzpunkte wie die Start-Reihenfolge von Containern und Job-Workloads sauber löst. Die Datenebene bleibt damit konzeptionell einfach: kein Tuning-Universum, wenige Stellschrauben, dafür auch weniger Ausdruckskraft.

mTLS und Sicherheit

Beide Meshes verschlüsseln Service-zu-Service-Verkehr per mTLS und rotieren Zertifikate automatisch. Linkerd aktiviert mTLS ohne Zutun und hat mit Version 2.19 (Okt. 2025) Post-Quantum-Krypto in die Datenebene gebracht, ein bemerkenswert früher Schritt.

Der Unterschied liegt eine Ebene höher: bei der Autorisierung. Istio erlaubt AuthorizationPolicies bis auf HTTP-Methode, Pfad und JWT-Claim, kombiniert mit einem etablierten Default-Deny-Muster. Genau diese Feingranularität verlangen Audits in regulierten Umgebungen (BSI APP.4.4, NIS2, DORA) regelmäßig als Nachweis. Linkerd autorisiert auf Service- und Routen-Ebene; das ist für viele Teams ausreichend, aber spürbar weniger ausdrucksstark.

Betrieb und Overhead

Linkerds größtes Asset ist die Lernkurve: Installation, Upgrade und Debugging sind auf ein kleines Platform-Team zugeschnitten. Der Proxy-Footprint ist sehr gering, und Linkerd 2.20 hat den RAM-Bedarf der Control Plane um 85 % gesenkt und ein rate-limit-bewusstes Load Balancing eingeführt.

Istio im Sidecar-Modus ist das andere Extrem: ein Envoy je Pod skaliert die Kosten mit der Pod-Zahl, und Upgrades fassen jede Workload an. Der Ambient-Modus hat diesen Aufwand deutlich gesenkt, weil Sidecars entfallen und L7-Kosten nur dort anfallen, wo Waypoints laufen. Ehrlich bleibt trotzdem: Istio ist die größere Maschine mit mehr beweglichen Teilen, auch im Ambient-Modus.

Die Buoyant-Stable-Frage, fair erklärt

Seit Februar 2024 veröffentlicht das Linkerd-Projekt keine Open-Source-Stable-Artefakte mehr. Wichtig für die faire Einordnung: Der Quellcode bleibt vollständig Apache-2.0-lizenziert, es geht um die gebauten, getesteten Release-Artefakte. Stabile Releases gibt es über Buoyant Enterprise; kostenlos ist das nur für Unternehmen mit weniger als 50 Mitarbeitenden.

Das ist kein Grund für Alarmismus, aber ein Fakt für die Risikobewertung: Wer Linkerd im Enterprise-Maßstab stabil betreiben will, plant eine Vendor-Beziehung zu Buoyant ein, mit Vertrag, Preisverhandlung und Abhängigkeit von einem einzelnen Anbieter. Istio kennt diese Konstellation nicht: Apache 2.0, CNCF-Projekt und eine breite Basis konkurrierender Anbieter und Distributionen.

Wann Linkerd die bessere Wahl ist

• Ein kleines Platform-Team will mTLS, goldene Metriken und zuverlässiges Routing, ohne eine Envoy-Konfigurationswelt zu lernen.
• Der Ressourcen-Overhead muss minimal sein, etwa bei vielen kleinen Pods oder knappen Node-Budgets.
• Die Autorisierungs-Anforderungen bleiben auf Service- und Routen-Ebene; niemand verlangt L7-Policies bis auf JWT-Claims.
• Das Unternehmen hat weniger als 50 Mitarbeitende und bekommt Buoyant-Stable-Releases kostenlos, oder die Vendor-Beziehung ist bewusst akzeptiert.
• Multi-Cluster beschränkt sich auf einfache Topologien, die das Gateway-basierte Service-Mirroring gut abdeckt.

Wann Istio die bessere Wahl ist

• Compliance-Auflagen verlangen feingranulare, auditierbare L7-Autorisierung und ein durchgesetztes Default-Deny.
• Multi-Cluster- und Multi-Team-Setups brauchen ausgereifte Topologien (Multi-Primary, Primary-Remote) und Mandantentrennung.
• Traffic-Management in Envoy-Tiefe ist gefordert: Mirroring, Fault Injection, feinsteuerbare Retries und Timeouts.
• Die Organisation will keinen Single-Vendor-Pfad für Stable-Releases; Istios breite Anbieter-Basis ist hier das Gegenmittel.
• Gateway API und GAMMA sollen durchgängig getragen werden, von Ingress bis Mesh-Routing.