记一次k8s pod频繁重启的优化之旅

1.背景

最近有运维反馈某个微服务频繁重启，客户映像特别不好，需要我们尽快看一下。

听他说完我立马到监控平台去看这个服务的运行情况，确实重启了很多次。对于技术人员来说，这既是压力也是动力，大多数时候我们都是沉浸在单调的业务开发中，对自我的提升有限，久而久之可能会陷入一种舒适区，遇到这种救火案例一时间会有点无所适从，但是没关系，毕竟…

“我只是收了火，但没有熄炉”，借用电影中的一句话表达一下此时的心情。

2.初看日志

我当即就看这个服务的运行日志，里面有大量的oom异常，如下：

org.springframework.web.util.NestedServletException: Handler dispatch failed;

nested exception ``is java.lang.OutOfMemoryError: GC overhead limit exceeded

整个服务基本可以说处于不可用状态，任何请求过来几乎都会报oom，但是这跟重启有什么关系呢？是谁触发了重启呢？这里我暂时卖个关子，后面进行解答。

3.k8s健康检查介绍

我们的服务部署在k8s中，k8s可以对容器执行定期的诊断，要执行诊断，kubelet 调用由容器实现的 Handler （处理程序）。有三种类型的处理程序：

• ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

• TCPSocketAction：对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。

• HTTPGetAction：对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

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

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

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

• Unknown（未知）：诊断失败，因此不会采取任何行动。

针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：

• livenessProbe：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。

• readinessProbe：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。初始延迟之前的就绪态的状态值默认为 Failure。如果容器不提供就绪态探针，则默认状态为 Success。

• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。如果容器没有提供启动探测，则默认状态为 Success。

看完探针的相关介绍，可以基本回答上面的疑点**“oom和重启有什么关系？”，**是livenessProbe的锅，简单描述一下为什么：

1. 服务启动；

2. k8s通过livenessProbe中配置的健康检查Handler做定期诊断（我们配置的是HttpGetAction）；

3. 由于oom所以HttpGetAction返回的http status code是500，被k8s认定为Failure（失败）-容器未通过诊断；

4. k8s认为pod不健康，决定“杀死”它然后重新启动。

这是服务的Deployment.yml中关于livenessProbe和restartPolicy的配置

livenessProbe:

failureThreshold: 5

httpGet:

path: /health

port: 8080

scheme: HTTP

initialDelaySeconds: 180

periodSeconds: 20

successThreshold: 1

timeoutSeconds: 10