Handle optional port-forwarding

[viglesiasce]

I started to go down the route of figuring out how to work with Skaffold and use a remote debugger (delve in my case).

The only thing I really needed from Skaffold was for it to be able to reconfigure a port-forwarding setup to one of the new pods that was created.

I think it could look something like:

portForwarding:
  - labelSelector:
      app: my-app
      component: backend
    port: 2345
  - labelSelector:
      app: my-app
      component: frontend
    port: 8080:80

Skaffold could pick the most recently deployed pod that matches the selectors, although some more precise detection of the "right pod" may be necessary.

[dlorenc]

I wonder if we could figure out the "skaffold deployed" pods automatically, and forward any ports automatically.

[r2d4]

@dlorenc we have code -> image which gives us any pod running that container.

The one thing we're missing is really understanding the manifests going in and what resources we're deploying. You might want to port forward a service or ingress backend, which we wouldn't be able to do today.

[errordeveloper]

It's a very interesting problem, I think.

Draft has draft connect, which I've not used and not quite aware of what it does, but perhaps that's one area to explore.

Right now I can grab pod names from skaffold dev output and use it with kubectl exec or kubect port-forward, it'd be nice if I didn't need to do this manually, as I won't necessarily grab the rigth pod name. Maybe this isn't Skaffold's problem to solve at all, I'm not sure.

On the other hand, kubectl exec (and kubect port-forward as of latest release, I hear) no longer require pod name, so it's not that make things easier for some users, although I'm pretty sure that some user would aim at a particular pod... Also, I'm not sure if new kubectl debug requires pod name or it can be used with deployment/<name>, I've not got a chance to use it yet.

Despite that, it'd be nice to have a way to deal with the case of a simple project where I have one deployment and don't want to maintain non-portable/insecure scripts or service definitions, so I'd rather like to see a simple tool that parses skaffold.yaml and figures out the pod I want to connect to (whether I wanna do kubectl exec|port-forward|debug).

Alternatively, it'd be also neat to have skaffold dev --proxy-all|--proxy=<name>..., which would set-up some kind of proxies all ports for all workloads that it manages (or a subset of), and it'd try to do the right thing for the type of cluster it's used with.
For example, on Docker for Mac it could just create NodePort services (basically kubectl expose, but Skaffold would print the port it allocates), while for a remote cluster it could be something based on kubectl port-forward.

Just a few thoughts...

[bhack]

I think that debugging it is a very important feature to be covered in dev.
What is the debugging hipotesis of the Skaffold dev loop? How it is supposed currently to do debugging?

[r2d4]

I'm going to close this with #945. There is #969 with some additional ideas around how the feature might work.