We are considering running a service mesh as part of our application and are wondering if there are any active replicated customers who use the embedded cluster functionality successfully running a service mesh. Are there any concerns with using a service mesh with replicated?
It is not a very common pattern, because it can be hard to design a release that includes a component like a service mesh (let’s use Istio for sake of argument) that installs well in all use cases.
Existing cluster customers may not be willing/able to install a service mesh included as a component in a release, so you might decide that you only install it with a kURL embedded cluster. But now you have to manage 2 diffferent architectures with potentially very different behaviour because one of your releases includes Istio and the other does not. If you start to leverage features of the service mesh for mutual TLS or routing, then your releases start to diverge on features, and as soon as you start to do support, you need to know whether your customer is using embedded or existing, with or without istio, because you also likely have customers on older builds who haven’t updated yet.
Whenever I am asked about service mesh implementations, I usually start with the question “what problem does including a service mesh solve?” and then try to find counterexamples that will solve for those problems without the service mesh.
That being said, we do have at least 1 vendor that ships istio for the istio-gateway Ingress Controller component, but I don’t know if we have vendors that ship the entire Istio Service Mesh.