Kubernetes中Flask-SocketIO多副本Ingress会话粘滞问题求助

核心问题定位 #

你遇到的400错误和连接中断，核心原因是SSL Passthrough配置与Ingress会话亲和性冲突：当开启enable-ssl-passthrough: "true"时，Nginx Ingress会直接转发SSL流量到后端Pod，跳过自身的SSL终止流程，导致Ingress层面的cookie/ip_hash亲和性配置完全失效，请求会被随机分发到不同Pod，破坏WebSocket的长连接绑定。

具体解决方案 #

1. 优先解决SSL Passthrough与亲和性的冲突 #

方案A：关闭SSL Passthrough（推荐，若Ingress可统一处理SSL）

如果你的后端Pod不需要直接处理SSL证书，建议关闭enable-ssl-passthrough，让Ingress负责SSL终止，此时Ingress的cookie亲和性可以正常生效：

• 移除Ingress中的nginx.ingress.kubernetes.io/enable-ssl-passthrough: "true"配置
• 补充完整的Ingress亲和性配置，确保WebSocket路径的会话粘滞：

  nginx.ingress.kubernetes.io/affinity: "cookie"
  nginx.ingress.kubernetes.io/session-cookie-name: "socketio_route"
  nginx.ingress.kubernetes.io/session-cookie-hash: "sha1"
  nginx.ingress.kubernetes.io/session-cookie-path: "/"
  nginx.ingress.kubernetes.io/session-cookie-expires: "3600"
  nginx.ingress.kubernetes.io/session-cookie-max-age: "3600"
  

• 确保Ingress规则包含WebSocket路径/socket.io/的转发：

  spec:
    rules:
    - host: your-domain.com
      http:
        paths:
        - path: /socket.io/
          pathType: Prefix
          backend:
            service:
              name: your-flask-socketio-service
              port:
                number: 80
  

方案B：保留SSL Passthrough，改用Service层会话亲和性

如果必须让后端Pod处理SSL（比如需要自定义证书逻辑），则Ingress层面的亲和性无法生效，需在Service配置中设置会话粘滞：

apiVersion: v1
kind: Service
metadata:
  name: your-flask-socketio-service
spec:
  selector:
    app: your-flask-app
  ports:
    - port: 443
      targetPort: 2731
      protocol: TCP
  sessionAffinity: ClientIP  # 基于客户端IP绑定会话，适合无Cookie场景
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600  # 会话超时时间，按需调整

若需要更灵活的Cookie绑定，可将sessionAffinity设为Cookie并配置对应的参数，但需注意Service的Cookie亲和性仅在HTTP/HTTPS流量中生效，WebSocket连接同样依赖初始握手的会话绑定。

2. 优化Flask-SocketIO与Gunicorn配置 #

• 显式指定SocketIO的异步模式为gevent，匹配Gunicorn的Worker类型：

  socketio = SocketIO(app, message_queue='redis://redis-server.domain:6379', async_mode='gevent')
  

• 调整Gunicorn的超时配置，适配WebSocket长连接：

  CMD ["gunicorn", "-k", "geventwebsocket.gunicorn.workers.GeventWebSocketWorker", "-w", "4", "--timeout", "300", "--bind", "0.0.0.0:2731", "app:app"]
  

3. 验证Redis消息队列可用性 #

确保所有Pod都能正常访问redis-server.domain:6379，Redis无权限限制或网络隔离问题——消息队列是多Pod间SocketIO事件同步的关键，若连接失败会导致跨Pod的消息无法传递，但不会直接引发400错误，需作为基础验证项。

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