在AWS EKS部署WebSocket应用无需ALB/nginx ingress是否为合理方案？

一、原生EKS运行WebSocket应用是否存在遗漏配置 #

你当前应用已经稳定运行，说明现有配置适配你的业务场景，原生EKS本身没有针对WebSocket的强制特殊配置要求，你可以核对以下常规配置点确认无遗漏即可：

• 检查服务对应安全组规则：已经开放WebSocket使用的端口入方向流量，同时出站规则允许到Pod网段的通信
• 检查Kubernetes Service的会话保持配置：如果是多副本部署、客户端需要固定连接同一个Pod，需要确认是否配置了service.spec.sessionAffinity: ClientIP，如果你的echo-server是无状态、不需要会话保持也可正常工作可忽略该配置
• 检查kube-proxy的运行模式：无论是IPVS还是iptables模式，原生都天然支持TCP长连接，不会主动中断WebSocket连接，仅需确认集群TCP连接空闲超时配置符合业务要求，默认TCP连接空闲超时一般为3600秒，如果你的业务需要更长的空闲连接，可调整节点内核参数net.ipv4.tcp_keepalive_time为更小值，让内核主动发送保活包避免连接被中间网络设备断开
• 如果你是用LoadBalancer类型Service对外暴露服务，需确认对应AWS NLB（EKS默认LoadBalancer类型Service绑定的是AWS NLB而非ALB）的空闲超时配置，AWS NLB默认空闲超时为350秒，如果你的WebSocket连接会有超过该时长的空闲无数据情况，可将NLB空闲超时调整到业务预期值，或者在应用层实现心跳包机制定期传输小数据包保活

二、WebSocket场景是否必须使用AWS ALB或者Nginx Ingress Controller #

不是必须，是否使用完全取决于你的业务需求：

• 如果你只有单个WebSocket应用，不需要复杂的路由规则（比如根据域名、路径分流到不同服务），也不需要统一的SSL卸载、限流、鉴权等能力，直接用LoadBalancer类型的Service或者NodePort加外部负载均衡完全可以满足需求，不需要额外部署Ingress组件
• 多数资料提到的ALB、Nginx Ingress在WebSocket场景的问题，本质都是默认配置适配问题：
  • Nginx Ingress默认的代理读取、发送超时仅为60秒，WebSocket连接空闲超过60秒就会被断开，需要手动配置proxy-read-timeout、proxy-send-timeout参数延长，同时还要配置proxy-set-upgrade、proxy-set-connection等请求头支持WebSocket协议升级
  • AWS ALB默认也需要手动调整监听器的空闲超时，支持WebSocket升级还需要配置对应目标组属性，且ALB属于七层负载均衡，长连接承载能力比四层的NLB弱
• 如果你后续有多个服务需要统一入口、域名路由、统一SSL证书管理这类需求，再考虑引入Ingress组件也完全来得及，只要提前做好对应WebSocket适配配置即可，没有提前部署的必要性。

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