如何确定部署在 Kubernetes 上的 Spring Boot 应用程序中出现 CrashLoopBackOff 错误的原因答案

【问题标题】：How to determine the reason of a CrashLoopBackOff error in a Spring Boot application deployed on Kubernetes如何确定部署在 Kubernetes 上的 Spring Boot 应用程序中出现 CrashLoopBackOff 错误的原因
【发布时间】：2018-01-19 16:31:54
【问题描述】：

我有一个 Spring Boot 应用程序，部署在 Kubernetes 的 docker 容器上。该应用程序在一段时间（数小时）内运行良好，但在某个时刻它开始疯狂地重新启动并显示 CrashLoopBackOff 错误状态。

这是我从死豆荚得到的信息：

Port:       8080/TCP
State:      Waiting
  Reason:       CrashLoopBackOff
Last State:     Terminated
  Reason:       Error
  Exit Code:    137
  Started:      Fri, 11 Aug 2017 10:15:03 +0200
  Finished:     Fri, 11 Aug 2017 10:16:22 +0200
Ready:      False
Restart Count:  7
...
    Volume Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-bhk8f (ro)
    Environment Variables:
      JAVA_OPTS:        -Xms512m -Xmx1792m
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
...
QoS Class:  BestEffort
Tolerations:    <none>
No events.

有什么方法可以获取有关崩溃原因的更详细信息？

137 错误代码是内存不足错误吗？我一直将 Java 进程的内存从 -Xmx768m 增加到 1792m，但错误不断出现。 会不会是别的？

一个奇怪的事实：我需要找出应用程序为什么运行良好，几个小时后 pod 被杀死，然后每次重启仅在执行几秒钟后就被杀死。

【问题讨论】：

所以在您的节点上执行docker ps -a 以查看退出的容器并查看日志中的内容。此外，仅在容器内提供内存限制也无济于事，您还需要将其应用于容器。还要检查是否存在磁盘空间问题。我们有一个类似的问题，tomcat 会进行核心转储，并且转储很大，导致 10GB 容器内部没有空间
没有遥测几乎是不可能的。可能是泄漏，你会被 OOMed，谁知道 :) 你用什么来监控系统和你的容器？
要明确一点：是的，代码 137 来自 Docker 引擎，指示 OOM kill，但我们需要一个根本原因，对吧？
@TarunLalwani 我会在 kubernetes 节点中尝试docker ps -a。我不明白这个：Also Just giving memory limit inside container wont help, you would need to also apply that to the container。我们的 dockerfile 运行 java 进程设置 -Xms 和 -Xmx 限制，我认为这适用于 cointainer。如果没有，我该怎么办？
@MichaelHausenblas 我们正在使用 Prometheus + Grafana 进行监控，可以看到每个 pod 的内存演变。正如你所说，它可能是任何东西，那么如何确定根本原因？

标签： docker spring-boot kubernetes

【解决方案1】：

kubectl logs podName containerName 将为您提供容器日志，该日志应为您提供有关错误原因的更多信息。

【讨论】：

kubectl logs 显示应用程序日志，一切似乎都正常。有没有办法获取有关崩溃容器的更具体信息？
我不这么认为。除了使用其他潜在指标。日志中是否提供了退出代码？退出代码是什么（进程终止时）？