Die drei Patterns
Sidecar (Istio classic, Linkerd, Kuma, Consul):
Envoy bzw. 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.10.x (Meilenstein 2.20), Kuma 3.0, Consul 2.1.
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), kein Primary-Remote, 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.
Kuma (CNCF Sandbox, Apache 2.0): Envoy-Sidecar auf
Kubernetes und VMs, Multi-Zone mit globaler Control Plane. mTLS per
MeshIdentity/MeshTrust (SPIFFE-IDs, eigene
CA oder SPIRE), Routing per MeshHTTPRoute oder
HTTPRoute/GRPCRoute. 3.0 (15.10.2026)
entfernt die Legacy-Policies, Mesh.mtls und das
eingebaute Gateway.
Consul (HashiCorp, BUSL 1.1 seit 1.17, kein
CNCF-Projekt): Envoy-Sidecar auf Kubernetes, VMs, Nomad und ECS.
Zugriff per Intentions (L4 oder L7), Routing per Config-Entries
service-router, -splitter,
-resolver; Gateway-API-Ressourcen nur am API-Gateway
dokumentiert.
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.
Projekte und Quellen
- Istio (CNCF Graduated): istio.io/latest/docs · github.com/istio/istio · cncf.io/projects/istio
- Linkerd (CNCF Graduated): linkerd.io/2-edge · github.com/linkerd/linkerd2 · cncf.io/projects/linkerd
- Cilium (CNCF Graduated): docs.cilium.io, Service Mesh · github.com/cilium/cilium · cncf.io/projects/cilium
- Kuma (CNCF Sandbox): kuma.io/docs · github.com/kumahq/kuma · cncf.io/projects/kuma
- Consul (HashiCorp, kein CNCF-Projekt): developer.hashicorp.com/consul · github.com/hashicorp/consul
- Gateway API (Kubernetes SIG Network): gateway-api.sigs.k8s.io, GAMMA · github.com/kubernetes-sigs/gateway-api
- Envoy (CNCF Graduated, Proxy in Istio, Cilium, Kuma und Consul): envoyproxy.io/docs · github.com/envoyproxy/envoy · cncf.io/projects/envoy