Kubernetes部署Node.js应用每50秒崩溃，Dockerfile配置问题排查

以下是你提供的Dockerfile以及Kubernetes部署场景下的具体错误和修复方案：

• 依赖安装逻辑冲突，易引发依赖版本/兼容性异常
  当前依赖安装顺序完全错误：拷贝package*.json后执行的npm install会安装全量依赖（含开发依赖），还可能修改镜像内的package-lock.json；后续拷贝本地完整代码时，会直接覆盖镜像内生成的package-lock.json，再执行npm ci --only=production。
  如果你没有配置.dockerignore忽略本地node_modules目录，拷贝操作还会把本地环境的node_modules（比如Windows/macOS系统编译的依赖）带入Linux容器，直接出现依赖兼容错误导致服务崩溃。
  修复方案：删除冗余的RUN npm install命令，仅保留拷贝代码后的RUN npm ci --only=production；同时在项目根目录新增.dockerignore文件，添加node_modules、.git、本地日志等不需要入镜像的目录。
• 服务监听地址配置错误概率极高
  如果你的server.js中服务默认监听127.0.0.1，就只能在容器本地访问，Kubernetes的存活/就绪探针无法探测到服务状态，连续探测失败后K8s会自动重启Pod，默认探针的失败阈值累计时间和你提到的50秒崩溃特征高度吻合。
  修复方案：修改server.js监听地址为0.0.0.0，示例代码如下：

  app.listen(4000, '0.0.0.0', () => {
    console.log('Service running on port 4000')
  })
  

• 可选优化项
  你引入dumb-init托管进程的逻辑是正确的，可以避免Node.js作为PID1进程的僵尸进程问题，也可以直接用Node官方镜像内置的--init参数替代，无需额外安装dumb-init，CMD可改为["node", "--init", "server.js"]以减少镜像体积。如果修复后仍有崩溃问题，可尝试升级基础镜像为更新的LTS版本，比如node:18-alpine、node:20-alpine，避免旧版本系统依赖兼容问题。
• 额外排查方向
  上述问题修复后如果服务仍崩溃，检查Kubernetes的Deployment配置：确认存活探针（livenessProbe）、就绪探针（readinessProbe）的探测端口为4000，探测路径为服务返回200状态码的正常路径，初始延迟时间不要设置过短，避免服务未启动完成就被探针强制杀掉。

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