Node.js应用部署AKS集群Nginx Ingress报502及Connection reset by peer错误求助

针对你遇到的本地正常、AKS部署后出现502（错误码104）的问题，结合Django应用正常的现状，按以下步骤逐一排查：

1. 检查Node.js应用的监听地址 #

Node.js应用若本地监听localhost（如app.listen(3000, 'localhost')），容器内外部请求无法访问，会直接导致连接重置。修改为监听0.0.0.0：

app.listen(3000, '0.0.0.0', () => {
  console.log('Server running on port 3000');
});

2. 验证Kubernetes Service与Endpoint配置 #

• 确认Service的targetPort与Node.js应用的监听端口完全一致；
• 执行kubectl get endpoints <your-nodejs-service-name>，检查输出中是否包含就绪的Pod IP与端口：
  • 若Endpoint为空或无就绪状态的Pod，说明Pod未通过就绪探针，直接排查探针配置；
  • 若Endpoint正常，手动在集群内测试Service连通性：

    kubectl run -it --rm curl-test --image=curlimages/curl -- curl <your-nodejs-service-name>.<namespace>.svc.cluster.local/sp-platform/vehicles -X POST -d 'test'
    

    若请求失败，问题出在Pod或Service层面；若成功，再聚焦Ingress配置。

3. 检查Pod的就绪/存活探针配置 #

探针配置错误会导致Pod被标记为未就绪，Ingress转发流量时会出现连接重置：

• 确认探针的httpGet.path是应用实际可响应的健康检查路径（如/healthz），且应用已实现该端点；
• 确认探针的port与应用监听端口一致；
• 查看Pod事件：kubectl describe pod <your-nodejs-pod-name>，检查是否有探针失败的记录。

4. 查看Node.js应用的实时日志 #

当触发502错误时，应用可能因未捕获异常崩溃，导致连接重置：

kubectl logs <your-nodejs-pod-name> -f

重点关注请求触发时的报错（如内存溢出、body解析失败、依赖缺失等）。

5. 验证Ingress规则的Backend配置 #

日志中upstream: "http:///vehicles"显示上游地址异常，检查Ingress规则：

• 确认spec.rules.http.paths.backend.service.name是Node.js应用对应的正确Service名称；
• 确认service.port.number或service.port.name与Service的端口配置匹配；
• 对比Django应用的Ingress规则，排查是否存在配置差异（如路径重写、注解等）。

6. 检查Node.js应用的请求处理限制 #

• 若POST请求体较大，确认应用已配置对应大小的body解析限制（以Express为例）：

  app.use(express.json({ limit: '50mb' }));
  app.use(express.urlencoded({ extended: true, limit: '50mb' }));
  

  确保应用的限制不小于Ingress的proxy_body_size（50m）。

7. 排查NetworkPolicy限制 #

若集群配置了NetworkPolicy，确认Ingress Controller所在命名空间（通常是kube-system）有权限访问Node.js应用所在命名空间的Pod端口：

• 检查应用命名空间下的NetworkPolicy资源：kubectl get networkpolicy -n <your-namespace>；
• 临时移除NetworkPolicy测试，若问题解决，需调整规则允许Ingress Controller的流量。

8. 核对容器与本地的依赖版本 #

确保容器内安装的依赖与本地完全一致：

• 构建镜像时正确拷贝package-lock.json或yarn.lock；
• 检查Dockerfile中是否使用了npm ci而非npm install，避免依赖版本不一致。

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