Kubernetes pod (Java) 以 137 TERMINATED 重新启动答案

【问题标题】：Kubernetes pod (Java) restarts with 137 TERMINATEDKubernetes pod (Java) 以 137 TERMINATED 重新启动
【发布时间】：2020-08-24 07:53:34
【问题描述】：

我们正在使用 Docker 1.19 和 systemd 在具有 3 个 master 和 3 个 worker 的本地部署上运行 Kubernetes (1.18)。操作系统是 RedHat 7.8。

Container 是一个基于 Java 13 的 Spring Boot 应用程序（使用基础镜像作为 openjdk:13-alpine），以下是内存设置。

吊舱：

内存 - 最小 448M 和最大 2500M
cpu - 最小 0.1

容器：

Xms：256M，Xmx：512M

当流量发送时间较长时，容器突然重启；在 Prometheus 中，我可以看到 Pod 内存低于最大级别（仅 1300MB 左右）。

在 pod 事件中，我可以看到 liveness 和 readiness 探测的警告；并且 pod 会重新启动。

State:          Running
  Started:      Sun, 23 Aug 2020 15:39:13 +0530
Last State:     Terminated
  Reason:       Error
  Exit Code:    137
  Started:      Sun, 23 Aug 2020 15:23:03 +0530
  Finished:     Sun, 23 Aug 2020 15:39:12 +0530
Ready:          True
Restart Count:  14

我可以参考哪些日志来找出触发重启的原因？应用程序日志根本没有帮助；在运行应用程序的最后一个日志之后；我可以看到日志的起始行是下一行。
解决此问题的推荐方法是什么？

谢谢

【问题讨论】：

编辑问题以添加 pod yaml
这是一个舵图，docker镜像是为上面提到的基础的微服务。需要什么具体参数吗？

标签： java kubernetes restart

【解决方案1】：

137 表示 128 + 9（所以它被 kill -9 杀死） https://tldp.org/LDP/abs/html/exitcodes.html

查看 pod 和应用程序日志。

也许容器需要更多资源才能启动？

【讨论】：

是的，并且容器在流量的情况下运行了数小时。但是，这个微服务使用 RestTemplate 连接到另一个微服务，看起来该微服务在填充数据时变得越来越慢。
对我来说，这表明应用程序存在问题，而不是 k8s，但我对您正在运行的应用程序当然知之甚少
我明白你的意思。调查应用程序级别原因的选项有哪些；应用程序日志是无用的，因为它在崩溃和启动之间没有任何内容；我已经查看了 threaddupm 和 memorydump，但看不到问题。从码头工人的角度来看有什么办法吗？