-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
validate that hostports are not configured twice with the same protocol #2975
Comments
👁️ |
Can you guys share the link to the issue, I would like to take this up. |
The issue doesn't really add more context than this title, it just brought the topic to attention: hostports should not be configured twice with the same protocol. You can't listen to say port 80 on the host on TCP twice to different container Ports. It's not possible, both port forwards have to create a listener on the host on the (port, protocol) and if there's duplicate entries covering the same (hostPort, protocol) that should be an error. Sorry I've been drowning in notifications :-) |
@BenTheElder It is possible to bind a socket to the same port and protocol on different interfaces (listenAddress). |
@BenTheElder @aojea While going through the code I found that we don't check if the user-provided port is free/available, is this intentional or should I create an issue for this? kind/pkg/cluster/internal/providers/common/getport.go Lines 25 to 36 in 49c8845
|
Yes we should consider listenAddress. No we should not attempt to check if the port is free.
The linked utility is used for obtaining a semi-randomized port, because if we don't explicitly set one it will be re-randomized when the container is recreated on restart. In the case of a remote host -1 may be configured to avoid the local check at the cost of the reboot behavior. |
cc @aojea (thinking of that kubernetes issue)
The text was updated successfully, but these errors were encountered: