Closed steeling closed 1 year ago
FYI, we had invested in setting up a multicluster environment before using Kind or AKS:
https://github.com/openservicemesh/osm/pull/3984 https://github.com/openservicemesh/osm/pull/3915
Want to hear your opinion if we can still leverage these changes and start this issue.
I imagine a tool could be agnostic to the clusters themselves. Passing in 2 kubectl context names should allow it to work anywhere
We can have a subtasks list here:
osm import-service
, osm export-service
etc. This provide us a smooth process to further custom the environment.Note that it is mentioned in KEP-1645 that MCS API implementation is responsible for the tooling
More subtasks can be added if necessary.
@allenlsy has been experimenting with Submariner. Submariner is a unique MCS implementation that creates ServiceImports/Exports and populates with the IP address of the Submariner gateway, which handles network connectivity across clusters.
As a service mesh, we will need to create our own network connectivity solution, agnostic to submariner. This bug is explicitly to create a workflow to "join" to clusters, such that they are aware of a set of ServiceImports and ServiceExports for appropriate services in each cluster.
This may be as simple as a script that wraps kubectl commands to: