一个合适的处理方法是使用“粘性会话”。这是基于cookie的设置将用户固定到特定的pod。
下面是配置Ingress资源对象以使用粘性会话的示例：

#
# https://github.com/kubernetes/ingress-nginx/tree/master/docs/examples/affinity/cookie
#
apiVersion: extensions/v1beta1  
kind: Ingress  
metadata:  
  name: nginx-test-sticky
  annotations:
    kubernetes.io/ingress.class: "nginx"
    ingress.kubernetes.io/affinity: "cookie"
    ingress.kubernetes.io/session-cookie-name: "route"
    ingress.kubernetes.io/session-cookie-hash: "sha1"
spec:
  rules:
  - host: $HOST
    http:
      paths:
      - path: /
        backend:
          serviceName: $SERVICE_NAME
          servicePort: $SERVICE_PORT

字符串
现在说了这么多，处理这个问题的正确方法是使用消息代理或支持集群的WebSocket实现，如socketcluster（https://socketcluster.io）。

我刚刚在Azure Kubernetes Service（AKS）上完成了WebSocket服务器的生产部署（使用Sping Boot 构建），利用Kafka作为世界状态（SoTW），没有任何子协议，如STOMP等。
我想分享我的经验。一些挑战和解决方案已经在答案中列出。但是，我想在这里综合一下。

挑战：

1.**持久连接：**Kubernetes的负载均衡机制可能不支持长期的WebSocket连接，需要额外的配置或专用的入口控制器，如NGINX或Envoy。
1.**会话粘性：**确保用户会话与同一Pod的连接一致可能具有挑战性，通常需要会话关联规则或粘性会话。
1.**复杂性增加：**在Kubernetes上管理WebSockets增加了一层复杂性，需要对Kubernetes概念和配置有更深入的理解。
1.**监控和故障排除：**由于集群的分布式特性和多层基础架构，集群内WebSocket问题的故障排除可能更加复杂。

决定因素：

1.**流量和可变性：**如果您的WebSocket服务器遇到高流量或不可预测的流量，Kubernetes的可扩展性和高可用性特性将非常有益。
1.**部署频率：**如果您需要频繁更新或部署新版本的WebSocket服务器，Kubernetes简化的部署流程非常有利。
1.**集成需求：**如果您的应用涉及WebSocket服务器和其他服务之间的复杂交互，Kubernetes的服务发现和集成功能非常有价值。
1.**团队专业知识：**考虑您的团队对Kubernetes的熟悉程度以及管理增加的复杂性的意愿。

最佳实践：

1.**选择Ingress Controller：**选择支持WebSockets的Ingress Controller，如NGINX或Envoy。
1.**配置会话亲和度：**实现会话亲和度规则，确保同一Pod连接一致。
1.**有效监控和调试：**使用工具和技术在Kubernetes中监控和调试WebSockets。
1.**考虑服务网格：**对于高级负载平衡和服务到服务通信，请探索像Istio这样的服务网格解决方案。
在Kubernetes上部署WebSocket服务器在可扩展性、高可用性、资源优化和部署管理方面具有显著优势。但是，解决持久连接、会话粘性和复杂性增加的挑战至关重要。请仔细评估应用程序的需求和团队专业知识，以做出明智的决策。
此外，你似乎是在正确的轨道上，因为这个问题有点老，请分享你的经验，以及你是如何最终实现它.