您应该研究两件事：

1. Debug Pods

使用来检查窗格的当前状态和最近的事件 以下命令：

kubectl describe pods ${POD_NAME}查看容器的状态 在豆荚里他们都在跑步吗？最近有重启吗？

根据Pod的状态继续调试。

特别要仔细研究why the Pod crashed。

更多信息可以在我提供的链接中找到。

1. 调试StatefulSet。

StatefulSets提供了一种调试机制，以使用注释暂停Pods上的所有控制器操作。在任何StatefulSet Pod上将pod.alpha.kubernetes.io/initialized注释设置为“ false”将暂停StatefulSet的所有操作。暂停时，StatefulSet将不执行任何缩放操作。设置调试挂钩后，您可以在StatefulSet容器的容器内执行命令，而不会受到扩展操作的干扰。您可以通过执行以下操作将注释设置为“ false”：

kubectl annotate pods <pod-name> pod.alpha.kubernetes.io/initialized="false" --overwrite

当注释设置为“ false”时，StatefulSet将不会响应其Pod变得不健康或不可用。在注释被删除或在每个StatefulSet Pod上设置为“ true”之前，它不会创建替换Pod。

请让我知道是否有帮助。

我想出的另一个小技巧是在 pod 停止记录后立即describe 使用

kubectl logs -f mypod && kubectl describe pod mypod

当 pod 失败并停止记录时，kubectl logs -f mypod 将终止，然后 shell 将立即执行 kubectl describe pod mypod，（希望如此）让您在重新创建失败的 pod 之前捕获它的状态。

就我而言，它正在显示

    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137

与蒂莫西所说的一致

kubectl log -p postgresPod -p将为您提供以前的日志（如果是简单的重启）。

这里有很多“了解环境的其余部分”。您知道组成集群的节点有多少（我们是在谈论1或2，还是在谈论10的100或更多）。您是否知道它们是专用实例还是使用现货实例的AWS等云提供商？

看看kubectl get nodes，它将为您提供节点的年龄。

您对广告连播设置了要求和限制吗？做一个kubectl describe ${POD_NAME}。在请求，限制等中，您将看到Pod位于哪个节点上。描述将具有CPU和内存详细信息的节点。您的吊舱可以住在其中吗？您的应用程序是否配置为在这些限制之内？如果没有设置限制，那么您的Pod可能会轻易消耗大量资源，以致内核oom Killer终止了您的Pod。如果您确实有广告连播限制，但您的应用配置错误，那么K8s可能会杀死您的应用，因为它违反了限制

如果您有权访问该节点，请查看dmesg以查看OOM-Killer是否终止了您的任何吊舱。如果您没有访问权限，请找人来看看日志。当您描述节点时，请寻找具有0个限制的Pod，因为它们是无限的，并且可能行为不当并导致您的应用被终止，因为当应用不可用时，它不够幸运，无法从系统请求更多资源由于无限的应用程序。