I'm not seeing any benefits though, there are a lot of assumptions and emotional comments here not any hard evidence of it being a better solution.
There is actually a lack of it, there is only connotative evidence here in one comment that refers to "hey look linkerd does this at scale" that sounds nice, except that is not necessarily the point or the case.
How is having side-loaded proxies _better_ or more beneficial than having it separate? It doesn't appear to be discussed or mentioned in this thread, all of the arguments made for doing so are equally applicable to the separation of the proxy.
Early in the design, we have looked at various modes of proxy deployment and found that there are pros and cons for each. You are right that the sidecar model is not always the optimal choice, it's a trade-off (see the referenced document in the discussion). The sidecar is the least invasive approach with respect to Kubernetes and was the focus for the initial release. We'd be happy to hear arguments for a more centralized proxy model, and if needed invest effort into making it happen.
Resiliency: Centralized proxies can suffer from shared failure domain issues (especially when large number of configs, etc., are deployed).
Performance: Side-loaded proxies tend to perform better, in part because they deal with a subset of config.
Our choice of sidecar deployment was informed by on our (Google, Lyft) experiences with both centralized and sidecar models. However, that being said, Istio is not predicated on per-pod deployment.
Disclaimer: I work on Istio
1. https://groups.google.com/forum/m/#!msg/kubernetes-sig-netwo...