New strategy combining local with LB service

[luisdavim]

Is your feature request related to a problem? Please describe.

There may be cases where there's no network path between the source and destination clusters and this case is covered by the local strategy but that seems to use k8s port-forwarding putting extra load on the API server.

Describe the solution you'd like

This strategy could use the same approach as the existing local strategy but create the LBs and use them for tunnelling instead of k8s port forwarding.

Describe alternatives you've considered

The local strategy would work for my use case but it will be a problem for larger amounts of data.

Additional context

The port-forward approach is still valid for some use cases but trying to use the LB first could be a good option to alleviate the impact on the API server.

[utkuozdemir]

Thanks for the idea.

Just a thought - Isn't it a kinda special case where the local system has access to both clusters over their LB IPs, but they don't have a network path between each other. It can definitely be the case, but is it a common enough case to generalize on? The local strategy only relies on 1 fact - both cluster's kube-apiservers are accessible. If this wasn't the case, migration would probably be impossible anyway.

Also please keep in mind that local strategy is experimental and generally only reliable for small amount of data.

Also, wouldn't something like this make more sense to open a network path between the clusters?

In any case, unfortunately, at the moment I don't have the time to implement new features. PRs are very welcome though.

[luisdavim]

Systems that are only accessible through a VPN for example. And if I can access both clusters API's for port forwarding I can probably also reach a LB on each even if either cluster can't reach the other.

[slimm609]

Wonder if something like wstunnel (https://github.com/erebe/wstunnel) could be used as a sidecar to tunnel the data over an ingress controller instead of an LB. This would still allow the client to be the proxy but shifts the load off the kubeAPIserver and would support any existing ingress controller