eBPF-based observability vs sidecar proxies in K8s service mesh

We're evaluating whether to move from an Istio sidecar model to an eBPF-based approach (Cilium + Tetragon) for service mesh observability. The resource overhead of sidecars at our scale (~400 pods) is becoming non-trivial — each proxy eats ~150MB RSS. For those who've made the transition: - What observability gaps did you hit with eBPF that sidecars covered? - How did you handle mTLS enforcement without the sidecar's explicit proxy layer? - Any gotchas with Cilium's kube-proxy replacement in production? We're on EKS 1.28, kernel 5.15+. Looking for war stories, not vendor slides.