Kubernetes pod（一些）在运行一天后死亡答案

【问题标题】：Kubernetes pods (some) die after running for a dayKubernetes pod（一些）在运行一天后死亡
【发布时间】：2015-10-11 18:34:28
【问题描述】：

我们正在 AWS 上尝试使用 Kubernetes 版本 1.0.6 进行测试设置。

此设置涉及 Cassandra（2 个节点）、Spark（主节点、2 个工作节点、驱动程序）和 RabbitMQ（1 个节点）的 pod。此设置的一些 pod 会在一天左右后死亡

有没有办法从 Kubernetes 获取关于他们如何/为什么死亡的日志？

当您尝试手动重新启动已死亡的 pod 时，您会看到一些 pod 状态为“类别/spark-worker 已准备好，容器正在创建”，并且 pod 启动永远不会完成。

场景中的唯一选项是“kube-down.sh”，然后是 kube-up.sh，然后从头开始完成整个设置。

【问题讨论】：

您是直接运行 Pod 还是在复制控制器下运行？您是否为 pod 指定资源限制？查看运行 pod 的节点上的 /var/log/kubelet.log，看看它是否有任何有趣的内容。
死掉的都是直接运行的，因为它们是1个实例类型（如master，driver），不能在replication controller下运行。上述所有 8-pod 都在“3 台机器，每台 2 核”kubernetes 集群上以 CPU="100cpu" (0.10%) 运行
在 1 天后死亡的豆荚总是相同的吗？您是否查看了 kubelet 日志文件以了解它们失败的原因？
今天又死了一些，这次有些相同，有些不同。我没有看到 /var/log/kublet.log。我正在运行 Kubernetes 1.0.6，日志文件有不同的位置吗？
我还注意到这些 pod 位于运行 influxdb 的机器上（该进程的 CPU 使用率很高）。之前有 5 个 Pod，现在只有 2 个带有复制控制器的新 Pod 回来了（fluentd-elasticsearch、spark-worker-controller）其他 3 个 Pod - influxdb 和 2 个直接运行的 didi not

【解决方案1】：

kubectl describe ${POD_NAME} 或 kubectl logs ${POD_NAME} ${CONTAINER_NAME} 应该为您提供更多调试信息。

编辑：

在 cmets 中讨论后，我认为您的节点的问题是节点无响应超过 5 分钟（可能是由于 influxdb 的内存使用率高）。节点控制器然后认为节点未准备好并驱逐节点上的所有 pod。请注意，由复制控制器管理的 Pod 将被重新创建（使用不同的名称），但手动创建的 Pod 不会被重新创建。

如果您怀疑 influxdb 内存使用是根本原因，您可以尝试不运行此 pod 以查看问题是否自行解决。或者，您可以将influxdb container 的内存限制更改为更小的值。

编辑2：

找出节点发生了什么的一些提示：

检查/var/log/kubelet.log。这是最简单的方法。
kubectl describe nodes 或 kubectl get events | grep <node_name>（适用于旧版本的 kubernetes）

此命令将为您提供与节点状态相关的事件。但是，事件每两小时刷新一次，因此您需要在节点遇到问题后的时间窗口内运行此命令。

【讨论】：

在 pod 死机时尝试了这些命令。它以“错误：未找到 pod“spark-driver””的形式返回，就好像该 pod 从未存在过一样。不确定master上是否有任何内部日志
即使pod死掉了，只要没有被删除，你应该可以通过kubectl访问pod。您能否发布您运行的完整命令及其输出？
我运行了以下命令但没有结果： (1) ./cluster/kubectl.sh get ev ------- 产生 [ FIRSTSEEN LASTSEEN COUNT NAME KIND SUBOBJECT REASON SOURCE MESSAGE] (2 ) ./cluster/kubectl.sh 描述 pods spark-driver --- 产生 [error: pods "spark-driver" not found]
您是否能够通过kubectl get pods < pod_name> 或kubectl describe <pod_name>在 pod 运行时获取 pod？您使用什么云提供商+操作系统发行版？
我在 AWS 提供商上使用“debian:wheezy”docker 容器。在这个特定的一个仆从上杀死的所有 docker 容器；所有带有“Exited(0)”的 kubernetes “google_containers/pause”和带有“Exited(137)”的其他应用程序容器。这个错误代码似乎意味着 - 容器停止了 SIGKILL (137 = 128 + 9 - kill signal)。 如何找到他们被杀的原因？ sudo docker inspect 47b671fe593b 给出 - "State": { "Error": "", "ExitCode": 137, "OOMKilled" ：假，}

【解决方案2】：

由于an issue in Kubernetes，您的节点可能已用完磁盘空间。

最近发布的Kubernetes v1.0.7 提供了间接修复。

AWS：为 aufs 创建一个存储池，而不是两个 #13803 (justinsb)

但正如上述问题中所述，这方面仍有一些工作要做。

【讨论】：