K8s高流量Zone X的Fastify版NestJS应用突发OOM问题排查求助

已明确的故障观测特征 #

• 基础架构栈：基于Multi Zones架构拆分的NestJS Web应用（核心框架：nestjs v6.1.1、fastify v2.11.0），运行在物理隔离的两套Kubernetes集群（v1.18.12）上，配套Ingress组件版本v0.30.0，应用容器基于node:12-alpine（v12.18.3）构建
• 故障影响范围：仅集群A内承载全量最高流量的Zone X模块会触发故障，其余分区服务、集群B全量服务运行状态长期稳定
• 故障演化链路：故障初期集群A Ingress监控先观测到部分499响应，随后Zone X全量Pod的内存占用快速攀升至配置上限，依次触发OOM被驱逐；故障发生时，同集群内其他分区的服务无任何异常
• 已验证排除的常见诱因：
  • 全量流量切流到集群B后服务即可完全恢复，无脏数据类持续性故障特征
  • 强制重建集群A内Zone X的全部Pod后，只要流量切回集群A，故障立刻复现
  • 故障触发后停止往集群A切流，等待2-3小时再将流量切回，故障又会自行消失
  • 已排查Node.js生态常见的内存泄漏类场景，所有已知问题特征均与当前故障表现不匹配

分层落地排查方向 #

网络与Ingress配置维度 #

• 逐行对比集群A、集群B内Zone X对应的Ingress规则差异：重点核对长连接超时阈值、代理缓冲区大小、上游断开后连接回收逻辑——499状态本质是客户端主动断开连接，若代理侧或应用侧未正确回收已断开连接的关联资源，会导致大量未完成响应的上下文对象堆积在应用内存中，快速触发OOM
• 核查集群A内Zone X对应的Service端点列表：确认是否存在残留的历史下线Pod端点未被K8s正常摘除，导致大量无效连接被转发到已不存在的Pod地址，在应用层形成大量半开连接的缓冲区堆积。这类问题的特征与当前观测现象高度匹配：重建Pod时端点列表会被临时刷新，故障短暂消失；待K8s端点同步周期走完，无效端点重新被纳入转发列表，经过2-3小时的流量累积就会再次触发故障
• 对比集群A、集群B节点的内核网络参数配置：重点核查tcp_tw_recycle、tcp_max_orphans、somaxconn、netfilter_conntrack_max参数差异，确认是否因为高流量下内核连接跟踪表溢出、socket资源耗尽，导致用户态应用无法正确感知连接断开事件，持续缓存已经失效的请求上下文

应用运行时与框架版本维度 #

• 验证fastify v2.11.0与Node.js v12.18.3版本组合的已知资源回收缺陷：该版本组合存在已验证的兼容性问题——当请求被客户端主动断开时，fastify不会正确触发请求生命周期内的资源释放逻辑，会导致每个被断开的请求都在内存中留存未被回收的响应序列化对象，在高流量断开场景下会快速耗尽内存
• 核对两套集群内Zone X Pod的Node.js启动参数：重点确认--max-old-space-size配置值是否一致，排查是否因为K8s节点资源压力，导致集群A的Pod被自动注入了不同的堆内存阈值，老年代可用容量低于实际流量下的临时对象堆积水平，提前触发OOM
• 开启应用内存采样能力：在Pod内配置每30秒自动生成一次V8堆快照的逻辑，故障触发时拉取快照分析内存占用Top的对象类型。如果观测到大量未被回收的Request、Reply类框架核心对象，即可直接定位到连接断开后的资源泄漏点

集群调度与节点维度 #

• 核查集群A内Zone X Pod的实际调度分布：确认是否Pod被调度到存在网络瓶颈的Worker节点上（比如存在丢包、跨交换机延迟、防火墙拦截规则的节点），导致请求传输延迟升高，触发大量客户端主动断开。这类问题的特征与观测现象匹配：小流量分区服务因为请求量低，不会暴露网络瓶颈带来的影响；网络问题带来的连接积压需要经过2-3小时的流量累积，才会把内存占用推到触发OOM的阈值
• 对比两套集群的Kube-proxy配置差异：重点核查IPVS模式下的连接跟踪表容量、负载均衡算法配置，排查是否因为高流量下连接表项占满，导致大量请求被丢弃后触发客户端断开，形成应用侧的请求积压

所有复现类排查操作请优先在生产流量镜像环境验证，避免直接影响线上用户可用性

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