K8S避坑指南 - Deployment更新POD内容器没法收到SIGTERM信号

开源项目推荐

Pepper Metrics是我与同事开发的一个开源工具(github.com/zrbcool/pep…)，其经过收集jedis/mybatis/httpservlet/dubbo/motan的运行性能统计，并暴露成prometheus等主流时序数据库兼容数据，经过grafana展现趋势。其插件化的架构也很是方便使用者扩展并集成其余开源组件。
请你们给个star，同时欢迎你们成为开发者提交PR一块儿完善项目。

简述

容器化后，在应用发布时，某个服务重启，致使该服务调用方大量报错，直到服务重启完成。报错的内容是RPC调用失败，咱们的RPC这块是有优雅关闭的，也就是说，在进程收到SIGTERM信号后，咱们经过JVM的ShutdownHook机制，注册了RPC服务的反注册钩子，在进程收到SIGTERM时应用会主动从注册中心摘除自身防止调用方大量报错。可是为何容器化后会致使这个问题呢？

问题排查

应用正常启动

查看容器内进程

# yum install psmisc
# pstree -p
bash(1)───java(22)─┬─{java}(23)
                   ├─{java}(24)
                   ├─{java}(25)
                   ├─{java}(26)
                   ├─{java}(27)
                   ├─{java}(28)
                   ├─{java}(29)
                   ├─{java}(30)
                    ...
# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 09:50 ?        00:00:00 /bin/bash run.sh start
root        22     1 15 09:50 ?        00:01:20 /app/3rd/jdk/default/bin/java -Xmx512m -Xms512m ...
root        49     0  0 09:51 pts/0    00:00:00 bash
root       263    49  0 09:59 pts/0    00:00:00 ps -ef
复制代码

在容器内正常kill 22子进程，可见咱们应用的shutdown钩子能够正确处理善后工做

可是，在实际生产中，咱们的deploy滚动更新时，经过查看被删除pod的日志，发现pod被terminate的时候，应用进程并未正确处理SIGTERM信号，问题产生。

问题分析

根据对Kubernetes机制的调研，如图： kubernetes.io/docs/concep…

由于咱们的容器是经过run.sh脚本启动，这个在前面截图能够看到，java进程是1号run.sh进程的子进程，对应Kubernetes原理，可知22号java进程在POD删除时不必定会收到SIGTERM，因此致使了咱们的shutdown hook不生效。

问题解决

既然已经定位问题，那么解决问题的方法就有了思路，run.sh执行java进程后，将进程上下文让给java进程，java进程接管，java进程变为容器内的1号进程。 咱们参考了这篇文章受到启发 yeasy.gitbooks.io/docker_prac… 在run.sh执行java前面增长exec命令便可

而后，从新build镜像，发布，查看进程，发现咱们的java进程已是1号进程

而后重启，再查看重启前POD留下的日志

问题解决！