Skaffold: Add ability to pass in additional ports to port-forward

[etanshaul]

As discussed offline, adding for tracking purposes:

It would be useful to be able to pass in a flag to the Skaffold execution with ports for Skaffold to port-forward in addition to those specified as container ports.

One use-case is for configuring debugging. In order to attach a debugger, it is necessary to port-forward the debug port. With this feature, tools like IDEs could then automate this by passing the debug port as a flag to Skaffold.

[priyawadhwa]

Hey @etanshaul , is it necessary for this to be a flag, or would a skaffold.yaml field work as well? Initially I preferred the flag but I forgot that the pod and container name may need to be passed in as well :sweat_smile:

apiVersion: skaffold/v1beta2
kind: Config
build:
  artifacts:
  - image: gcr.io/k8s-skaffold/skaffold-example
deploy:
  kubectl:
    manifests:
      - k8s-*
  port-forward:
    - pod: getting-started
      container: hello-world
      ports: 
        - 8080
        - 9000

[etanshaul]

hi @priyawadhwa - ah yes you are right. Ideally, there would be both options. For the use-case I have in mind, we'd pass them in as a flag so that it doesn't have to be a permanent part of the user's configuration but simply something that they IDE automatically configures at run-time when running in debug mode.

However, I do recognize that expressing this as a CLI flag isn't very pretty so we could make it work as just part of skaffold.yaml config. I do wonder if we have any precedents for passing in data like this via the CLI?

[r2d4]

Why not specify the debugger port in the deployment YAML? That seems like the right way to expose this feature. Adding it there is basically a no-op. From the API docs:

ports
List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated.

[etanshaul]

@r2d4 Actually I think you are right that specifying the ports in skaffold.yaml would have no benefit over specifying them in the deployment.

My original thought process was that minimizing the configuration burden on the user for setting up debugging in the IDE would be something worthwhile. However, if you don't think exposing this as a skaffold flag is the right way to go then there are other things we can do here in the editor to help (template generation, auto-writing containerPorts etc.).

[priyawadhwa]

I'm not sure if there are any precedents to passing in this much data via the CLI. I suppose the flag could look something like pod/container:port, so for the example above you'd have to pass in --port getting-started/hello-world:8080 --port getting-started/hello-world:9000

but, if we end up adding support for users to specify what local ports they want to map to, it would have to look like this:

pod/container:localPort:port which is definitely not pretty...

[etanshaul]

@priyawadhwa this reminds me, currently there is no way to specify a localPort is there? This is important in the case of multi-service applications where, for example, multiple java containers in different pods expose jdwp on 5005 (and so would need to be mapped to different local ports to avoid collisions).

@briandealwis @patflynn

[priyawadhwa]

@etanshaul that's correct, I recently merged #1474 which will map colliding ports to a random local port, but right now there's no way for the user to specify what that local port should be.

[etanshaul]

aha. I think in this case it makes sense to expose more user control over the port-forwarding either via configuration in skaffold.yaml, or at command execution time via a flag (more convenient for our use-case, but will defer to you) like you suggested (pod/container:localPort:port). This way IDE debuggers have control over the port mapping done by Skaffold. wdyt?

[etanshaul]

wrt to my last comment: the other option is to expose the local ports chosen by Skaffold through the (in progress) event API work. @nkubala

[priyawadhwa]

Cool, it seems like the flag makes most sense for the IDE use case, so I'll start prototyping it and see how it looks!

Just saw your last comment -- that could potentially be an option, @nkubala wdyt?

ref #1311 #1245

[briandealwis]

I think the command-line flags might hit some issues with deployments with replicas, or containers that are referenced from multiple manifests.

Also how will the iDE figure out pod names (pod/container:localPort:port) for deployments? The PodSpecs are usually unnamed, and the resulting pods have the deployment name with some hashes.

[etanshaul]

containers that are referenced from multiple manifests

Is this a common practice? Regardless, these are all valid issues with the flag approach that we need to think through.

[briandealwis]

I had a crazy idea: could the IDEs and Skaffold communicate across a gRPC channel? gRPC can be bidirectional and this could be a mechanism to provide both an Event API (#1265) and a Command API.

[nkubala]

@briandealwis you read my mind, see https://github.com/GoogleContainerTools/skaffold/pull/1574 for a first draft. this will likely become the start of a full control API

[balopat]

I think we can close this now: we are reporting PortForwarding events. Please reopen if you think we need this to track something.