我有一个 golang 服务，它使用通过 NodePort(在本例中为 30002)暴露给谷歌容器引擎 (GKE)/k8s 集群的 gorilla 实现 WebSocket 客户端。
我有一个带有 HTTP/HTTPS 前端(即 80/443)的手动创建的负载均衡器(即不在 k8s 入口/负载均衡器)，它将流量转发到端口 30002 上我的 GKE/k8s 集群中的节点。
我可以在浏览器(OSX 上的 Chrome 58.0.3029.110)中获取我的 JavaScript WebSocket 实现，以连接、升级和发送/接收消息。
我在 golang WebSocket 客户端中记录了 ping/pong，在 30 秒之前一切正常。连接后 30 秒，我的 golang WebSocket 客户端收到 EOF/close 1006(异常关闭)并且我的 JavaScript 代码收到关闭事件。据我所知，我的 Golang 或 JavaScript 代码都没有启动 WebSocket 闭包。
在这种情况下，我并不特别关心 session 亲和性 AFAIK，但我已经在负载均衡器中尝试了基于 IP 和 cookie 的亲和性以及长生命周期 cookie。
此外，这组完全相同的 k8s 部署/pod/服务规范和 golang 服务代码通过 AWS 的 ELB 在 AWS 上基于 KOPS 的 k8s 集群上运行良好。
30 年代的强制关闭可能来自哪里？这可能是特定于 GKE 或 GCE 负载均衡器上的 k8s 默认集群设置吗？
感谢阅读!
-- 更新--
负载均衡器上有一个后端配置超时设置，用于“在将其视为失败请求之前等待后端服务响应的时间”。
WebSocket 并非无响应。它一直在发送 ping/pong 和其他消息，直到被杀死，我可以通过浏览器中的 console.log 验证并登录 golang 服务。
就是说，如果我将负载均衡器后端超时设置提高到 30000 秒，事情就会“起作用”。
虽然感觉不是真正的修复，因为负载均衡器将继续不恰本地提供实际无响应的服务流量，如果 WebSocket 确实变得无响应也没关系。
我已经使用路径映射将高超时设置隔离到特定的后端设置，但希望能够真正解决该问题。
最佳答案
关于go - GKE + WebSocket + NodePort 30 秒掉线，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44033191/