Estimate memory overhead added by an Istio Envoy sidecar per pod.
Every pod in an Istio mesh runs an Envoy sidecar proxy alongside the application container, and its memory usage grows with the number of open connections, configured routes/clusters, and request throughput it must buffer and process. Formula: memory_MB = base(50) + 0.5 × connections + 2 × routes + 0.1 × RPS, applied per pod and then multiplied across the mesh. This overhead is in addition to the application container's own memory and must be budgeted into node capacity planning.
Per-sidecar memory
memory_MB = 50 + 0.5 × connections + 2 × routes + 0.1 × RPS
Total mesh memory
total_mesh_MB = memory_per_sidecar × pod_count
Each route/cluster the sidecar knows about (driven by the number of services in the mesh and how Istio's Sidecar/DestinationRule scoping is configured) adds to the xDS configuration Envoy holds in memory — large meshes without scoped sidecars can see this dominate memory usage.
Use Istio's Sidecar resource to scope each pod's visible service registry to only what it needs, reducing route/cluster count; also tune concurrency and connection pool settings, and consider ambient mesh mode which removes per-pod sidecars entirely.
No — they're reasonable planning heuristics based on commonly observed Envoy behavior. Validate against your own `istio-proxy` container's actual memory usage (via `kubectl top` or Prometheus) and recalibrate the constants for your workload.
No — this estimates only the per-pod data-plane sidecar memory. istiod's own memory scales with mesh size (services, endpoints, and config objects) and should be sized separately.