Is there ever a case where more than 1 adapter will be deployed? 1/mesh type I mean. You won’t have more than one Linkerd adapter deployed at once for example.
This is an excellent question, @jbyers19. While it is not necessary to do so in order for Meshery to manage multiple instances of the same type of a service mesh, you can. Meshery supports this. It’s not an oft used deployment model, but can make sense for a couple reasons:
- Resiliency - in case one adapter falls over or becomes unavailable.
- Performance - in the event that parallel execution of many Adapter operations is critical.
- Security - to the extent that different network or user permissions might apply to a given
- Locality - one deployed within each cluster, whether this be for resiliency, performance, or security reasons.
- Tenancy - in case there is a desire to run dedicated, segregated adapters by Kubernetes cluster, by service mesh deployment, workload, or other.
Outside of the execution lifetime of a given operation, Meshery Adapters are stateless and are not required to be cognizant of one another (that’s Meshery Server’s job).
Of the examples given above, Meshery Server handles 1. Resiliency use case as of v0.5.x. Roadmap could call for additional intelligence to be put into Meshery Server so that it might either take action or expose controls to users over the selection of an Adapter on a per operation basis, or cluster/service mesh association basis. External systems (e.g. load balancing or authorization capabilities of a service mesh) can be paired with a Meshery deployment today to achieve use cases 2 through 4. The good news is that Meshery’s architecture affords for this flexibility.
The answer to the FAQ Using Multiple Adapters | Meshery could use updating with some of the use cases provided here.
1 Like
