Skip to content
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

feat(helm): configure service port independent of container port #2957

Closed
elchenberg opened this issue Sep 29, 2022 · 4 comments
Closed

feat(helm): configure service port independent of container port #2957

elchenberg opened this issue Sep 29, 2022 · 4 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.

Comments

@elchenberg
Copy link
Contributor

I would like to use port 80 as the service port but keep the default container port (or use any other unprivileged port as container port) because I am not very good at remembering (seemingly) random port numbers. It is much easier to remember the address of the Trivy server as http://trivy.trivy.svc than remembering http://trivy.trivy.svc:4954. I do not want to use the privileged port 80 as container port though (and even if I wanted, the container would fail to start with the following error: FATAL listen tcp 0.0.0.0:80: bind: permission denied).

With the current Helm chart I can only configure the .service.port value and this will be used for service's port, the service's targetPort and for the container's port:

@elchenberg elchenberg added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 29, 2022
@dbirks
Copy link

dbirks commented Oct 12, 2022

Yeah I agree, being able to set port 80 for the service is quite nice to have. I can't remember what each app's port is otherwise. Just submitted a PR to fix 🔧

@github-actions
Copy link

This issue is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Dec 12, 2022
@github-actions github-actions bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Dec 13, 2022
@github-actions
Copy link

This issue is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Feb 11, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 3, 2023
@sparkacus
Copy link

This is quite an important request.

Although I haven't created helm charts myself, it seems a bit odd for the port defined specifically for a service to be forcefully reused as the port the container binds to. If I define the 'service' port I expect that to be the service only, at least that's my opinion.

There are often various reasons why the ports need to be different. Routes to a kubernetes service can be from many directions e.g. internally, externally etc. I'm now hitting the same issue in that all our CI builds point to the local kube service DNS and we don't define a port as we're happy to use port 80. I have no problem with the container binding to a high value port, but I need the service to route on port 80.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants