The industry appears to have chosen the de facto standards for containers (docker) and orchestration (kubernetes) but this doesn't appear to be the case for the options for implementing a service mesh.
Are there some good standards to follow when choosing from the available options for implementing a service mesh?
In general you are going to find the best support for “an X” on Kubernetes by looking at what “X” projects are members of the same software foundation so governed by the same organisation. Kubernetes is part of the Cloud Native Computing Foundation so you should study what “Xs” it offers. In the case of service mesh CNCF has Linkerd.
At this point in time though as other answers point out there is a lot of momentum around itsio. This uses Envoy which is a top level CNCF project to actually shape the traffic between your containers. That is reassuring as we would not expect k8s to suddenly break Envoy at a minor release so we might expect itiso to be able to keep up to date with k8s. That’s a guess though.
You should also consider whether there is a “service mesh like” tech for that stack you use already. If for example you are a Java shop doing microservice like a lot of big firms then you are probably using spring boot and spring cloud. In which case spring cloud already had a bunch of components that offer the same benefits as a mesh but do it in a more traditional way (libraries embeds in your app). By way of example here is an architecture demo of how to port a java spring cloud airline booking microservices demo app onto openshift Kubernetes. In that doc they mention itsio but actually they stick with spring cloud ribbon, eureka and zuul. Spring cloud also has distributed tracing etc.
This then leads to three choices if you’re a java shop. In order of more conservative first:
The smart money if you have the time is to try out all three.
