Kubernetes执行新部署时是否会向PM2发送进程终止信号？

你观察到的PM2以退出码0、收到SIGINT退出的现象，是Kubernetes Deployment滚动更新旧Pod时的正常流程表现，不属于应用或PM2运行异常。Kubernetes在销毁旧Pod时确实会向容器内主进程发送终止信号，PM2收到信号后执行优雅退出逻辑就会产生你看到的日志。

• Kubernetes滚动更新触发旧Pod终止时，首先会将旧Pod从Service端点列表中摘除，不再转发新流量，随后向容器内PID为1的主进程发送SIGTERM信号，默认等待30秒（可通过terminationGracePeriodSeconds字段自定义）供进程做优雅退出，超时后发送SIGKILL强制销毁进程。
• 正常情况下使用容器推荐的pm2-runtime命令启动PM2时，PM2会直接作为PID1进程运行，收到SIGTERM后默认会向托管的Node.js业务进程转发SIGINT信号，等待业务进程处理完存量请求、释放资源退出后，PM2自身也会以0状态码退出，和你贴出的日志特征完全吻合。

如果你的发布流程存在卡顿、旧Pod退出慢、请求报错的问题，可以对照调整配置：

• 禁止用普通pm2 start命令在容器中启动应用：该模式会让PM2后台守护运行，容器主进程会立刻退出触发Pod异常重启，必须使用pm2-runtime作为启动命令，保证PM2在前台运行、正常接收K8s信号。
• 不要用裸shell作为PID1进程：如果通过shell脚本启动PM2，需要在启动命令前加exec，比如exec pm2-runtime ./api.bundle，让PM2替换shell进程成为PID1，避免shell默认不转发信号导致PM2收不到终止指令、最终被强杀。
• 对齐PM2和K8s的优雅退出超时时间：在PM2的ecosystem.config.js配置中设置kill_timeout参数，和K8s侧的terminationGracePeriodSeconds保持一致，避免PM2提前强杀业务进程、或者K8s超时后强制杀死PM2导致存量请求中断。
• 不需要在PM2配置中开启针对信号退出的自动重启：PM2收到终止信号后主动退出属于正常行为，旧Pod本身就要被销毁，自动重启只会拉长旧Pod的终止时间，拖慢发布节奏。

只要发布过程中没有出现业务请求报错、新旧版本衔接异常，你观察到的PM2退出日志属于完全正常的行为，不需要做特殊修复。

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