It seems like it. Envoy was already competing with Linkerd, and "Istio uses an extended version of the Envoy proxy" (source: https://istio.io/docs/concepts/what-is-istio/overview.html). So it does that and more.

I was just wondering the same thing, since we use linkerd in production to handle thrift traffic to, from, and within our k8s clusters. But this statement from the examples page put me off a little: "If you use GKE, please ensure your cluster has at least 4 standard GKE nodes."

That suggestion is based on the requirements of the underlying bookinfo sample application and is not related to Istio itself.

Disclaimer: I work on Istio.

Thanks for the clarification!

Spectators love a fight. Ultimately it's more about using the right tool for your situation.

Istio and Linkerd are both very young and the adoption will be with those that really need their unique features. Most companies, including startups, in my experience are using roll-your-own routing/traffic mgt via Consul , or using NetflixOSS' stuff today and probably through 2018. Enterprises are buying API Gateways and the like too - IBM API Connect, MuleSoft, Apigee Edge, etc.

As for K8S vs Swarm, I rarely see Swarm in the wild, really. From my vantage point, the battle has been Kubernetes vs. roll-your-own-Docker vs. Mesos in startups using the pure open source. For enterprises paying a vendor, it's been IBM Bluemix vs. Pivotal Cloud Foundry vs. OpenShift, as they've been making more money out of all these container vendors combined (I work for Pivotal) - probably around $300m+ annually across the vendors. Some just use their native cloud's platform, like AWS container engine, etc.

The main X-factor will be serverless frameworks eventually taking over, possibly rendering today's battles over runtimes somewhat moot.

linkerd guys are going to need to find a new hobby.