<p>I have a golang service that implements a WebSocket client using gorilla that is exposed to a Google Container Engine (GKE)/k8s cluster via a NodePort (30002 in this case).</p>

<p>I've got a manually created load balancer (i.e. NOT at k8s ingress/load balancer) with HTTP/HTTPS frontends (i.e. 80/443) that forward traffic to nodes in my GKE/k8s cluster on port 30002.</p>

<p>I can get my JavaScript WebSocket implementation in the browser (Chrome 58.0.3029.110 on OSX) to connect, upgrade and send / receive messages.</p>

<p>I log ping/pongs in the golang WebSocket client and all looks good until 30s in. 30s after connection my golang WebSocket client gets an EOF / close 1006 (abnormal closure) and my JavaScript code gets a close event. As far as I can tell, neither my Golang or JavaScript code is initiating the WebSocket closure.</p>

<p>I don't particularly care about session affinity in this case AFAIK, but I have tried both IP and cookie based affinity in the load balancer with long lived cookies.</p>

<p>Additionally, this exact same set of k8s deployment/pod/service specs and golang service code works great on my KOPS based k8s cluster on AWS through AWS' ELBs.</p>

<p>Any ideas where the 30s forced closures might be coming from? Could that be a k8s default cluster setting specific to GKE or something on the GCE load balancer?</p>

<p>Thanks for reading!</p>

<p>-- UPDATE --</p>

<p>There is a backend configuration timeout setting on the load balancer which is for "How long to wait for the backend service to respond before considering it a failed request".</p>

<p>The WebSocket is not unresponsive. It is sending ping/pong and other messages right up until getting killed which I can verify by console.log's in the browser and logs in the golang service.</p>

<p>That said, if I bump the load balancer backend timeout setting to 30000 seconds, things "work".</p>

<p>Doesn't feel like a real fix though because the load balancer will continue to feed <em>actual</em> unresponsive services traffic inappropriately, never mind if the WebSocket <em>does</em> become unresponsive.</p>

<p>I've isolated the high timeout setting to a specific backend setting using a path map, but hoping to come up with a real fix to the problem.</p>

<p>I think this may be Working as Intended. Google just updated the documentation today (about an hour ago).</p>

<p><a href="https://cloud.google.com/compute/docs/load-balancing/http/#websocket_proxy_support" rel="nofollow noreferrer">LB Proxy Support docs</a></p>

<p><a href="https://cloud.google.com/compute/docs/load-balancing/http/backend-service#backend_service_components" rel="nofollow noreferrer">Backend Service Components docs</a></p>

<p>Cheers,</p>

<p>Matt</p>
