Golang WebSocket 服务在 Kubernetes 中必须通过 Ingress（如 Nginx Ingress Controller）实现负载均衡，不可依赖 ClusterIP Service；因 Service 仅工作在四层，无法识别 Upgrade/Connection 头，导致握手失败或空闲断连，需配置透传 header、延长超时及服务端监听地址、探针路径等关键项。
直接说结论：Golang WebSocket 服务在 Kubernetes 中不能靠 Service 做负载均衡，必须走 Ingress（如 Nginx Ingress Controller），且关键配置缺一不可——否则连接会在握手阶段失败或空闲后被静默断开。
为什么 ClusterIP Service 对 WebSocket 无效
Kubernetes 的 Service 是四层（TCP/UDP）转发，它不解析 HTTP 头，更无法识别 Upgrade: websocket 和 Connection: upgrade 这两个 WebSocket 握手必需的 header。客户端发来的 Upgrade 请求会被当成普通 HTTP 流量轮询分发到后端 Pod，而 Go 服务若没在根路径 / 显式处理 upgrade 逻辑，就会返回 404 或 400；即使处理了，连接后续也可能因 Service 的连接复用机制、超时策略或健康探针干扰而中断。
常见错误现象：
- 浏览器控制台报
WebSocket connection to 'wss://xxx/ws' failed: Error during WebSocket handshake: Unexpected response code: 400 - 连接建立后 60 秒左右自动关闭，日志里看不到错误，只有
read: connection reset by peer - 同一用户刷新页面后连到不同 Pod，导致会话状态丢失（比如 signaling server 场景下找不到目标
clientId）
必须加的 Ingress annotation 和 timeout 配置
Nginx Ingress Controller 默认会丢弃 Upgrade 和 Connection 头，必须显式开启透传，并拉长超时时间。以下 annotation 缺一不可：
立即学习“go语言免费学习笔记（深入）”；
-
nginx.ingress.kubernetes.io/upgrade: "websocket"：启用协议升级识别 -
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"：防止空闲连接被默认 60s 关闭 -
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"：同上，覆盖发送侧超时 -
nginx.ingress.kubernetes.io/backend-protocol: "HTTP"：确保后端走 HTTP/1.1（WebSocket 基于它）
如果用 Higress，对应配置是 higress.io/backend-protocol: websocket；Traefik 则需在路由中设置 middlewares 启用 upgrade。不要依赖默认值——它们几乎都不开。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Go 服务端代码和部署的硬性要求
你的 Go 代码和 Deployment 配置稍有偏差，Ingress 就白配：
- 监听地址必须是
0.0.0.0:8080，不是127.0.0.1:8080，否则 readiness probe 无法访问 - HTTP mux 不要注册
/的 handler，否则会拦截所有 upgrade 请求；WebSocket 路径应明确为/ws、/api/v1/ws等 - readinessProbe 必须禁用对 WebSocket 路径的探测——
http.Get("http://localhost:8080/ws")会触发握手失败，建议单独暴露/healthz用于探针 - Deployment 中
serviceAccountName和securityContext要设非 root 用户（如runAsUser: 65532），避免容器逃逸风险
示例 probe 配置：
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
别踩 NodePort 和 LoadBalancer 这两个坑
type: NodePort 或 type: LoadBalancer 直连 Pod，绕过了 Ingress 的七层能力。云厂商 LB（如 AWS ALB、阿里云 SLB）多数不支持 WebSocket 协议感知，会主动重置长连接；NodePort 则受限于宿主机端口范围和防火墙策略，且无法做 TLS 终止、host 匹配、路径路由等关键动作。
真正需要会话保持（比如 signaling server 里 clientId → *websocket 映射不能跨 Pod），靠 sessionAffinity: ClientIP 只能缓解，不能根治——它在 Pod 重建、节点故障时照样漂移。业务层该用 Redis 共享连接状态，就老实用 Redis。
最易被忽略的一点：客户端发起连接时，URL 的 Host header 必须和 Ingress 的 host 字段严格一致，否则 Nginx 会直接返回 426 或 400。别用 http:// 开头的 URL 去连 WebSocket，必须是 wss:// 或 ws://，且域名不能写错。
