Sorry for the late reply, I was trying to replicate the scenario to gather the info for you.
First thing that can potentially break things is the fact that
interNamespaceAccessLabels show up in the hub deployment… As you know, hub will have issues starting up if it can’t immediately bind to an address/connect to an external proxy.
In this case, these two [*] hardcoded configs on the pre-injected
jupyterhub_config.py prevent the hub from starting up since… well we’re not using the proxy pod and we need the hub to know this and start the proxy on its own:
#Connect to a proxy running in a different pod. Note that *_SERVICE_*
# environment variables are set by Kubernetes for Services
c.ConfigurableHTTPProxy.api_url = (
c.ConfigurableHTTPProxy.should_start = False
In addition to setting should_start to
true and removing the api-url, the configurable-http-proxy binary didn’t seem to be on the preset image so I had to build my own and install it.
These are the basic observations I was able to make. If this is something of interest to you and other users I can work on a PR to make the proxy an “optional” setting on the chart.