networking
Service Mesh Overhead Calculator
Calculate the RAM, CPU, and latency overhead of running Istio, Linkerd, or Cilium as a service mesh. Compare sidecar vs eBPF approaches per pod and cluster-wide.
Comparing Service Mesh Overhead: Istio vs Linkerd vs Cilium
Service meshes provide mTLS, observability, traffic management, and retries — but at a resource cost that scales with pod count.
Architecture Comparison
| Mesh | Approach | Sidecar | Overhead Model |
|---|---|---|---|
| Istio | Envoy proxy | Yes (per pod) | O(pods) |
| Linkerd | micro-proxy | Yes (per pod) | O(pods), smaller |
| Cilium | eBPF | No | O(nodes) |
Istio Overhead
Each pod gets an injected Envoy container:
- ›Idle: ~50 MB RAM, 0.01 vCPU
- ›Under load: up to 300 MB RAM, 0.5 vCPU
- ›Control plane (istiod): ~1 GB RAM
Linkerd Overhead
Linkerd's micro-proxy (Rust, not C++) is significantly lighter:
- ›Idle: ~10 MB RAM per sidecar
- ›Control plane: ~250 MB RAM total
Cilium eBPF Approach
No sidecar = no per-pod overhead. eBPF programs run in kernel space:
- ›Agent per node: ~100–200 MB RAM
- ›WireGuard encryption: adds ~0.05 vCPU per node
- ›Hubble (observability): +80 MB per node
Decision Guide
- ›Need full traffic management (circuit breaking, retries, canary): Istio
- ›Want mTLS + observability with minimal overhead: Linkerd
- ›Already using Cilium as CNI, want lowest overhead: Cilium service mesh mode
Key Terms
Full glossary →Linkerd
A lightweight service mesh for Kubernetes. Linkerd provides automatic mTLS between pods, observability dashboards, and traffic management without sidecar overhead.
mTLS (Mutual TLS)
A protocol where both client and server authenticate each other using TLS certificates. In Kubernetes, service meshes like Linkerd and Istio use mTLS for pod-to-pod encryption.
CNI (Container Network Interface)
A standard interface for Kubernetes networking plugins. CNI plugins (Flannel, Calico, Cilium) handle pod-to-pod networking, IP address management, and network policies.
Ingress Controller
A Kubernetes component that manages external HTTP/S access to cluster services. Common implementations include NGINX Ingress, Traefik, and HAProxy Ingress.
Frequently Asked Questions
How much RAM does an Istio Envoy sidecar use?
An idle Envoy sidecar uses ~40–60 MB RAM. Under load (thousands of req/sec) it can reach 150–300 MB. For a 50-pod cluster: 50 × 50 MB = 2.5 GB of RAM just for sidecars, before your application workloads.
Is Cilium really zero-overhead?
Not zero, but much lower. Cilium runs eBPF programs in the Linux kernel (no sidecar process), so there's no per-pod memory overhead. Instead, there's a DaemonSet agent per node (~100–200 MB RAM per node). For 50 pods on 5 nodes: ~750 MB total vs Istio's ~2.5 GB.
Why does Istio add latency?
Every request passes through two Envoy sidecars — one on the sender side and one on the receiver side. Each Envoy adds ~1–2 ms per hop for TLS termination, header manipulation, telemetry, and policy enforcement. On service chains (A→B→C→D), this compounds.
Can I use Cilium for mTLS without sidecars?
Yes — Cilium supports transparent mTLS via WireGuard encryption and its own certificate management. Since Kubernetes 1.26, Cilium + SPIFFE/SPIRE provides sidecar-free mTLS that's equivalent to Istio's security model with a fraction of the overhead.
Related Tools
Cilium Resources
Calculate Cilium CNI agent RAM and CPU requirements per node. Includes Hubble observability overhead, WireGuard encryption, and BPF map memory for network policies.
K8s Bandwidth
Estimate internal pod-to-pod bandwidth, external egress, and recommended NIC size for your Kubernetes cluster. Accounts for service mesh overhead and Hetzner egress pricing.
K8s Node Sizing
Calculate the right number and size of Kubernetes worker nodes for your workloads. Supports Hetzner Cloud and Vultr with verified pricing.