6

我有我的部署，在那里我定义了 postgres statefulSet，但是我没有 PVC，所以如果 pod 死了 - 所有数据都消失了。如果我要列出所有豆荚，我会看到下图：

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

一段时间后，我再次列出 pod 并查看以下内容：

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？有没有额外的日志？可能它与机器的资源有某种关系，或者 pod 是在另一个节点上创建的，该节点在那个特定时刻拥有更多资源？

有任何想法吗？

4

3 回答 3

4

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

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

与蒂莫西所说的一致

于 2021-01-29T09:40:10.163 回答
3

你应该研究两件事：

  1. 调试 Pod

使用以下命令检查 pod 的当前状态和最近发生的事件：

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

根据 pod 的状态继续调试。

尤其要仔细看看Pod 崩溃的原因。

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

  1. 调试有状态集。

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

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

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

请让我知道这是否有帮助。

于 2020-01-09T10:18:47.333 回答
0

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

这里有一大堆“了解你的环境的其余部分”。你知道你的集群有多少个节点（我们说的是 1 还是 2 或者我们说的是 10 的 100 或更多）。您是否知道它们是专用实例，还是您在使用 Spot 实例的 AWS 等云提供商上。

看看kubectl get nodes它会不会告诉你你的节点的年龄。

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

如果您有权访问该节点dmesg，请查看是否OOM-Killer已终止您的任何 pod。如果您无权访问，请找人查看日志。当您描述节点时，请查找具有0限制的 pod，因为它是无限的，它们可能行为不端并导致您的应用程序被杀死，因为当由于无限的应用程序而无法使用时，它很不幸地从系统请求更多资源。

于 2020-10-21T20:34:51.133 回答