Unabhängige Analyse · Stand: Juli 2026
Dieses Journal vergleicht die relevanten Service-Mesh-Lösungen für Kubernetes ohne Werbesprache: keine Affiliate-Links, keine Vendor-Gelder, quartalsweise gepflegt. Jede Aussage ist mit Versionsstand und Quelle belegt.
Istio 1.30.2 Linkerd 2.20 Cilium 1.19 Gateway API v1.6.0
Die Matrix
Istio tritt zweimal an, weil Sidecar- und Ambient-Modus operativ zwei verschiedene Systeme sind. Auf schmalen Displays scrollt die Tabelle horizontal; die Kriterien-Spalte bleibt stehen.
| Kriterium | Istio (Sidecar) | Istio (Ambient) | Linkerd | Cilium Service Mesh |
|---|---|---|---|---|
| Architektur / Datenebene | Envoy-Proxy je Pod. Maximale Isolation, größte Reife. | ztunnel je Node (L4), Waypoint-Proxy nur bei Bedarf (L7). GA | Rust-Microproxy je Pod; native Sidecars GA seit 2.20. | eBPF im Kernel (L3/L4), Envoy je Node (L7). CNI und Mesh in einem. |
| mTLS & Zero-Trust | mTLS STRICT mit Workload-Identitäten; Referenz für Zero-Trust-Nachweise. | mTLS im ztunnel, STRICT ab Tag eins, ohne Sidecar. GA | mTLS by default; seit 2.19 mit Post-Quantum-Krypto. | Transparente Verschlüsselung (WireGuard/IPsec), Strict-Mode seit 1.19; sidecarloses mTLS via ztunnel Beta. |
| L7-Traffic-Management | Volle Envoy-Tiefe: Routing, Retries, Timeouts, Mirroring, Fault Injection. | Gleiches Feature-Set, sobald ein Waypoint gesetzt ist. | Solide Kernfunktionen; bewusst weniger Feature-Tiefe als Envoy. | Basis-L7 über den Node-Envoy; weniger granular pro Workload. |
| Autorisierung (feingranular) | AuthorizationPolicies bis auf Methode, Pfad und JWT-Claim; Default-Deny etabliert. | L4-Policies im ztunnel; L7-Policies brauchen einen Waypoint. | Policies auf Service- und Routen-Ebene; weniger ausdrucksstark. | Netzwerk-Policies inklusive L7 (HTTP, Kafka, DNS); stark, aber netzwerkzentriert. |
| Multi-Cluster | Ausgereift: Multi-Primary und Primary-Remote in Produktion bewährt. | Multi-Network-Multicluster erst seit März 2026 Beta. | Gateway-basiertes Service-Mirroring; gut für einfache Topologien. | ClusterMesh verbindet Cluster-Netze; Mesh-Feature-Tiefe begrenzt. |
| Observability | Metriken, Traces und Access Logs je Workload; Kiali-Integration. | L4-Telemetrie im ztunnel; L7-Telemetrie mit Waypoint. | Goldene Metriken out of the box; schlankes eigenes Dashboard. | Hubble: Flow-Sichtbarkeit vom Paket bis L7. |
| Ressourcen-Overhead | Am höchsten: ein Proxy je Pod skaliert mit der Pod-Zahl. | Deutlich reduziert; L7-Kosten nur dort, wo Waypoints laufen. | Sehr schlanker Proxy; Control-Plane-RAM in 2.20 um 85 % gesenkt. | Gering: Datenpfad im Kernel, Envoy nur je Node. |
| Betriebsaufwand | Hoch: Injection, Proxy-Lifecycle und Upgrades je Workload. | Spürbar gesenkt; dafür ein neues Betriebsmodell zu lernen. | Bewusst einfach; die geringste Lernkurve im Feld. | Mit dem CNI verschmolzen; verlangt Kernel- und eBPF-Know-how (Kernel 5.10+, ideal 6.1+). |
| Lizenz- / Vendor-Situation | Apache 2.0, CNCF-Projekt, breite Anbieter-Basis. | Wie Sidecar: Apache 2.0, CNCF-Projekt. | Code Apache 2.0; Stable-Releases seit Feb. 2024 nur über Buoyant (gratis unter 50 Mitarbeitenden). | Apache 2.0, CNCF-Projekt; Isovalent gehört seit 2024 zu Cisco. |
| Compliance-Eignung (BSI APP.4.4, NIS2, DORA) | Referenzprofil: mTLS STRICT plus Default-Deny, auditierbar bis L7. | Gleichwertig, sofern L7-Kontrollen über Waypoints abgedeckt sind. | mTLS-Nachweis solide; feingranulare L7-Autorisierung begrenzt. | Starke Netztrennung; Verschlüsselungs-Nachweis je nach Modus verschieden. |
| Gateway-API- / GAMMA-Support | Gateway API seit Istio 1.22 für Ingress und Mesh (GAMMA). | Durchgängig; Waypoints werden über Gateway-Resources konfiguriert. | Routing wird über Gateway-API-Typen (HTTPRoute) konfiguriert. | Gateway API für Ingress; Mesh-Routing folgt dem eigenen Policy-Modell. |
| Lösung | Status Juli 2026 | Einordnung |
|---|---|---|
| Consul | Consul 1.22 (Dual-Stack, Multi-Port-Services); HashiCorp seit Feb. 2025 Teil von IBM. | Stärke in Multi-Runtime- und VM-Welten; im reinen Kubernetes-Umfeld selten erste Wahl. |
| Kong Mesh / Kuma | Kong Mesh 2.13 LTS bzw. 2.14, basiert auf Kuma und Envoy. | Nische; relevant vor allem in bestehenden Kong-Landschaften. |
| AWS App Mesh | EOL 30.09.2026 Neukunden-Stopp bereits seit Sept. 2024. | Kein Zukunftspfad. AWS nennt ECS Service Connect, VPC Lattice und ALBs als Migrationsziele. |
Wann passt was
Eine Matrix beantwortet nicht, was zu deinem Team passt. Diese fünf Profile decken die häufigsten Ausgangslagen ab, inklusive der Empfehlung, gar kein Mesh einzuführen.
Profil A
Empfehlung Istio
Wer Auflagen aus NIS2, DORA oder BSI APP.4.4 nachweisen muss und multi-team sowie multi-cluster arbeitet, braucht feingranulare Autorisierung, ausgereiftes Multi-Cluster und auditierbare Policies. Das liefert heute nur Istio in voller Tiefe. Der Preis ist Betriebskomplexität; Ambient hat sie deutlich gesenkt.
Profil B
Empfehlung Cilium Service Mesh
Läuft Cilium ohnehin als CNI und genügen transparente Verschlüsselung plus Basis-L7, ist der Schritt zum Cilium Service Mesh der kleinste. Beachte: das sidecarlose mTLS (ztunnel) ist in 1.19 noch Beta, und der Kernel muss mitspielen (5.10+, ideal 6.1+).
Profil C
Empfehlung Linkerd, mit Vertragsfrage
Linkerd bleibt das Mesh mit der geringsten Lernkurve und sehr kleinem Overhead. Vorher klären: Stable-Releases gibt es seit Feb. 2024 nur über Buoyant Enterprise (kostenlos nur für Firmen unter 50 Mitarbeitenden). Diese Vendor-Beziehung gehört in die Risikobewertung, bevor die erste Policy geschrieben wird.
Profil D
Empfehlung (Noch) kein Mesh
Bei überschaubarer Service-Anzahl reichen Gateway API, NetworkPolicies und TLS am Ingress oft aus. Ein Mesh lässt sich später nachrüsten; ein zu früh eingeführtes Mesh kostet dagegen sofort Betriebskraft. Das ist die unbequemste, aber häufig richtige Antwort.
Profil E
Handlungspflicht Migration bis 30.09.2026
AWS App Mesh erreicht am 30.09.2026 das End of Support; Neukunden werden seit Sept. 2024 nicht mehr angenommen. Wer heute noch darauf steht, migriert entweder auf die AWS-eigenen Pfade (ECS Service Connect, VPC Lattice, ALBs) oder nutzt den Umzug, um auf ein portables Mesh wie Istio zu wechseln, je nachdem, ob Kubernetes-Portabilität ein Ziel ist.
Die drei Duelle
Drei Vergleiche in der Tiefe, in der Entscheidungen tatsächlich fallen: Architektur, Betrieb, Lizenzfragen und die Fälle, in denen der jeweils andere Kandidat gewinnt.
Duell 01
Feature-Tiefe gegen Einfachheit, Envoy gegen Rust-Microproxy, und die Buoyant-Stable-Frage fair erklärt.
Zur AnalyseDuell 02
eBPF gegen Envoy, ztunnel-Beta gegen Ambient-GA, und die Frage, wann das CNI-Mesh schlicht reicht.
Zur AnalyseDuell 03
Das Istio-interne Duell: GA-Status, Ressourcen, Migrationspfad und der Leitfaden für Bestand und Neubau.
Zur AnalyseMethodik
Bewertet wird ausschließlich anhand offizieller Dokumentation, Release-Notes und nachvollziehbarer Primärquellen, gepinnt auf konkrete Versionsstände. Adoptionszahlen ohne belastbare Primärquelle lassen wir weg. Die Betreiberin dieses Journals ist ein Beratungshaus mit Istio-Schwerpunkt; wie wir trotzdem werkzeug-ehrlich bleiben, steht offen in der Methodik.
Umsetzung
Für Enterprise Service Mesh Engineering, von der Architektur bis zum auditierbaren Betrieb, betreibt die OMNI52 GmbH die spezialisierte Beratung istio-consulting.de. Der Vergleich hier bleibt davon unabhängig; die Empfehlung ergibt sich aus deinem Profil, nicht aus unserem Portfolio.
Readiness-Gespräch anfragenStand: Juli 2026 · Versionsstichtage: Istio 1.30.2 (24.06.2026), Linkerd 2.20 (23.06.2026), Cilium 1.19 (Feb. 2026) · Quartalsweise Pflege, nächste planmäßige Prüfung: Oktober 2026.