Zero-to-jupyterhub-k8s: [feature request] Add option to specify port on a LoadBalancer

[anton-khodak]

I need to expose JupyterHub proxy on a custom port via a LoadBalancer, but there is no such an option in the schema (although there is one for NodePort). I need to manually create a service with my custom port instead. Is it possible to add such an option?

[consideRatio]

Looking into this briefly:

https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/bcbde2002e28fcddf72e26a9cb6c9b7f1b85c49d/jupyterhub/templates/proxy/service.yaml#L44-L71

This was a quite complicated code we got =/ I think the answer is yes sure, but this was hard for me to grasp fully.

A custom port or custom targetPort btw? I think port reflects the service's incomming traffic, and targetPort what it redirects to. Which did you want to configure?

[anton-khodak]

Hi @consideRatio , I wanted to configure the port for the incoming traffic. Our infrastructure requires that services run on ports higher than 8000, and LoadBalancers are exposed on port 80 by default.

[consideRatio]

@anton-khodak aha sounds fine to configure. I notice that we have properly named the port "http" which means that we probably can change the 80 to something else at this place without needing to update it elsewhere - because all the references elsewhere is to a port named "http".

Actionplan

For anyone to close this issue, we need a PR that does something like this I think:

• Make the port reference a helm value instead of the hardcoded 80.
• Decide on what helm value would make sense, perhaps {{ .Values.proxy.service.port }}?
• Set a default value of this variable in values.yaml to 80
• Verify that a change to the port value to 8000 or similar works as intended without crashing other things that perhaps also needed to be updated.

[consideRatio]

@anton-khodak is this still a relevant feature request? Have you heard anyone else that has had this need, or why there is a requirement imposed on the services to run on ports higher than 8000 imposed?

[anton-khodak]

@consideRatio we found a workaround and proceeded with it, so you can close this issue if you want