[Kubernetes]为什么有时会出现删除POD后要等一段时间才能被删掉
正常情况下，执行kubectl delete pod之后，pod一般会立即被删除。但是偶尔会出现这样一种情况，删除pod之后，pod的状态一直显示为terminating，需要等待一段时间才会被删除，这是什么原因呢？
name ready status restarts agenginx 1/1 terminating 0 4m34s
首先我们来了解一下，删除pod时，k8s做了哪些操作
typically, with this graceful termination of the pod, kubelet makes requests to the container runtime to attempt to stop the containers in the pod by first sending a term (aka. sigterm) signal, with a grace period timeout, to the main process in each container. the requests to stop the containers are processed by the container runtime asynchronously. there is no guarantee to the order of processing for these requests. many container runtimes respect the stopsignal value defined in the container image and, if different, send the container image configured stopsignal instead of term. once the grace period has expired, the kill signal is sent to any remaining processes, and the pod is then deleted from the api server
上图为k8s官方文档上的说明，这一大段简单概括起来就是如下两步：
kubelet发送kill 1到pod
经过terminationgraceperiodseconds(一般为30s)之后，如果pod还没被删掉，则直接发送kill -9 1强制杀掉进程
至于这里为什么会等待30s，原因如下: k8s pod在结束前可能需要执行一些命令，这些命令可以设置在prestop中进行设置，在删除pod的时候，prestop hook和sigterm 信号并行发生，但是kubernetes 不会等待 prestop hook 完成，所以这里需要设置一个等待时间让prestop执行完成之后，在删除pod，这个等待时间就是通过terminationgraceperiodseconds进行设置的.
但是我们的pod里并没有设置prestop,还是等待了30s pod才彻底被删除
所以这里的问题可能是第1步中, kill 1并没有将进程杀掉, 也就是说进程并没有响应sigterm信号
为什么会出现这种情况呢, 进入到容器中看下具体的进程:
uid pid ppid c stime tty time cmdroot 1 0 0 08:58 ? 0000 bash /start.shroot 7 1 94 08:58 ? 0013 python3 /server.py
可以看到有两个进程, 其中1为主进程, 7为1的子进程, start.sh内容如下:
#!/usr/bin/env bashpython3 /server.py
通过执行shell脚本拉起真正的业务进程, 而且以阻塞方式运行, 删除pod时, 发送的sigterm信号不会有任何响应, 因为传递不到子进程7, 无法结束子进程, 进而导致pod无法结束.
这里可能会有这样的疑问, 为什么不直接启动业务进程呢? 这是因为有些场景下, 在启动业务进程之前, 需要进行一些初始化操作, 又不想或者不能通过init-container来完成, 只能通过启动脚本去做, 启动脚本初始化结束之后, 再将业务进程拉起.
如何避免这类问题
尽量直接启动业务进程, 不要依赖进程拉起业务进程, 初始化操作尽量通过init-container来完成
在启动脚本里捕获sigterm, 并将其传递到子进程
#!/usr/bin/env bashexit_func() { pkill python3 exit}trap 'exit_func' sigtermpython3 /server.py &while truedo sleep 1done
如上所示, 将start.sh调整一下, 这样就能将sigterm传递到子进程, 让pod快速结束
链接：https://juejin.cn/post/7314804357697945637
区块链能为自由职业者带来什么帮助
如何使用检测模型进行唤醒词检测模型的部署
浅谈隔离变压器铁芯的作用功率和性质
联结组变压器的特点
深度解密石墨烯重大突破：“黑科技”石墨烯究竟给我们带来了什么？
[Kubernetes]为什么有时会出现删除POD后要等一段时间才能被删掉
eSATA接口是什么
SEPIC方程和分量额定值
英特尔宣布10nm 芯片将实现全面量产
环网柜的SF6气体的年泄漏率标准问题是什么
测评 快充移动电源哪个好？SuperMini实力领航
Opera将尽快发布补丁修复桌面浏览器漏洞
人工智能正在推动自动驾驶的创新步伐
机智云怎么使用？iot开发平台快速开发硬件产品案例分享
TCO99 |电磁辐射 |6轴色彩控制
IGBT模块单极驱动的特殊注意事项
数字孪生支撑万物互联
助听器的工作原理
Buck变换器和Boost变换器原理分析
Fraunhofer HHI 适用于 TCP/UDP/IP 处理的 10 GigE 网络协议加速器现已针对 Zynq SoC 提供
name ready status restarts agenginx 1/1 terminating 0 4m34s
首先我们来了解一下，删除pod时，k8s做了哪些操作
typically, with this graceful termination of the pod, kubelet makes requests to the container runtime to attempt to stop the containers in the pod by first sending a term (aka. sigterm) signal, with a grace period timeout, to the main process in each container. the requests to stop the containers are processed by the container runtime asynchronously. there is no guarantee to the order of processing for these requests. many container runtimes respect the stopsignal value defined in the container image and, if different, send the container image configured stopsignal instead of term. once the grace period has expired, the kill signal is sent to any remaining processes, and the pod is then deleted from the api server
上图为k8s官方文档上的说明，这一大段简单概括起来就是如下两步：
kubelet发送kill 1到pod
经过terminationgraceperiodseconds(一般为30s)之后，如果pod还没被删掉，则直接发送kill -9 1强制杀掉进程
至于这里为什么会等待30s，原因如下: k8s pod在结束前可能需要执行一些命令，这些命令可以设置在prestop中进行设置，在删除pod的时候，prestop hook和sigterm 信号并行发生，但是kubernetes 不会等待 prestop hook 完成，所以这里需要设置一个等待时间让prestop执行完成之后，在删除pod，这个等待时间就是通过terminationgraceperiodseconds进行设置的.
但是我们的pod里并没有设置prestop,还是等待了30s pod才彻底被删除
所以这里的问题可能是第1步中, kill 1并没有将进程杀掉, 也就是说进程并没有响应sigterm信号
为什么会出现这种情况呢, 进入到容器中看下具体的进程:
uid pid ppid c stime tty time cmdroot 1 0 0 08:58 ? 0000 bash /start.shroot 7 1 94 08:58 ? 0013 python3 /server.py
可以看到有两个进程, 其中1为主进程, 7为1的子进程, start.sh内容如下:
#!/usr/bin/env bashpython3 /server.py
通过执行shell脚本拉起真正的业务进程, 而且以阻塞方式运行, 删除pod时, 发送的sigterm信号不会有任何响应, 因为传递不到子进程7, 无法结束子进程, 进而导致pod无法结束.
这里可能会有这样的疑问, 为什么不直接启动业务进程呢? 这是因为有些场景下, 在启动业务进程之前, 需要进行一些初始化操作, 又不想或者不能通过init-container来完成, 只能通过启动脚本去做, 启动脚本初始化结束之后, 再将业务进程拉起.
如何避免这类问题
尽量直接启动业务进程, 不要依赖进程拉起业务进程, 初始化操作尽量通过init-container来完成
在启动脚本里捕获sigterm, 并将其传递到子进程
#!/usr/bin/env bashexit_func() { pkill python3 exit}trap 'exit_func' sigtermpython3 /server.py &while truedo sleep 1done
如上所示, 将start.sh调整一下, 这样就能将sigterm传递到子进程, 让pod快速结束
链接：https://juejin.cn/post/7314804357697945637
区块链能为自由职业者带来什么帮助
如何使用检测模型进行唤醒词检测模型的部署
浅谈隔离变压器铁芯的作用功率和性质
联结组变压器的特点
深度解密石墨烯重大突破：“黑科技”石墨烯究竟给我们带来了什么？
[Kubernetes]为什么有时会出现删除POD后要等一段时间才能被删掉
eSATA接口是什么
SEPIC方程和分量额定值
英特尔宣布10nm 芯片将实现全面量产
环网柜的SF6气体的年泄漏率标准问题是什么
测评 快充移动电源哪个好？SuperMini实力领航
Opera将尽快发布补丁修复桌面浏览器漏洞
人工智能正在推动自动驾驶的创新步伐
机智云怎么使用？iot开发平台快速开发硬件产品案例分享
TCO99 |电磁辐射 |6轴色彩控制
IGBT模块单极驱动的特殊注意事项
数字孪生支撑万物互联
助听器的工作原理
Buck变换器和Boost变换器原理分析
Fraunhofer HHI 适用于 TCP/UDP/IP 处理的 10 GigE 网络协议加速器现已针对 Zynq SoC 提供