Istio vs. Cilium: das Mesh aus dem Netzwerk gegen das Mesh aus der Service-Schicht.

eBPF-Ansatz gegen Envoy-Ansatz

Cilium verlagert L3/L4-Verarbeitung per eBPF direkt in den Linux-Kernel: kein Proxy im Datenpfad, sehr geringe Latenz, und Observability über Hubble bis auf Flow-Ebene. Für L7-Funktionen startet Cilium einen Envoy je Node, nicht je Workload. Das Ergebnis ist ein extrem effizienter Datenpfad, dessen L7-Steuerung aber gröber bleibt als bei einem dedizierten Workload-Proxy.

Istio arbeitet vollständig auf der Service-Ebene: Envoy je Pod im Sidecar-Modus, oder im Ambient-Modus ein ztunnel je Node für L4 plus Waypoint-Proxies für L7. Die Feature-Tiefe von Envoy steht damit pro Workload zur Verfügung: Routing bis auf Header und JWT-Claim, Mirroring, Fault Injection, feinjustierte Retries.

mTLS: ztunnel-Beta gegen Ambient-GA

Bei der Verschlüsselung trennen sich Reifegrade. Istios Ambient-Modus ist seit Version 1.24 (Nov. 2024) GA und liefert mTLS mit Workload-Identitäten ohne Sidecars. Cilium 1.19 (Feb. 2026) bringt eine eigene ztunnel-Variante für sidecarloses mTLS, allerdings als Beta. Produktionsreif und langjährig bewährt ist bei Cilium die transparente Verschlüsselung per WireGuard oder IPsec, seit 1.19 auch mit einem Strict-Encryption-Mode, der unverschlüsselten Verkehr konsequent unterbindet.

Für Audits ist der Unterschied relevant: Transparente Netz-Verschlüsselung und workload-identitätsbasiertes mTLS sind zwei verschiedene Nachweise. Wer Zero-Trust auf Identitätsebene belegen muss, bekommt das bei Istio heute in GA-Qualität, bei Cilium im ztunnel-Pfad noch im Beta-Stadium.

Kernel-Anforderungen und CNI-Kopplung

Cilium stellt Bedingungen an die Plattform: Kernel 5.10 oder neuer, idealerweise 6.1+, und Cilium als CNI. Das Service Mesh ist kein Aufsatz, sondern eine Funktion des CNI; ein Wechsel des CNI ist in Bestandsclustern ein Großprojekt. In gepflegten, selbst kontrollierten Umgebungen ist das kein Hindernis, bei konservativen Distributionen oder fremdverwalteten Nodes sehr wohl.

Istio ist CNI-agnostisch und läuft auf jeder gängigen Netzwerk-Schicht, auch auf Cilium selbst. Diese Kombination ist in der Praxis verbreitet: Cilium übernimmt CNI, NetworkPolicies und Node-Effizienz, Istio darüber die Service-Schicht mit mTLS, L7-Autorisierung und Traffic-Management. Die beiden Projekte sind also nicht nur Konkurrenten, sondern oft Schichten desselben Stacks.

Wann Cilium reicht

• Cilium ist bereits als CNI gesetzt, und das Team beherrscht den eBPF-Stack.
• Verschlüsselung auf L4 (WireGuard/IPsec, Strict-Mode) genügt als Sicherheits-Nachweis; workload-identitätsbasiertes mTLS ist kein hartes Muss.
• L7-Anforderungen bleiben bei Basis-Routing und L7-Netzwerk-Policies (HTTP, Kafka, DNS).
• Observability über Hubble deckt den Bedarf; ein separates Mesh-Telemetrie-System ist nicht gefordert.
• Die Kernel-Basis ist modern (5.10+, ideal 6.1+) und bleibt unter eigener Kontrolle.

Wann Istio nötig ist

• Feingranulare, auditierbare L7-Autorisierung bis auf Methode, Pfad und JWT-Claim ist gefordert, etwa unter BSI APP.4.4, NIS2 oder DORA.
• mTLS mit Workload-Identitäten muss heute in GA-Qualität laufen, nicht als Beta.
• Multi-Cluster-Topologien mit Mesh-Semantik (nicht nur Netz-Verbund) sind Kernanforderung.
• Traffic-Management in Envoy-Tiefe je Workload wird gebraucht: Canary-Routing, Mirroring, Fault Injection.
• Die Mesh-Entscheidung soll unabhängig von CNI und Kernel-Versionen bleiben.