Port-forwards with localPorts should fail if port is occupied, and fail early

[briandealwis]

Some users wish to establish port-forwards for HTTPS services to port 443. They need the port-forward to fail if this port is unavailable, and ideally it should fail early rather than waiting until the deployment has completed.

Current behavior

With user-defined port-forwards, the localPort is acquired on a best-effort used.

portForward:
- resourceType: deployment
  resourceName: myDep
  namespace: mynamespace
  port: 8080
  localPort: 9000 # *Optional*

field	description
localPort:	local port to forward to. If the port is unavailable, Skaffold will choose a random open port to forward to. Optional.

Proposed behavior

Revise port-forwarding as follows:

• a portForward without a localPort should attempt to acquire the requested port, subject to our current restrictions (i.e., port ≥ 1024)
• if localPort is a non-zero value, then it should be acquired OR the Skaffold session should fail. (If unspecified, the localPort is set to 0.)

Further, Skaffold should check and fail on start if requested local-ports are not available.

[dhodun]

Running into this issue as well. We are running large angular front-end on workstations which require 4 microservices on GKE and ports are hard coded at FE level.

[gianfrancodemarco]

Hello, any update on this? We are having the same issue. When redeploying the images, the port forward uses random ports (maybe the ports are not freed in time?), and the whole environment breaks.

[mariocandela]

Hello, any update on this? We are having the same issue. When redeploying the images, the port forward uses random ports (maybe the ports are not freed in time?), and the whole environment breaks.

+1

[mattskinosix]

+1

[Jul13nT]

Hello, any update on this? We are having the same issue. When redeploying the images, the port forward uses random ports (maybe the ports are not freed in time?), and the whole environment breaks.

Same here. We are having this issue only with Linux but not with Windows. When killing Skaffold then restarting it, it regularly take the next port instead of the defined one. Linux shows that the port is not used but Skaffold is not using it. Failing early will at least save some time.

[ericzzzzzzz]

Hi all, thank you for the replies. This issue has not got any replies for more than 2 years. This makes me wonder if this is related to something we introduced recently, or things have always been like this? Could you let me know the skaffold version you use with this issue? Thank you so much! ❤️

[Jul13nT]

Hi all, thank you for the replies. This issue has not got any replies for more than 2 years. This makes me wonder if this is related to something we introduced recently, or things have always been like this? Could you let me know the skaffold version you use with this issue? Thank you so much! ❤️

I'm using 2.6.0. I've been using Skaffold since v1.36.0. I've always had this problem but never took the time to report it because it's not blocking.

[gianfrancodemarco]

@ericzzzzzzz I'm now using 2.7.1. I'll elaborate on my situation: I have a number of containers with port forwarding enabled:

Port forwarding ***, remote port 11000 -> http://0.0.0.0:11000
Port forwarding ***, remote port 20001 -> http://0.0.0.0:20001
Port forwarding ***, remote port 20002 -> http://0.0.0.0:20002
Port forwarding ***, remote port 61613 -> http://0.0.0.0:61613
Port forwarding ***, remote port 5001 -> http://0.0.0.0:5001
Port forwarding ***, remote port 10140 -> http://0.0.0.0:10140
Port forwarding ***, remote port 5002 -> http://0.0.0.0:5002
Port forwarding ***, remote port 27017 -> http://0.0.0.0:27017
Port forwarding ***, remote port 20000 -> http://0.0.0.0:20000
Port forwarding ***, remote port 8161 -> http://0.0.0.0:8161
Port forwarding ***, remote port 6379 -> http://0.0.0.0:6379
Port forwarding ***, remote port 10000 -> http://0.0.0.0:10000
Port forwarding ***, remote port 10050 -> http://0.0.0.0:10050
Port forwarding ***, remote port 5003 -> http://0.0.0.0:5003
Port forwarding ***, remote port 5004 -> http://0.0.0.0:5004

and this works as expected, which is when a code change is made and images are re-deployed, the port forwardings keep the same ports.

However, If I add some port forwardings for debug purposes (like the following):

  - resourceType: deployment
    resourceName: test
    namespace: hlpy
    address: 0.0.0.0
    port: 5678
    localPort: 5679

the ports start to change every time the images are re-deployed, e.g:

Port forwarding ***, remote port 10000 -> http://0.0.0.0:10001

I don't understand how this is causing the problem, since the local ports associated with the remote 5678 are far from the other allocated ports.

[ericzzzzzzz]

Thank you @Jul13nT @gianfrancodemarco for the additional information! We'll work on a fix for this in this milestone or next milestone.

[dio4ev]

+1