[Kubernetes] 为什么有时会出现删除POD之后,需要等待一段时间才能被删掉

正常情况下,执行kubectl delete pod之后,pod一般会立即被删除。但是偶尔会出现这样一种情况,删除pod之后,pod的状态一直显示为Terminating,需要等待一段时间才会被删除,这是什么原因呢?

复制代码
NAME    READY   STATUS        RESTARTS   AGE
nginx   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官方文档上的说明,这一大段简单概括起来就是如下两步:

  1. kubelet发送kill 1到pod
  2. 经过terminationGracePeriodSeconds(一般为30s)之后,如果pod还没被删掉,则直接发送kill -9 1强制杀掉进程
graph TD A[kubectl delete pod] --> B{send 'kill -1'} --> C[Terminated] B --> |still alive after some time| D[send 'kill -9 1'] D --> C

至于这里为什么会等待30s,原因如下: k8s pod在结束前可能需要执行一些命令,这些命令可以设置在preStop中进行设置,在删除pod的时候,preStop Hook和SIGTERM 信号并行发生,但是Kubernetes 不会等待 preStop Hook 完成,所以这里需要设置一个等待时间让preStop执行完成之后,在删除pod,这个等待时间就是通过terminationGracePeriodSeconds进行设置的.

但是我们的pod里并没有设置preStop,还是等待了30s pod才彻底被删除

所以这里的问题可能是第1步中, kill 1并没有将进程杀掉, 也就是说进程并没有响应SIGTERM信号

为什么会出现这种情况呢, 进入到容器中看下具体的进程:

bash 复制代码
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 08:58 ?        00:00:00 bash /start.sh
root         7     1 94 08:58 ?        00:00:13 python3 /server.py

可以看到有两个进程, 其中1为主进程, 7为1的子进程, start.sh内容如下:

bash 复制代码
#!/usr/bin/env bash
python3 /server.py

通过执行shell脚本拉起真正的业务进程, 而且以阻塞方式运行, 删除pod时, 发送的SIGTERM信号不会有任何响应, 因为传递不到子进程7, 无法结束子进程, 进而导致pod无法结束.

这里可能会有这样的疑问, 为什么不直接启动业务进程呢? 这是因为有些场景下, 在启动业务进程之前, 需要进行一些初始化操作, 又不想或者不能通过init-container来完成, 只能通过启动脚本去做, 启动脚本初始化结束之后, 再将业务进程拉起.

如何避免这类问题

  1. 尽量直接启动业务进程, 不要依赖进程拉起业务进程, 初始化操作尽量通过init-container来完成
  2. 在启动脚本里捕获SIGTERM, 并将其传递到子进程
shell 复制代码
#!/usr/bin/env bash

exit_func() {
    pkill python3
    exit
}

trap 'exit_func' SIGTERM

python3 /server.py &

while true
do
    sleep 1
done

如上所示, 将start.sh调整一下, 这样就能将SIGTERM传递到子进程, 让pod快速结束

相关推荐
阿狸远翔1 天前
Protobuf 和 protoc-gen-go 详解
开发语言·后端·golang
间彧1 天前
Vert.x与Spring框架:开发效率与团队学习成本深度对比
后端
间彧1 天前
Vert.x与传统Spring框架在性能、并发处理方面有哪些差异
后端
间彧1 天前
Vert.x框架详解与项目实战:构建高性能异步应用
后端
间彧1 天前
Spring Boot 与 Disruptor 高性能并发实战
后端
想用offer打牌1 天前
如何开启第一次开源贡献之路?
java·后端·面试·开源·github
间彧1 天前
在实际项目中,如何根据具体业务场景选择合适的并发容器?
后端
码界奇点1 天前
基于Spring Boot的内容管理系统框架设计与实现
java·spring boot·后端·车载系统·毕业设计·源代码管理
a努力。1 天前
字节Java面试被问:系统限流的实现方式
java·开发语言·后端·面试·职场和发展·golang
小高Baby@1 天前
使用Go语言中的Channel实现并发编程
开发语言·后端·golang