Connectivity Issue with JupyterHub on Kubernetes: Cannot Access Services by Internal DNS Name

Hello everyone,

I’ve deployed JupyterHub on a Kubernetes cluster using the official Helm chart and have run into a networking issue that I’m struggling to resolve. My setup includes using an NGINX Ingress Controller to expose JupyterHub, and I’ve opted to disable the LoadBalancer service for JupyterHub, configuring it instead as a ClusterIP service.

While JupyterHub is accessible and functions as expected from the outside, I’m encountering issues when trying to connect to other services within the same Kubernetes cluster. Specifically, any attempt to connect to services using their internal Kubernetes DNS service names fails, indicating a problem with service name resolution or network routing within the cluster.

I suspect there might be a misconfiguration either in my ingress setup, the JupyterHub service configuration, or possibly network policies that are affecting DNS name resolution and internal connectivity.

I would greatly appreciate any insights, suggestions, or similar experiences from the community that could help me diagnose and resolve this issue.

Can you give us more details about your K8S cluster? For example is it self-hosted or are you using a managed service such as AWS EKS or Google’s GKE? Some managed services require extra configuration to enable DNS. For example see the properties starting from

it’s a self hosted cluster, but also I try it in my own lab using minikube got the same result.

While JupyterHub is accessible and functions as expected from the outside, I’m encountering issues when trying to connect to other services within the same Kubernetes cluster. Specifically, any attempt to connect to services using their internal Kubernetes DNS service names fails, indicating a problem with service name resolution or network routing within the cluster.

There are networkpolicy resources created that restrict networking, by default, user servers for example not allowed to speak to other k8s internal destinations. This is controlled by singleuser.networkPolicy.egressAllowRules, where one rule is about private IPs, documented in z2jh’s configuration reference i think.

1 Like

Thank you very much, I wasn’t aware of network policy

1 Like