如何使用Kubernetes实现WebSocket的可扩展性？

问题1：客户端消息发送路径选择 #

客户端必须将消息发送至后端服务，再由后端转发至Redis Pub/Sub，绝对不能让客户端直接连接Redis：

• 安全层面：直接暴露Redis会带来严重权限风险，客户端可随意操作Redis数据，破坏业务逻辑。
• 业务逻辑：WebSocket连接的身份验证、消息合法性校验、会话管理等核心逻辑都在后端，跳过后端会丢失这些必要校验。
• 负载均衡适配：Kubernetes LoadBalancer确实会将客户端连接分散到不同Pod，后端作为统一入口，能将消息广播到Redis，确保所有相关Pod都能收到并推送给对应客户端。

问题2：Redis主题设计方案 #

推荐为每个聊天室（单聊/群聊）创建独立的Redis主题（比如命名为chat:{chatId}），具体实现逻辑：

• 当客户端连接到某个Pod时，该Pod会订阅这个客户端所在的所有聊天室主题。
• 当有消息发送到某个聊天室主题时，只有订阅了该主题的Pod会收到消息，然后推送给自己连接的对应客户端。
• 对比“每个Pod存储ChatId再过滤”的方案，按聊天室拆分主题能避免所有Pod接收全量消息再本地过滤，大幅减少Redis带宽和Pod的资源消耗，性能更优。

问题3：跨Pod消息推送失败的原因与解决 #

这个问题和当前LoadBalancer配置直接相关，核心是缺少会话亲和性配置：

• 默认的LoadBalancer是四层TCP负载均衡，没有开启会话保持时，客户端的WebSocket帧可能被转发到不同的Pod，而WebSocket是长连接，只有持有客户端连接的Pod才能推送消息。
• 解决办法：
  1. 修改LoadBalancer Service配置，添加会话亲和性：

     apiVersion: v1
     kind: Service
     metadata:
       name: lct-api-service
     spec:
       selector:
         app: lct-api
       type: LoadBalancer
       sessionAffinity: ClientIP  # 基于客户端IP保持会话
       sessionAffinityConfig:
         clientIP:
           timeoutSeconds: 3600  # 会话保持时长
       ports:
         - protocol: TCP
           port: 6008
           targetPort: 80
     

  2. 如果LoadBalancer不支持ClientIP亲和，或者需要更灵活的会话管理，可以换成Ingress（比如Nginx Ingress），配置基于Cookie的会话亲和性，同时确保Ingress支持WebSocket协议：

     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
       name: lct-api-ingress
       annotations:
         nginx.ingress.kubernetes.io/affinity: "cookie"
         nginx.ingress.kubernetes.io/session-cookie-name: "lct-session"
         nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
         nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
         nginx.ingress.kubernetes.io/websocket-services: "lct-api-service"
     spec:
       rules:
       - host: your-domain.com
         http:
           paths:
           - path: /
             pathType: Prefix
             backend:
               service:
                 name: lct-api-service
                 port:
                   number: 6008
     

  3. 同时检查后端.Net Core的Kestrel配置，确保开启长连接支持，比如在Program.cs中：

     builder.WebHost.ConfigureKestrel(options =>
     {
         options.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(30);
         options.Limits.RequestHeadersTimeout = TimeSpan.FromMinutes(30);
     });
     

内容的提问来源于stack exchange，提问作者kenik