Create only one service for JupyterHub and make type a parameter

[jlewi]

We are currently creating two services for JupyterHub; one of type ClusterIp and one of type LoadBalancer.

   jupyterHubService: {
	  "apiVersion": "v1", 
	  "kind": "Service", 
	  "metadata": {
	    "labels": {
	      "app": "tf-hub"
	    }, 
	    "name": "tf-hub-0",
	    namespace: namespace,
	  }, 
	  "spec": {
	    "clusterIP": "None", 
	    "ports": [
	      {
	        "name": "hub", 
	        "port": 8000
	      }
	    ], 
	    "selector": {
	      "app": "tf-hub"
	    }
	  }
   },

   jupyterHubLoadBalancer: {
	  "apiVersion": "v1", 
	  "kind": "Service", 
	  "metadata": {
	    "labels": {
	      "app": "tf-hub"
	    }, 
	    "name": "tf-hub-lb",
	    "namespace": namespace,
	  }, 
	  "spec": {
	    "ports": [
	      {
	        "name": "http", 
	        "port": 80, 
	        "targetPort": 8000
	      }
	    ], 
	    "selector": {
	      "app": "tf-hub"
	    }, 
	    "type": "LoadBalancer"
	  }
	},

We should just create a single service and make the type a configurable parameter.

@foxish @yuvipanda Am I missing something? Is there any reason to have two services?

[jlewi]

It looks like the first service is a headless that is needed by the individual Jupyter servers to connect back to the hub. It looks like this needs to be a headless service.

Whereas the second service is used to create an entrypoint from outside the cluster for users to connect to.

[yuvipanda]

While I haven't looked at the code yet (been swamped!), I suspect you need the headless service because the pods need to know where to find the hub, and by default this just uses the hub's hostname. Since you're using a statefulset, that would be tf-hub-0, and you need the extra headless service.

This is configurable - see the 4 hub_connect_* options used in https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/master/images/hub/jupyterhub_config.py#L128 to get an idea of how to configure it. Setting those in your config should allow you to get rid of the headless service.

[jlewi]

Thanks. So my conclusion is we do in fact need two services

• Service is intended for internal consumption by the spawned pods with the hub
• 2nd service is intended for users to connect to the hub.

[yuvipanda]

Why does it need to be two services? The jupyter pods can just talk to the hub using the same service external users use to access it, no?

…

On Jan 6, 2018 2:28 PM, "Jeremy Lewi" ***@***.***> wrote: We are currently creating two services for JupyterHub; one of type ClusterIp and one of type LoadBalancer. jupyterHubService: { "apiVersion": "v1", "kind": "Service", "metadata": { "labels": { "app": "tf-hub" }, "name": "tf-hub-0", namespace: namespace, }, "spec": { "clusterIP": "None", "ports": [ { "name": "hub", "port": 8000 } ], "selector": { "app": "tf-hub" } } }, jupyterHubLoadBalancer: { "apiVersion": "v1", "kind": "Service", "metadata": { "labels": { "app": "tf-hub" }, "name": "tf-hub-lb", "namespace": namespace, }, "spec": { "ports": [ { "name": "http", "port": 80, "targetPort": 8000 } ], "selector": { "app": "tf-hub" }, "type": "LoadBalancer" } }, We should just create a single service and make the type a configurable parameter. @foxish <https://github.com/foxish> @yuvipanda <https://github.com/yuvipanda> Am I missing something? Is there any reason to have two services? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB23tbAQqOXkkcGcTOPHZ4LGegSqlGrks5tH_OSgaJpZM4RVdjA> .

[jlewi]

I tried it and ran into problems. Specifically I tried having a single tf-hub-0 service of type ClusterIP.

I ran into an error like #78 with the Jupyter pods not being able to connect to the hub. My guess is that there is something about headless services and how these pods connect to the hub.

I didn't bother to investigate because it seems much cleaner to have 2 services.

Users will want to configure how they connect to JupyterHub; for example they might want to use an external loadbalancer; they might want to use ingress; they might want to use kubectl proxy. I can't think of a reason why external access to JupyterHub should affect how the pods connect to the hub. That just seems like its creating more ways for things to go wrong.

[yuvipanda]

I think having two services is unneeded complexity since you can configure it to not need it, but will defer to you for the UX you want for your users :)

…

On Sun, Jan 7, 2018 at 4:30 PM, Jeremy Lewi ***@***.***> wrote: I tried it and ran into problems. Specifically I tried having a single tf-hub-0 service of type ClusterIP. I ran into an error like #78 <#78> with the Jupyter pods not being able to connect to the hub. My guess is that there is something about headless services and how these pods connect to the hub. I didn't bother to investigate because it seems much cleaner to have 2 services. Users will want to configure how they connect to JupyterHub; for example they might want to use an external loadbalancer; they might want to use ingress; they might want to use kubectl proxy. I can't think of a reason why external access to JupyterHub should affect how the pods connect to the hub. That just seems like its creating more ways for things to go wrong. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#99 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB23mJELmxNhZuHUzh3F5isHSGXqAz5ks5tIWGOgaJpZM4RVdjA> .

-- Yuvi Panda T http://yuvi.in/blog

[jlewi]

Thanks for the input. I think we'll stick with two.

With two services the pod always use a headless service to connect to the hub. So we don't have to worry about configuration of the ingress to JupyterHub interfering with pod to hub communication.

[foxish]

I ran into an error like #78 with the Jupyter pods not being able to connect to the hub. My guess is that there is something about headless services and how these pods connect to the hub.

We could actually unify them. The headless service differs in the kind of DNS name it imparts to the pod, which is why it wasn't interoperable when you tried it I think. But I agree that they are serving different purposes - one is essential for jupyterhub to connect back and creates a DNS entry, the other is for exposing Jupyterhub outside of the cluster - so, I'm also in favor of keeping both of them around at least for now.