【kubernetes 入门到精通】Kubernetes 的健康监测机制以及常见 ExitCode 问题分析「探索篇」

kubernetes 进行 Killed 我们服务的问题背景

无论是在微服务体系还是云原生体系的开发迭代过程中，通常都会以 Kubernetes 进行容器化部署，但是这也往往带来了很多意外的场景和情况。例如，虽然我们已经将 JVM 堆内存设置为小于 Docker 容器中内存及 K8S 的 Pod 的内存，但是还是会被 K8s 给无情的杀掉（Kill -9 / Kill -15）Killed。当发生了 Killed 的时候，我们该如何分析和判断呢？在此我们介绍一下 K8s 的 Killed 的 Exit Code 编码。

kubernetes 健康检测体系之探针

K8s 中的探针用来对 pod 中容器的状态进行检测，有 3 种探针，存活探针、就绪探针、启动探针。

kubernetes 如何监控和管理我们的 Pod 的运行状态

Kubernetes 中的健康检查主要使用就绪性探针（readinessProbes） 和 存活性探针（livenessProbes） 来实现，service 即为负载均衡，k8s 保证 service 后面的 pod 都可用，是 k8s 中自愈能力的主要手段，主要基于这两种探测机制，可以实现如下需求：

• 异常实例自动剔除，并重启新实例

• 多种类型探针检测，保证异常 pod 不接入流量

• 不停机部署，更安全的滚动升级

存活探针 — livenessProbes

kubelet 使用 存活探针 来确定什么时候要重启容器。 例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况，重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。

就绪探针 — readinessProbes

kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 该指针用来指示容器是否准备好为请求提供服务。如果就绪态探测失败，kubelet 将该 Pod 提供的所有服务的 endpoint 列表中删除该 Pod 的 IP 地址。

与存活探针的区别

当容器未通过检查准备，则不会被终止或重新启动。存活探针通过杀死异常的容器并用新的容器去替代他们的工作，而就绪探针确保只有准备好处理请求的 pod 才能在服务集群中。

启动探针 — startupProbes( 1.17 版本新增）

kubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查， 确保这些存活、就绪探针不会影响应用的启动。

启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉，如：使用了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。

探针的 3 种机制

每种探测机制支持三种健康检查方法，分别是命令行 exec，httpGet 和 tcpSocket，其中 exec 通用性最强，适用与大部分场景，tcpSocket 适用于 TCP 业务，httpGet 适用于 web 业务。

• HTTP GEt：该类型的探针通过容器的 IP 地址、端口号及路径调用 HTTP Get 请求，如果响应的状态码大于等于 200 且小于 400，则认为容器 健康。

• TcpSocket：该类型的探针尝试与容器指定端口建立 TCP 连接，如果端口打开，则诊断被认为是成功的。

• Exec（自定义健康检查）：该类型的探针在容器内执行任意的命令，如果命令退出时返回码为 0，则认为诊断成功。

配置和设定 livenessProbes 探针

通过在 yaml 文件中 pod 的 spec 部分的 containers 里面添加一个字段 livenessProbe 来添加存活指针：

livenessProbe 执行模式执行探针控制(httpGet)

apiVersion: v1kind: Podmetadata:  labels:    test: liveness  name: liveness-httpspec:  containers:  - name: liveness    image: registry.k8s.io/liveness    args:    - /server    livenessProbe:      httpGet:        path: /healthz        port: 8080        httpHeaders:        - name: Custom-Header          value: Awesome      initialDelaySeconds: 3      periodSeconds: 3

Exec 执行模式执行探针控制(exec)

apiVersion: v1kind: Podmetadata:  labels:    test: liveness  name: liveness-execspec:  containers:  - name: liveness    image: registry.k8s.io/busybox    args:    - /bin/sh    - -c    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600    livenessProbe:      exec:        command:        - cat        - /tmp/healthy      initialDelaySeconds: 5      periodSeconds: 5

livenessProbe 执行模式执行探针控制(tcpSocket)

apiVersion: v1kind: Podmetadata:  name: goproxy  labels:    app: goproxyspec:  containers:  - name: goproxy    image: registry.k8s.io/goproxy:0.1    ports:    - containerPort: 8080    readinessProbe:      tcpSocket:        port: 8080      initialDelaySeconds: 5      periodSeconds: 10    livenessProbe:      tcpSocket:        port: 8080      initialDelaySeconds: 15      periodSeconds: 20

每次探测都将获得以下三种结果之一：

• Success（成功）：表示容器通过了诊断。

• Failure（失败）：表示容器未通过诊断。

• Unknown（未知）：表示没有正常进行且诊断失败，因此不会采取任何行动。

容器退出状态码的区间

Exit Codes 的取值范围必须在 0-255 之间。可以参考：https://tldp.org/LDP/abs/html/exitcodes.html，如下图所示。

• 0：表示正常退出

• 1-128：一般程序自身原因导致的异常退出状态区间在 1-128 (这只是一般约定，程序如果一定要用 129-255 的状态码也是可以的)

• 129-255：外界中断将程序退出的时候状态码区间在 129-255，(操作系统给程序发送中断信号，比如 kill -9 是 SIGKILL)

查看 Pod 退出状态码

$ kubectl describe pods ${pod-name}

如下图所示：

Exit Code 0

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

Exit Code 1

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

Exit Code 139

Exit Code 139: Indicates failure as container received SIGSEGV

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

Exit Code 143

Exit Code 143: Indicates failure as container received SIGTERM

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

Exit Code 137

Exit Code 137: Indicates failure as container received SIGKILL

表明容器收到了 SIGKILL 信号，进程被杀掉，对应 kill -9，引发 SIGKILL 的是 docker kill。这可以由用户或由 docker 守护程序来发起，手动执行：docker kill(Manual intervention or ‘oom-killer’ [OUT-OF-MEMORY]) 被手动干预杀死进程，或者违反系统限制被杀

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

内存溢出问题

此状态码一般是因为 pod 中容器内存达到了它的资源限制(resources.limits)，一般是内存溢出(OOM)，CPU 达到限制只需要不分时间片给程序就可以。因为限制资源是通过 linux 的 cgroup 实现的，所以 cgroup 会将此容器强制杀掉，类似于 kill -9，此时在 describe pod 中可以看到 Reason 是 OOMKilled

还可能是宿主机本身资源不够用了(OOM)，内核会选取一些进程杀掉来释放内存，不管是 cgroup 限制杀掉进程还是因为节点机器本身资源不够导致进程死掉，都可以从系统日志中找到记录:

ubuntu 的系统日志在 /var/log/syslog，centos 的系统日志在 /var/log/messages，都可以用 journalctl -k 来查看系统日志。