Kubespawner fails to create service when internal_ssl is activated because of the metadata

[diegoPlain]

Bug description

I am using JupyterHub with Kubespawner and a custom authenticator. I wanted to activate SSL for all comms inside JupyterHub using this param c.JupyterHub.internal_ssl = True, but the thing is that KubeSpawner fails to create the kubernetes service associated with the Jupyter Notebook whenever I try to spin an user server.

The service and secret, as far as I know, they are the correspondant certificate for the user after activating the internal ssl, and the error says (I am privatizing some of the values, but keeping +- the length):

    HTTP response body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Service \"******************************************\" is invalid: metadata.name: Invalid value: \"*******************************************************\": must be no more than 63 characters","reason":"Invalid","details":{"name":"***************************************************************************","kind":"Service","causes":[{"reason":"FieldValueInvalid","message":"Invalid value: \"**************************************************************\": must be no more than 63 characters","field":"metadata.name"}]},"code":422}

This is actually true in my case, because I am exceeding the length. The problem comes in my opinion with how the spawner.py handles the creation of this field, which concatenates jupyter-{username}--{servername}. If any of those fields, or all of them exceed the 63 characters of Kubernetes, it fails.

Furthermore, I have tried to play around with these params to overcome this problem with no luck:

c.KubeSpawner.secret_name_template = '{username/servername}'
c.KubeSpawner.pod_name_template = '{username/servername}'

Whenever I change those, I loose the conection with the notebook and after the timeout of 30s, it's beeing deleted by JupyterHub.

I am a bit lost right now, and I don't know if I am missing something, or if there is a missing parameter that I am not considering at the moment. Could you please help me?

How to reproduce

1. Activate the internal_ssl param in JupyterHub
2. Have any random UID for the servername, or username that it is long enough and combined exceed the 63 chars length
3. Login and try to access the server
4. JupyterHub fails to connect to the server when creating the certs for it

Expected behaviour

I would expect to consider this Kubernetes limitation, and reduce or apply any hash to the full name, so it is able to create the service and the secret, and it is still able to distinguish the different servers for the users.

During my search, I found an issue regarding how the labels were moved to annotations to comply with this restriction in Kubernetes, however, even though I wanted to add that link here, I am not able to find it anymore. I think it was either in this project or the jupyterhub/jupyterhub itself.

Actual behaviour

It fails when requesting the K8S API to create the service.

Your personal set up

• JupyterHub 4.0.2
• jupyterhub-kubespawner 6.1.0
• K8S v1.27.2
• DockerEngine v24.0.6

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉