Kubernetes 本身不感知 WebSocket 协议，但通过正确配置 Nginx Ingress Controller（启用 nginx.ingress.kubernetes.io/upgrade: "websocket"、调大 proxy-read-timeout 和 proxy-send-timeout）、使用 ClusterIP Service、禁用 HTTP readinessProbe、确保客户端 URL 与 Ingress host 严格一致，并调优 Ingress Controller 资源限制，即可稳定支撑千级并发 WebSocket 连接。
直接说结论：Kubernetes 本身不感知 WebSocket 协议，但只要正确配置 Ingress（尤其是 Nginx Ingress Controller）并确保后端服务、Service、连接生命周期协同，就能稳定支撑千级并发 WebSocket 连接；关键不是“能不能”，而是“Upgrade 头有没有透传”“连接有没有被中间件意外中断”“会话是否被轮询打散”。
nginx.ingress.kubernetes.io/upgrade-annotation 必须显式开启
Nginx Ingress 默认不会处理 Upgrade 和 Connection 请求头，这是 WebSocket 握手失败的最常见原因——浏览器发了 Upgrade: websocket，Ingress 却当成普通 HTTP 返回 400 或静默丢弃。
- 必须在
Ingress资源中添加 annotation：nginx.ingress.kubernetes.io/upgrade: "websocket" - 同时建议加上：
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"和nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"，避免空闲连接被默认 60s 超时关闭 - 如果用的是自建 Nginx（非 Ingress Controller），则需在
location块里手动写死：proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";
Service 类型选 ClusterIP，别用 LoadBalancer 直连 Pod
虽然 type: LoadBalancer 看起来“更直接”，但它绕过了 Ingress 的七层能力，无法做路径路由、TLS 终止、header 透传，且云厂商 LB 通常不支持 WebSocket 协议感知（比如 AWS ALB 默认会重置长连接）。
- WebSocket 流量应走
type: ClusterIPService + Ingress（七层）组合，这是唯一能稳定控制Upgrade流程的方式 - Service 的
sessionAffinity: ClientIP可以缓解会话漂移，但不解决根本问题；真正需要会话保持的应用，应在业务层用 Redis 共享连接状态，而非依赖调度器 - 避免使用
NodePort暴露 WebSocket：它依赖 kube-proxy 的 iptables/ipvs 规则，而这些规则对长连接友好度低，容易触发 conntrack 表满或连接复位
Deployment 中必须禁用 readinessProbe 的 HTTP 探针
很多团队照搬 HTTP 服务模板，给 WebSocket Pod 配了 readinessProbe 去 GET /health，这会导致严重问题：Ingress 认为 Pod “就绪”才转发流量，但 WebSocket 连接建立后，HTTP 探针可能因超时或返回非 2xx 而反复将 Pod 标为 NotReady，造成连接闪断。
- WebSocket 服务的健康检查应改用
exec探针，例如执行ss -tuln | grep :8080确认端口监听 - 或者干脆去掉
readinessProbe，靠livenessProbe（同样建议用exec）保活即可——WebSocket 连接本身已是活性证明 - 若必须用 HTTP 探针，请确保后端服务在
/health返回 200 且不依赖 WebSocket 上下文（比如不要查 ws client map）
客户端连接 URL 必须与 Ingress host 完全一致
WebSocket 握手时，浏览器会校验 Origin header 与请求 URL 的协议/域名/端口是否匹配。一旦 Ingress 配置了 host: ws.example.com，但前端代码写的是 ws://example.com 或 ws://192.168.1.100，服务端（尤其 Java Spring WebFlux 或某些 Node.js ws 库）会直接拒绝连接并返回 403。
- 前端必须用和 Ingress
rules.host完全一致的域名构造WebSocket实例，包括协议（wss://对应 TLS）、端口（显式写:443或省略均可，但不能错） - 开发环境可通过
/etc/hosts或 local DNS 模拟域名，禁止硬编码 IP 或 localhost - 若用自签名证书，
wss://连接在 Chrome 中会直接失败，需先手动访问一次对应域名并接受证书警告
最常被忽略的一点是：Ingress Controller 自身的资源限制。一个默认配置的 nginx-ingress-controller Pod 在未调优时，worker_connections 仅 1024，epoll wait timeout 偏短，面对大量长连接会迅速耗尽 fd 或触发 connection reset。上线前务必检查它的 ConfigMap 中 worker-processes、worker-connections 和 keepalive-timeout 是否按预期调整。这不是应用层该管的事，但它是整个链路的瓶颈底座。
