Bokeh in Kubernetes not rendering / couldnt open websocket

HI Guys,

I have a very smiple bokeh app that just draws a graph. i run it with bokeh server using the deafult port 5006. Works fine and renders on my browser as expected.

I am trying to get this to run in kubernetes in a docker container. i’ve mapped port 5006 to port 80 and setup ingres etc and the server does indeed start

2021-09-09 10:30:06,031 Starting Bokeh server version 2.3.3 (running on Tornado 6.1)
2021-09-09 10:30:06,036 User authentication hooks NOT provided (default user enabled)
2021-09-09 10:30:06,039 Bokeh app running at: http://localhost:5006/hello2
2021-09-09 10:30:06,039 Starting Bokeh server with process id: 1

When i hit the URL for the FQDN, it opens a blank webpage with title “Bokeh Application”. Looking at the web cosnole, its erroring with “Failed to connect to Bokeh server: Could not open websocket”.

Searching i see mention of --allow-websocket-origin. It says by deafult it allows 5006. i have tried every combination of this including just the wildcard ‘*’ but i still get the same error. Intuitively i would assume it should be locahost:80 since my kubernetes mapping is doing this:

- name: http
  port: 80
  targetPort: 5006
  protocol: TCP

it feel’s like im very close but no cigar. Any idea’s ? thanks in advance as im a bokeh newbie.

Is there a proxy or a load-balancer involved? If so that may require configuration to allow websocket connections. E.g. on AWS with class ELB websocket connections have to be explicitly enabled.

Not load balanced. just a bog standard kubernetes service. the same setup works perfectly with a standard pyton webserver or java springboot server running on 8080. ive tried to explicitly specify the FQDN. it resolves this ok but then fails to connect to websocket.

I don’t have enough k8s expertise to know what that means or entails. But if the initial HTTP request makes it to the server, and the browser gets the response, and then tries to perform the WS upgrade but fails, the most likely explanation is that there is something in the middle (proxy, firewall, load-balancer) that is not allowing websocket connections.