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分钟。我“描述了” statefulset，并在下面看到：

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重新创建吊舱？还有其他日志吗？可能是由于某种原因与机器资源有关，还是在该特定时刻在其他具有更多资源的节点上创建了pod？

有什么想法吗？

Answer 1

您应该研究两件事：

Debug Pods

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

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

根据Pod的状态继续调试。

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

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

调试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。

请让我知道是否有帮助。

Answer 2

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

kubectl logs -f mypod && kubectl describe pod mypod

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

就我而言，它正在显示

    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137

与蒂莫西所说的一致

Answer 3

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，因为它们是无限的，并且可能行为不当并导致您的应用被终止，因为当应用不可用时，它不够幸运，无法从系统请求更多资源由于无限的应用程序。

StatefulSet重新创建pod，为什么？

3 个答案: