Create only one service for JupyterHub and make type a parameter #99
Comments
|
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. |
|
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 |
|
Thanks. So my conclusion is we do in fact need two services
|
|
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>
.
|
|
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. |
|
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
|
|
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. |
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. |
…eflow#99) * Grant access to Johnu who wants to update devstats. * Add johnu's gmail address * Add container.admin permissions
We are currently creating two services for JupyterHub; one of type ClusterIp and one of 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?
The text was updated successfully, but these errors were encountered: