Handle optional port-forwarding about skaffold HOT 5 CLOSED

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...

from skaffold.

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

from skaffold.

@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.

from skaffold.

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?

from skaffold.

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

from skaffold.