K8S容器应用优雅关闭-修复5003 Error

• 1、遇到的问题
• 2、问题排查
• 3. 根因分析
  • 3.1、SHELL 模式和 CMD 模式带来的差异
  • 3.2、直接启动应用和通过脚本启动区别
• 4、总结

K8S容器应用优雅关闭-修复5003 Error

“运维就要无所不能，无所不会”

大家好，我是Stanley「史丹利」，今天聊技术：容器优雅关闭方案 。

1、遇到的问题

公司某服务接入效能平台后，发布过程中，页面偶尔会出现5003报错，开始以为是Nacos没有及时的将服务反注册，即POD在已经正常关闭的情况下，注册中心依然有POD信息，请求依然到已经关闭的POD中导致

5003报错

5003-error-2

2、问题排查

2.1 首先找开发同学，协助排查了反注册逻辑及相关日志，没有发现什么异常

2.2 后来偶然发现POD中的主进程PID不为1，而PID为1的进程为shell进程，这会导致容器关闭时业务进程无法接受k8s发送的SIGTERM信号，只能在等待15秒后被强行杀死

process-shell

2.3 修改了程序启动参数，通过EXEC启动模式，使应用主进程PID为1

process-exec

2.4 重新发布验证，5003报错问题修复

3. 根因分析

3.1、SHELL 模式和 CMD 模式带来的差异

通常Dockerfile中CMD和ENTRYPOINT来启动应用，启动应用有两种模式，shell 模式和 exec 模式，对应的使用 shell 模式，PID 为 1 的进程为 shell，使用 exec 模式 PID 为 1 的进程为业务本身。

SHELL模式

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM ubuntu
WORKDIR /root/
COPY --from=builder /go/app .
CMD ./app

这种方式构建的镜像应用启动后PID为1的进程是shell进程

EXEC模式

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM ubuntu
WORKDIR /root/
COPY --from=builder /go/app .
CMD ["./app"]

这种方式构建的镜像应用启动后PID为1的进程是应用进程

3.2、直接启动应用和通过脚本启动区别

在实际生产环境中，因为应用启动命令后会接很多启动参数，所以通常我们会使用一个启动脚本来启动应用，方便我们启动应用。对应的在容器内 PID 为 1 的进程为 shell 进程但 shell 程序不转发 signals，也不响应退出信号。所以在容器应用中如果应用容器中启动 shell，占据了 pid=1 的位置，那么就无法接收 k8s 发送的 SIGTERM 信号，只能等超时后被强行杀死了。启动脚本 start.sh

start.sh

$ cat > start.sh<< EOF
#!/bin/sh
sh -c /root/app
EOF

Dockerfile

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM alpine
WORKDIR /root/
COPY --from=builder /go/app .
ADD start.sh /root/
CMD ["/bin/sh","/root/start.sh"]

3.2.1 解决方案

方案一：通过 k8s 的 prestop 参数调用容器内进程关闭脚本，实现优雅关闭。

在前面脚本启动的dockerfile 基础上，定义一个优雅关闭的脚本，通过k8s-prestop 在关闭 POD 前调用优雅关闭脚本，实现 pod 优雅关闭。

stop.sh

#!/bin/sh
ps -ef|grep app|grep -v grep|awk '{print $1}'|xargs kill -15

通过 yaml 部署到 k8s 中

stop.sh

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-prestop
  labels:
    app: prestop
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prestop
  template:
    metadata:
      labels:
        app: prestop
    spec:
      containers:
      - name: prestop
        image: xx/app:v1.0-prestop
        lifecycle:
          preStop:
            exec:
              command:
              - sh
              - /root/stop.sh

方案二：shell 脚本修改为 exec 执行

修改start.sh脚本

stop.sh

#!/bin/sh
exec ./app

shell 中添加一个 exec 即可让应用进程替代当前 shell 进程,可将 SIGTERM 信号传递到业务层，让业务实现优雅关闭。

方案三：通过第三方 init 进程传递 SIGTERM 到进程中。

使用 dump-init 或 tini 做为容器的主进程，在收到退出信号的时候，会将退出信号转发给进程组所有进程。主要适用应用本身无关闭信号处理的场景。docker –init 本身也是集成的 tini。

stop.sh

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM alpine
WORKDIR /root/
COPY --from=builder /go/app .
ADD start.sh tini /root/
RUN chmoad a+x start.sh && apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["/root/tini", "--", /root/start.sh"]

4、总结

1、对于容器化应用启动命令建议使用 EXEC 模式。

2、对于应用本身代码层面已经实现了优雅关闭的业务，但有 shell 启动脚本，容器化后部署到 k8s 上建议使方案一和方案二。

3、对于应用本身代码层面没有实现优雅关闭的业务，建议使用方案三。