StatefulSet重新制造豆荚，为什么？

Question

我有我的部署，我已经定义了postgres statefulSet，但是我没有PVC，所以如果pod死了-所有的数据都消失了。如果我要列出所有的吊舱，我看到以下图片：

pod1 - Running - 10 min
pod2 - Running - 10 min
postgresPod - Running - 10 min

一段时间后，我再次列出豆荚，如下所示：

pod1 - Running - 10 min
pod2 - Running - 10 min
postgresPod - Running - 5 min

您可以看到postgresPod运行了5分钟。我“描述”了状态，并在下面看到：

Type     Reason               Age                From                    Message
  ----     ------               ----               ----                    -------
  Normal   SuccessfulCreate     5m **(x2 over 10m)**  statefulset-controller  create Pod postgresPod in StatefulSet x-postgres successful
  Warning  RecreatingFailedPod  5m                statefulset-controller  StatefulSet xx/x-postgres is recreating failed Pod postgresPod
  Normal   SuccessfulDelete     5m                statefulset-controller  **delete Pod postgresPod** in StatefulSet x-postgres successful

所以我的问题是我怎么知道为什么 statefulSet会重新创建豆荚呢？还有其他的日志吗？它可能与机器的资源有某种关系，或者是在另一个节点上创建的，在这个特定时刻拥有更多的资源？

有什么想法吗？

Answer 1

你应该研究两件事：

1. 调试Pods

使用以下命令检查吊舱的当前状态和最近发生的事件： kubectl describe pods ${POD_NAME}看舱内容器的状态。他们都跑了吗？最近有重新开始吗？ 根据荚的状态继续调试。

特别是仔细看看为什么Pod坠毁了。

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

1. 调试StatefulSets。

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

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

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

如果有帮助的话请告诉我。

Answer 2

我想出的另一个巧妙的小窍门是，当豆荚停止伐木时，立即使用describe

kubectl logs -f mypod && kubectl describe pod mypod

当结束符失败并停止日志记录时，kubectl logs -f mypod将终止，然后shell将立即执行kubectl describe pod mypod，(希望如此)允许您在重新创建失败的pod之前捕获它的状态。

在我的例子中它显示了

    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137

与蒂莫西的话一致

Answer 3

kubectl log -p postgresPod -- -p将为您提供前面的日志(如果是简单的重新启动)。

这里有一大堆“了解你的环境的其他部分”。你知道你的集群有多少个节点(我们说的是一个还是两个，或者是10到100或更多)。您知道它们是专用实例还是使用spot实例的云提供商(如AWS )。

看看kubectl get nodes，它会告诉您节点的年龄。

你的吊舱上有要求和限制吗？做一个kubectl describe ${POD_NAME}。在请求、限制等中，您将看到荚在哪个节点上。描述节点，它将有CPU和内存的细节。你的吊舱能住在里面吗。您的应用程序是否配置为在这些限制内生存？如果您没有设置限制，那么您的吊舱就可以很容易地消耗那么多资源，以至于内核oom杀手终止了您的吊舱。如果你有荚限制，但你的应用程序配置错误，那么K8s可能会杀死你的应用程序，因为它违反了限制。

如果您可以访问节点，那么查看一下dmesg，看看OOM-Killer是否已经终止了您的任何一个豆荚。如果你没有权限，找个人看看日志。当您描述节点时，请查找带有0限制的豆荚，因为这是无限的，而且它们可能行为不当，导致应用程序被杀死，因为在无限制的应用程序不可用的情况下，向系统请求更多的资源是不吉利的。