Kubernetes部署Node.js报exit code 243 CrashLoopBackOff排查

Node.js场景下exit code 243的本质是 128 + 15，代表容器内的Node进程收到SIGTERM信号后退出，问题不在K8s核心组件，出在容器内应用逻辑、镜像构建或K8s资源配置层面，按以下优先级排查：

第一步：拉取崩溃实例的全量日志 #

kubectl describe pod 只会展示K8s层面的事件，不会输出容器内应用的报错，这是绝大多数人卡壳的原因。执行以下命令拿上一个崩溃容器的日志（容器刚启动就退出时，当前实例没有留存日志，必须加-p参数）：

kubectl logs <故障Pod名称> -c <对应容器名> -p

重点排查日志里的以下典型报错：

• 依赖缺失：提示Cannot find module xxx，基本是镜像构建时没执行npm install --production，或者.dockerignore错误排除了必要文件
• 配置缺失：提示连接数据库/中间件失败、环境变量未定义，是ConfigMap/Secret/环境变量配置漏配、拼写错误导致
• 权限错误：提示EACCES: permission denied，是非root启动用户对应用目录、日志目录没有读写权限导致
• 语法错误：提示Unexpected token之类的语法报错，是镜像内Node.js版本和本地开发版本不兼容导致

第二步：本地复现验证镜像启动逻辑 #

如果日志没有输出有效信息，直接在本地运行镜像排除构建错误：

# 启动镜像并进入交互shell
docker run --rm -it <你的镜像地址:版本标签> sh

进入容器后手动执行Dockerfile里定义的启动命令（比如npm start、node index.js），看是否能正常启动：

• 如果手动执行启动命令直接报错，问题出在镜像本身：常见原因包括Dockerfile里CMD指令写错、package.json里没有定义start脚本、npm install因为网络问题装包失败、基础镜像Node版本过低不支持新语法
• 如果手动执行启动命令能正常跑，问题出在K8s侧配置，直接走第三步排查

第三步：排查K8s侧触发进程终止的配置 #

exit code 243是SIGTERM信号触发的，除了应用主动退出，也可能是K8s主动给进程发终止信号：

• 检查资源配置：如果memory limit配置过小，Node.js启动内存占用超过限制，部分K8s版本不会直接标记OOMKilled，会先发SIGTERM终止进程。直接把memory limit调到512Mi、cpu limit调到0.5核测试
• 检查探针配置：如果livenessProbe的initialDelaySeconds配置过短，应用还没完成启动探针就连续探测失败，K8s会反复重启容器；如果探针探测的端口、路径和应用实际监听的不一致，也会触发误杀。直接临时注释掉探针配置测试，确认是探针问题后再调大初始延迟、重试阈值
• 检查安全策略：如果集群开启了Pod安全准入、SELinux/AppArmor策略，禁止容器绑定1024以下端口、禁止root用户启动但镜像没做用户降级，也会导致进程被系统终止。直接临时配置privileged: true测试，确认是权限问题后再按需调整安全上下文

高频场景快速修复 #

• 依赖/镜像问题：重新构建镜像，确保Dockerfile在复制完项目代码后执行npm install --production，不要把本地的node_modules目录直接打包进镜像
• 启动命令问题：把Dockerfile里的CMD改成数组格式，比如CMD ["node", "app.js"]，避免shell格式启动导致的信号传递异常
• 探针问题：Node.js应用冷启动通常需要10-30s，建议把livenessProbe的initialDelaySeconds设为30，failureThreshold设为5，给应用留够启动时间
• 权限问题：如果用非root用户启动，在Dockerfile里提前给应用目录、日志目录赋对应用户的读写权限，不要在K8s侧强行提权
• 资源问题：Node.js应用初始内存限制建议不低于256Mi，后续根据实际监控数据调整配额

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