分析POD Exit Code 137,无法优雅下线

分析POD Exit Code 137,无法优雅下线

Deng YongJie's blog 1,983 2023-01-14

分析POD Exit Code 137,容器被强制kill掉原因

pod的生命周期:

https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/

常见的容器退出状态码解释

Exit Code 0
退出代码0表示特定容器没有附加前台进程
该退出代码是所有其他后续退出代码的例外
这不一定意味着发生了不好的事情。如果开发人员想要在容器完成其工作后自动停止其容器,则使用此退出代码。比如:kubernetes job 在执行完任务后正常退出码为 0

Exit Code 1
程序错误,或者Dockerfile中引用不存在的文件,如 entrypoint中引用了错误的包
程序错误可以很简单,例如 “除以0”,也可以很复杂,比如空引用或者其他程序 crash

Exit Code 137
表明容器收到了 SIGKILL 信号,进程被杀掉,对应kill -9
引发SIGKILL的是docker kill。这可以由用户或由docker守护程序来发起,手动执行:docker kill

137 比较常见,如果 pod 中的limit 资源设置较小,会运行内存不足导致 OOMKilled,此时state 中的 ”OOMKilled” 值为true,你可以在系统的 dmesg -T 中看到 oom 日志

Exit Code 139
表明容器收到了 SIGSEGV 信号,无效的内存引用,对应kill -11
一般是代码有问题,或者 docker 的基础镜像有问题

Exit Code 143
表明容器收到了 SIGTERM 信号,终端关闭,对应kill -15
一般对应 docker stop 命令
有时docker stop也会导致Exit Code 137。发生在与代码无法处理 SIGTERM 的情况下,docker进程等待十秒钟然后发出 SIGKILL 强制退出。

不常用的一些 Exit Code
Exit Code 126: 权限问题或命令不可执行
Exit Code 127: Shell脚本中可能出现错字且字符无法识别的情况
Exit Code 1 或 255:因为很多程序员写异常退出时习惯用 exit(1) 或 exit(-1),-1 会根据转换规则转成 255。这个一般是自定义 code,要看具体逻辑。


常见退出状态码

退出代码 0:一般为容器正常退出
退出代码 1:由于容器中 pid 为 1 的进程错误而失败
退出代码 137:由于容器收到 SIGKILL 信号而失败(手动执行或“oom-killer” [OUT-OF-MEMORY])
退出代码 139:由于容器收到 SIGSEGV 信号而失败
退出代码 143:由于容器收到 SIGTERM 信号而失败

查看异常 pod 的状态,注意需要在减少pod或删除pod,超过宽限期的一瞬间才会出现:

kubectl get -n crm-app-api-java pod crm-app-fund-5ffcd4c8b9-b5mts -o yaml|egrep 'exitCode|reason'

           f:reason: {}
            f:reason: {}
    reason: ContainersNotReady
    reason: ContainersNotReady
        exitCode: 137
        reason: Error

其中 ExitCode 即程序上次退出时的状态码,如果不为 0,表示异常退出,我们可以分析下原因。

复现过程:

运行一个nginx,然后把副本数降为0,查看yaml关键字段复现问题。发现是正常的

image-1680141147740

再次测试无法优雅下线的java服务,发现还是出现137 code

image-1680141240493
image-1680141294189

因为pod的字段reason出现的是error,并非oomkill。更进一步确认是否oom问题,查看宿主机内核日志

dmesg |grep oom
journalctl -k | grep -i -e memory -e oom

#并没有发现该容器的omm信息,彻底排除掉oomkill

通过上面的排查,初步判断是否发送了Kill信号,超过宽限期还没正常退出,然后kill -9停止了。尝试调大宽限期的范围,宽限期默认是30s,改成60s

spec:
  terminationGracePeriodSeconds: 60

调大宽限期之后,把副本数增加为1,随后减至0,结果还是出现exitcode 137

image-1680141381547

然后进入容器内部查看进程,发现1号进程运行的是脚本。通过排查和沟通,得知是测试同事使用入口shell命令运行pinpoint-agent脚本,占用了PID为1的进程,导致无法获取进程信号,所以容器超过宽限期而被强制kill掉,无法优雅下线!

image-1680142720902

常见问题:

  1. 在大多数情况下,信号处理不当。Linux内核对以PID 1运行的进程应用特殊的信号处理。当进程在普通Linux系统上被发送一个信号时,内核将首先检查进程是否注册了该信号的任何自定义处理程序,否则将返回到默认行为(例如,在SIGTERM上终止进程)。但是,如果接收到信号的进程是PID 1,它将得到内核的特殊处理;如果它没有为该信号注册处理程序,内核将不会返回到默认行为,并且不会发生任何事情。换句话说,如果您的进程没有显式地处理这些信号,那么发送SIGTERM将没有任何效果。一个常见的例子是执行docker run my-container script的CI作业:将SIGTERM发送到docker run进程通常会终止docker run命令,但让容器在后台运行。
  2. 孤立的僵尸进程没有得到正确的收获。进程在退出时变成僵尸,在其父进程调用wait()系统调用的某个变体之前,它仍然是僵尸。它作为“失效”进程保留在进程表中。通常,父进程将立即调用wait(),并避免long-living僵尸。如果父级在其子级之前退出,则子级是“孤立的”,并且在PID 1下是re-parented。因此,init系统负责孤立僵尸进程上的wait()-ing。当然,大多数进程在随机进程上不会wait(),而这些随机进程恰好与它们相连,因此容器通常以许多根于PID 1的僵尸结束。

总结:

  1. 通常1个pod只运行1个容器1个进程。 容器运行多个进程的情况,容器运行时会发送一个 TERM 信号到每个容器中的主进程,主进程要为子进程传递信号实现优雅退出,否则主进程先退出,而子进程还保留在进程表,就成了僵尸进程,超过pod的终止宽限期而触发kill -9

为什么我的容器收不到 SIGTERM 信号 ?

背景

我们的业务代码通常会捕捉 SIGTERM 信号,然后执行停止逻辑以实现优雅终止。在 Kubernetes 环境中,业务发版时经常会对 workload 进行滚动更新,当旧版本 Pod 被删除时,K8S 会对 Pod 中各个容器中的主进程发送 SIGTERM 信号,当达到超时时间进程还未完全停止的话,K8S 就会发送 SIGKILL 信号将其强制杀死。

业务在 Kubernetes 环境中实际运行时,有时候可能会发现在滚动更新时,我们业务的优雅终止逻辑并没有被执行,现象是在等了较长时间后,业务进程直接被 SIGKILL 强制杀死了。

什么原因 ?

通常都是因为容器启动入口使用了 shell,比如使用了类似 /bin/sh -c my-app 或 /docker-entrypoint.sh 这样的 ENTRYPOINT 或 CMD,这就可能就会导致容器内的业务进程收不到 SIGTERM 信号,原因是:

  1. 容器主进程是 shell,业务进程是在 shell 中启动的,成为了 shell 进程的子进程。
  2. shell 进程默认不会处理 SIGTERM 信号,自己不会退出,也不会将信号传递给子进程,导致业务进程不会触发停止逻辑。
  3. 当等到 K8S 优雅停止超时时间 (terminationGracePeriodSeconds,默认 30s),发送 SIGKILL 强制杀死 shell 及其子进程。

如何解决 ?

  1. 如果可以的话,尽量不使用 shell 启动业务进程。
  2. 如果一定要通过 shell 启动,比如在启动前需要用 shell 进程一些判断和处理,或者需要启动多个进程,那么就需要在 shell 中传递下 SIGTERM 信号了,解决方案请参考 Kubernetes 实用技巧: 在 SHELL 中传递信号

在 SHELL 中如何传递信号?

背景

在 Kubernetes 中,Pod 停止时 kubelet 会先给容器中的主进程发 SIGTERM 信号来通知进程进行 shutdown 以实现优雅停止,如果超时进程还未完全停止则会使用 SIGKILL 来强行终止。

但有时我们会遇到一种情况: 业务逻辑处理了 SIGTERM 信号,但 Pod 停止时好像没收到信号导致优雅停止逻辑不生效。

通常是因为我们的业务进程是在脚本中启动的,容器的启动入口使用了脚本,所以容器中的主进程并不是我们所希望的业务进程而是 shell 进程,导致业务进程收不到 SIGTERM 信号,下面将介绍几种解决方案。

使用 exec 启动

在 shell 中启动二进制的命令前加一个 exec 即可让该二进制启动的进程代替当前 shell 进程,即让新启动的进程成为主进程:

#! /bin/bash
...

exec /bin/yourapp # 脚本中执行二进制

然后业务进程就可以正常接收所有信号了,实现优雅退出也不在话下。

多进程场景: 使用 trap 传递信号

通常我们一个容器只会有一个进程,也是 Kubernetes 的推荐做法。但有些时候我们不得不启动多个进程,比如从传统部署迁移到 Kubernetes 的过渡期间,使用了富容器,即单个容器中需要启动多个业务进程,这时也只能通过 shell 启动,但无法使用上面的 exec 方式来传递信号,因为 exec 只能让一个进程替代当前 shell 成为主进程。

这个时候我们可以在 shell 中使用 trap 来捕获信号,当收到信号后触发回调函数来将信号通过 kill 传递给业务进程,脚本示例:

#! /bin/bash

/bin/app1 & pid1="$!" # 启动第一个业务进程并记录 pid
echo "app1 started with pid $pid1"

/bin/app2 & pid2="$!" # 启动第二个业务进程并记录 pid
echo "app2 started with pid $pid2"

handle_sigterm() {
  echo "[INFO] Received SIGTERM"
  kill -SIGTERM $pid1 $pid2 # 传递 SIGTERM 给业务进程
  wait $pid1 $pid2 # 等待所有业务进程完全终止
}
trap handle_sigterm SIGTERM # 捕获 SIGTERM 信号并回调 handle_sigterm 函数

wait # 等待回调执行完,主进程再退出

完美方案: 使用 init 系统

前面一种方案实际是用脚本实现了一个极简的 init 系统 (或 supervisor) 来管理所有子进程,只不过它的逻辑很简陋,仅仅简单的透传指定信号给子进程,其实社区有更完善的方案,dumb-inittini 都可以作为 init 进程,作为主进程 (PID 1) 在容器中启动,然后它再运行 shell 来执行我们指定的脚本 (shell 作为子进程),shell 中启动的业务进程也成为它的子进程,当它收到信号时会将其传递给所有的子进程,从而也能完美解决 SHELL 无法传递信号问题,并且还有回收僵尸进程的能力。

特性描述

进程信号传递

站在容器的角度,由其运行的第一个程序的PID为1,这个进程肩负着重要的使命:传递信号让子进程退出和等待子进程退出。对于第一点,如果pid为1的进程,无法向其子进程传递信号,可能导致容器发送SIGTERM信号之后,父进程等待子进程退出。此时,如果父进程不能将信号传递到子进程,则整个容器就将无法正常退出,除非向父进程发送SIGKILL信号,使其强行退出,这就会导致一些退出前的操作无法正常执行,例如关闭数据库连接、关闭输入输出流等。

僵尸进程处理 上边提到:PID为1的进程的一个重要使命是等待子进程退出,如果一个进程中A运行了一个子进程B,而这个子进程B又创建了一个子进程C,若子进程B非正常退出(通过SIGKILL信号,并不会传递SIGKILL信号给进程C),那么子进程C就会由进程A接管,一般情况下,我们在进程A中并不会处理对进程C的托管操作(进程A不会传递SIGTERM和SIGKILL信号给进程C),结果就导致了进程B结束了,倒是并没有回收其子进程C,子进程C就变成了僵尸进程。

进程信号模拟 父进程非正常退出(收到SIGKILL信号),若使用了Supervisor类工具,可以将SIGKILL信号传递给子进程,若子进程中想收到SIGTERM信号,就可以通过dumb-init来模拟。

容器里面安装Dumb-init

deb安装

RUN wget https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64.deb
RUN dpkg -i dumb-init_*.deb

二进制安装

RUN wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64
RUN chmod +x /usr/local/bin/dumb-init

PyPI安装

pip install dumb-init

这里以 dumb-init 为entrypoint固定使用dumb-init为容器运行的第一个进程,start.sh作为其子进程,它充当PID 1,并立即将命令作为子进程生成,在接收到信号时正确地处理和转发,下面是 Dockerfile 示例:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y dumb-init
ADD start.sh /
ADD app1 /bin/app1
ADD app2 /bin/app2
ENTRYPOINT ["dumb-init", "--"]
CMD ["/start.sh"]

这是以 tini 为例制作镜像的 Dockerfile 示例:

FROM ubuntu:22.04
ENV TINI_VERSION v0.19.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /tini /entrypoint.sh
ENTRYPOINT ["/tini", "--"]
CMD [ "/start.sh" ]

start.sh 脚本示例:

#! /bin/bash
/bin/app1 &
/bin/app2 &
wait

业务代码处理 SIGTERM 信号

要实现优雅终止,首先业务代码得支持下优雅终止的逻辑,在业务代码里面处理下 SIGTERM 信号,一般主要逻辑就是"排水",即等待存量的任务或连接完全结束,再退出进程。

本文给出各种语言的代码示例。

shell

#!/bin/sh

## Redirecting Filehanders
ln -sf /proc/$$/fd/1 /log/stdout.log
ln -sf /proc/$$/fd/2 /log/stderr.log

## Pre execution handler
pre_execution_handler() {
  ## Pre Execution
  # TODO: put your pre execution steps here
  : # delete this nop
}

## Post execution handler
post_execution_handler() {
  ## Post Execution
  # TODO: put your post execution steps here
  : # delete this nop
}

## Sigterm Handler
sigterm_handler() { 
  if [ $pid -ne 0 ]; then
    # the above if statement is important because it ensures 
    # that the application has already started. without it you
    # could attempt cleanup steps if the application failed to
    # start, causing errors.
    kill -15 "$pid"
    wait "$pid"
    post_execution_handler
  fi
  exit 143; # 128 + 15 -- SIGTERM
}

## Setup signal trap
# on callback execute the specified handler
trap 'sigterm_handler' SIGTERM

## Initialization
pre_execution_handler

## Start Process
# run process in background and record PID
>/log/stdout.log 2>/log/stderr.log "$@" &
pid="$!"
# Application can log to stdout/stderr, /log/stdout.log or /log/stderr.log

## Wait forever until app dies
wait "$pid"
return_code="$?"

## Cleanup
post_execution_handler
# echo the return code of the application
exit $return_code

Go

package main

import (
    "fmt"
    "os"
    "os/signal"
    "syscall"
)

func main() {

    sigs := make(chan os.Signal, 1)
    done := make(chan bool, 1)
    //registers the channel
    signal.Notify(sigs, syscall.SIGTERM)

    go func() {
        sig := <-sigs
        fmt.Println("Caught SIGTERM, shutting down")
        // Finish any outstanding requests, then...
        done <- true
    }()

    fmt.Println("Starting application")
    // Main logic goes here
    <-done
    fmt.Println("exiting")
}

Python

import signal, time, os

def shutdown(signum, frame):
    print('Caught SIGTERM, shutting down')
    # Finish any outstanding requests, then...
    exit(0)

if __name__ == '__main__':
    # Register handler
    signal.signal(signal.SIGTERM, shutdown)
    # Main logic goes here

NodeJS

process.on('SIGTERM', () => {
  console.log('The service is about to shut down!');
  
  // Finish any outstanding requests, then...
  process.exit(0); 
});

Java

import sun.misc.Signal;
import sun.misc.SignalHandler;
 
public class ExampleSignalHandler {
    public static void main(String... args) throws InterruptedException {
        final long start = System.nanoTime();
        Signal.handle(new Signal("TERM"), new SignalHandler() {
            public void handle(Signal sig) {
                System.out.format("\nProgram execution took %f seconds\n", (System.nanoTime() - start) / 1e9f);
                System.exit(0);
            }
        });
        int counter = 0;
        while(true) {
            System.out.println(counter++);
            Thread.sleep(500);
        }
    }
}