使用Helm升级Minikube上Node.js容器时遇Readiness Probe失败问题

我来帮你一步步排查这个就绪探针连接拒绝的问题，这在Node.js + Kubernetes/Minikube的场景里挺常见的，咱们从最可能的原因开始查起：

1. 确认Node.js应用是否正确监听了0.0.0.0而非localhost #

这是最常见的原因！很多Node.js开发者会默认写app.listen(3003)，这时候应用只会监听localhost（127.0.0.1），容器外部（包括Kubernetes的探针）根本访问不到。

• 先找到你的Pod：kubectl get pods
• 进入Pod的容器：kubectl exec -it <你的Pod名称> -- /bin/bash（如果是Alpine镜像，换成sh）
• 检查端口监听状态：执行netstat -tulpn | grep 3003或者ss -tulpn | grep 3003
  • 如果输出显示127.0.0.1:3003，那就是问题所在！修改你的Node.js代码，把监听地址改成0.0.0.0：

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

  • 如果看不到任何输出，说明应用根本没启动或者没监听3003端口，直接看下面的日志排查步骤。

2. 检查应用启动日志，确认是否有启动失败的情况 #

有时候应用因为依赖缺失、配置错误等原因没正常启动，自然不会监听端口：

• 获取Pod的完整日志：kubectl logs <你的Pod名称>
• 如果是重启过的Pod，加上--previous参数看之前的日志：kubectl logs <你的Pod名称> --previous
• 检查日志里有没有报错信息，比如module not found、数据库连接失败等，这些都会导致应用启动失败。

3. 验证容器端口映射与探针配置是否正确 #

• 查看Pod的详细描述，确认端口和探针配置：kubectl describe pod <你的Pod名称>
  • 在Containers部分，检查Ports是否包含containerPort: 3003，协议为TCP
  • 在Readiness Probe部分，确认：
    • httpGet的port是3003，而不是其他端口
    • path是/，如果你的应用根路径没有响应（比如需要特定路径），也可能导致失败，但当前报错是连接拒绝，所以先聚焦端口
    • initialDelaySeconds是否设置合理：如果你的应用启动较慢（比如需要加载大量依赖），这个值太小会导致探针在应用未就绪时就发起请求。可以尝试调大到30或60，给应用足够的启动时间。

4. 在Minikube节点上测试连通性 #

直接在Minikube节点上尝试访问容器IP和端口，确认网络是否可达：

• 进入Minikube节点：minikube ssh
• 执行curl http://172.17.0.6:3003或者telnet 172.17.0.6 3003
  • 如果这里也提示连接拒绝，说明问题确实在容器内部的应用监听或启动状态
  • 如果这里能正常访问，那可能是Kubernetes的网络策略或Pod网络配置问题，但这种情况比较少见，先确保前面的步骤都没问题。

5. 检查Helm Chart的配置是否正确 #

最后确认Helm模板里的Deployment配置：

• 检查containers.ports是否正确设置了containerPort: 3003
• 检查就绪探针的配置是否和你预期一致，比如端口、路径、超时时间等
• 升级后如果配置有变更，可以用kubectl get deployment <你的Deployment名称> -o yaml查看实际生效的配置，是否和Helm Chart中的定义一致。

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