Our Platform team have been pretty impressed with Envoy.
Have any of you had a similar experience?
13 Likes
Not over HTTPS?
envoy not be confused with envoi https://youtu.be/Gf0Cy9M1a0g 
2 Likes
Thanks for the fantastic article.
We wrote our own small control plane which would watch for changes in our Kubernetes infrastructure (such as an endpoint changing due to a new pod) and push changes to Envoy via the Cluster Discovery Service (CDS) API so it was aware of the new service.
We are thinking of doing the same thing in terms of a simple control plane that is Kubernetes aware. Have you given any thought to open sourcing your control plane? Almost all the companies that presented at EnvoyCon late last year have built their own control plane. It would be really helpful for some of these could be open sourced.
This is great, thanks for sharing your experience!
I was thinking to take a similar route on our Kube clusters but I’m still wondering how is this different form an Istio minimal installation https://github.com/istio/istio/blob/master/install/kubernetes/helm/istio/values-istio-minimal.yaml
sidecarInjectorWebhook: enabled: true
“Minimal” Istio installations are pretty heavyweight - they install 50-odd CRDs and a swathe of control plane components. Their default mTLS configuration breaks some pod healthchecks and they require an extremely permissive pod security policy (or a fairly experimental CNI plugin). If you don’t want all of Istio’s features, it’s probably easier to just deploy envoy.
Its an interesting switch but it reads like the choice was made before the comparison.
In that it pushes the benefits of envoy and the things its lacking, which would notably exist already in Linkerd2 (which is only mentioned by name at the start), but fails to explain the reasoning into why Linkerd2 wouldn’t have been a more obvious choice considering you’re already running v1.