Add copy-deployment and swap-service as a way to use Telepresence

[ark3]

See also #257 and PR #407

[ofpiyush]

Our use cases

1. Replace multiple services/deployments
2. Add a local process as a pod parallel to the ones already running
3. Let the deployments run and proxy traffic to our local (to allow background processes running)
4. Completely swap out the deployment (current behaviour)
5. Go back to previous state if something fails.
6. Prevent multiple users from targetting the same service at the same time(warn/deny based on type of proxy)

Proposal

1. Separate out the VPN process and tie it to value of kubectl config current-context
2. Allow context level configurations for things like --also-proxy
3. Add copy-deployment
4. Add a single deployment which manages multiple accessors and reverts a deployment that went sideways.
5. Allow for a .telepresence.json file to hold common config for a directory/git-repo.

I'm willing to help out with my dev time to speed up release of these features/any other solution to the use case :)

I'll leave the original comment here for completeness, can ignore it as all distilled bullet points are mentioned above.

Original comment:

Our use case/experience report:

We already have openvpn added to our cluster. Simplifying that would be sweet but isn't required as such. https://github.com/pieterlange/kube-openvpn

Having a separate openvpn instance allows us to add other kind of urls to be forwarded without needing --also-proxy.
eg: c.<project_id>.internal urls with GCP.

Separating out the VPN part makes it straight forward to have multiple different services running locally. It also makes the network very very stable. I run into cases where urls sometimes do not get proxied with telepresence. Those class of issues can be completely avoided by allowing a separate VPN setup.

If you baked that configurability into telepresence, that would be cool.

I envision separate telepresence config(s) tied to kubectl config current-context.

Different kind of needs we regularly run into:

1. Add a local process as a pod parallel to the ones running, some traffic comes to my pod. This has added benefit of being useful in really bad cases of production debugging as well.

2. Let the cluster pods deal with partial background functionality, redirect all active service traffic to my local.

We have rabbitmq listeners etc in some of our services, they can continue to operate in the cloud while we debug some API level stuff/dev locally, but we want requests to the service to come to the local instance.

3. Stop everything and let us completely take over. This is the current behaviour of --swap-deployment

We would not be opposed to having an always on, telepresence deployment with it's own URL and such if that made things easier, esp around networking and managing everyone's connection / multiple swappable shells.

This central deployment would also help you to keep 1 source of truth and return the cluster to it's original state if things went sideways on someone's local.

[donnyyung]

This seems to be pretty much how Telepresence 2 works. Here are the docs on how to install Telepresence (https://www.telepresence.io/docs/latest/install/), please re-open if you still see this issue in our latest version!