容器应用优雅关闭
source link: https://www.bladewan.com/2021/05/26/graceful_close/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
容器应用优雅关闭
优雅关闭: 在关闭前,执行正常的关闭过程,释放连接和资源,如我们操作系统执行shutdown。
目前业务系统组件众多,互相之间调用关系也比较复杂,一个组件的下线、关闭会涉及到多个组件
对于任何一个线上应用,如何保证服务更新部署过程中从应用停止到重启恢复服务这个过程中不影响正常的业务请求,这是应用开发运维团队必须要解决的问题。传统的解决方式是通过将应用更新流程划分为手工摘流量、停应用、更新重启三个步骤,由人工操作实现客户端不对更新感知。这种方式简单而有效,但是限制较多:不仅需要使用借助网关的支持来摘流量,还需要在停应用前人工判断来保证在途请求已经处理完毕。
同时,在应用层也有一些保障应用优雅停机的机制,目前Tomcat、Spring Boot、Dubbo等框架都有提供相关的内置实现,如SpringBoot 2.3内置graceful shutdown可以很方便的直接实现优雅停机时的资源处理,同时一个普通的Java应用也可以基于Runtime.getRuntime().addShutdownHook()来自定义实现,它们的实现原理都基本一致,通过等待操作系统发送的SIGTERM信号,然后针对监听到该信号做一些处理动作。优雅停机是指在停止应用时,执行的一系列保证应用正常关闭的操作。这些操作往往包括等待已有请求执行完成、关闭线程、关闭连接和释放资源等,优雅停机可以避免非正常关闭程序可能造成数据异常或丢失,应用异常等问题。优雅停机本质上是JVM即将关闭前执行的一些额外的处理代码。
现阶段,业务容器化后业务启动是通过shell脚本启动业务,对应的在容器内PID为1的进程为shell进程但shell 程序不转发signals,也不响应退出信号。所以在容器应用中如果应用容器中启动 shell,占据了 pid=1 的位置,那么就无法接收k8s发送的SIGTERM信号,只能等超时后被强行杀死了。
go开发的一个Demo
代码参考:https://www.jianshu.com/p/ae72ad58ecb6
1、Signal.Notify会监听括号内指定的信号,若没有指定,则监听所有信号。
2、通过switch对监听到信号进行判断,如果是SININT和SIGTERM则条用Exitfunc函数执行退出。
SHELL模式和CMD模式带来的差异性
编写应用Dockerfile文件
概述
在Dockerfile中CMD和ENTRYPOINT用来启动应用,有shell模式和exec模式,对应的使用shell模式,PID为1的进程为shell,使用exec模式PID为1的进程为业务本身。
SHELL模式
可以看见PID为1的进程是sh进程
此时执行docker stop,业务进程是接收不到SIGTERM信号的,要等待一个超时时间后被KILL
日志没有输出SIGTERM关闭指令
EXEC模式
可以看见PID为1的进程是应用进程
此时执行docker stop,业务进程是可以接收SIGTERM信号的,会优雅退出
注意:
1、以下测试在ubuntu做为应用启动base镜像测试成功,在alpine做为应用启动base镜像时shell模式和exec模式都一样,都是应用进程为PID 1的进程。
直接启动应用和通过脚本启动区别
在实际生产环境中,因为应用启动命令后会接很多启动参数,所以通常我们会使用一个启动脚本来启动应用,方便我们启动应用。对应的在容器内PID为1的进程为shell进程但shell 程序不转发signals,也不响应退出信号。所以在容器应用中如果应用容器中启动 shell,占据了 pid=1 的位置,那么就无法接收k8s发送的SIGTERM信号,只能等超时后被强行杀死了。
启动脚本
start.sh
docker stop关闭应用
是登待超时后被强行KILL
容器应用优雅关闭方案介绍
正常的优雅停机可以简单的认为包括两个部分:
- 应用:应用自身需要实现优雅停机的处理逻辑,确保处理中的请求可以继续完成,资源得到有效的关闭释放,等等。针对应用层,不管是Java应用还是其他语言编写的应用,其实现原理基本一致,都提供了类似的监听处理接口,根据规范要求实现即可。
- 平台:平台层要能够将应用从负载均衡中去掉,确保应用不会再接受到新的请求连接,并且能够通知到应用要进行优雅停机处理。在传统的部署模式下,这部分工作可能需要人工处理,但是在K8s容器平台中,K8s的Pod删除默认就会向容器中的主进程发送优雅停机命令,并提供了默认30s的等待时长,若优雅停机处理超出30s以后就会强制终止。同时,有些应用在容器中部署时,并不是通过容器主进程的形式进行部署,那么K8s也提供了PreStop的回调函数来在Pod停止前进行指定处理,可以是一段命令,也可以是一个HTTP的请求,从而具备了较强的灵活性。
通过以上分析,理论上应用容器化部署以后仍然可以很好的支持优雅停机,甚至相比于传统方式实现了更多的自动化操作,本文档后面会针对该方案进行详细的方案验证。 - 容器应用中第三方Init:在构建应用中使用第三方init如tini或dumb-init
方案一:
通过k8s的prestop参数调用容器内进程关闭脚本,实现优雅关闭。
方案二:
通过第三方init进程传递SIGTERM到进程中。
方案一:通过k8s Prestop参数调用
在前面脚本启动的dockerfile基础上,定义一个优雅关闭的脚本,通过k8s-prestop在关闭POD前调用优雅关闭脚本,实现pod优雅关闭。
启动脚本
start.sh
stop.sh
优雅关闭脚本
通过yaml部署到k8s中
查看POD日志,然后删除pod副本
另外窗口删除POD
可以看见执行了Prestop脚本进行优雅关闭。
同样的可以将yaml文件中的Prestop脚本取消进行对比测试可以发现就会进行强制删除。
方案二:shell脚本修改为exec执行
修改start.sh
脚本
shell中添加一个 exec 即可让应用进程替代当前shell进程,可将SIGTERM信号传递到业务层,让业务实现优雅关闭。
可使用上面例子,进行修改测试。
方案三:通过第三init工具启动
使用dump-init或tini做为容器的主进程,在收到退出信号的时候,会将退出信号转发给进程组所有进程。,主要适用应用本身无关闭信号处理的场景。docker –init本身也是集成的tini。
发现容器快速停止了,但没有输出应用关闭和清理的日志
后面查阅相关资料发现
使用tini或dump-init做为应用启动的主进程。
tini和dumb-init会将关闭信号向子进程传递,但不会等待子进程完全退出后自己在退出。而是传递完后直接就退出了。
相关issue:
https://github.com/krallin/tini/issues/180
后面又查到另外一个第三方的组件smell-baron能实现等待子进程优雅关闭后在关闭本身功能。 但这个项目本身热度不是特别高,并且有很久没有维护了。
1、对于容器化应用启动命令建议使用EXEC模式。
2、对于应用本身代码层面已经实现了优雅关闭的业务,但有shell启动脚本,容器化后部署到k8s上建议使方案一和方案二。
3、对于应用本身代码层面没有实现优雅关闭的业务,建议使用方案三。
项目地址:
https://github.com/insidewhy/smell-baron
https://github.com/Yelp/dumb-init
https://github.com/krallin/tini
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK