由于对象缓存的传播，作业的 Pod 被杀死答案

【问题标题】：Pods of job get killed because of propagation of object cache由于对象缓存的传播，作业的 Pod 被杀死
【发布时间】：2019-10-11 16:22:16
【问题描述】：

我们正在尝试在 Kubernetes 集群上运行一些分析代码。我们想使用以下 yaml 文件运行 1 个作业的 10 个 pod：

apiVersion: batch/v1
kind: Job
metadata:
 name: job-platooning-s1b
spec:
 parallelism: 10
 template:
   metadata:
     name: job-platooning-s1b
   spec:
     containers:
     - name: platooning-dp-1b
       image: registry.gitlab.com/company_name/repo_name/platooning:latest
       command: ["python3" , "/app/scenario_1b_cluster.py"]
     restartPolicy: 'OnFailure'
     imagePullSecrets:
     - name: regcred-nextsys

我们的 10 个豆荚可以在被杀死之前存活几分钟。我得到的错误是：MountVolume.SetUp failed for volume "default-token-7td4s" : couldn't propagate object cache: timed out waiting for the condition。

我的想法是豆荚消耗了太多的内存。我们尝试通过在 yaml 文件的containers 下添加以下参数来指定内存使用情况：

resources:
    limits:
        memory: "15Gi"
    requests:
        memory: "500Mi"

但这无济于事，因为 pod 仍然被终止。使用 1 个 pod 运行作业很好，因为它不会被杀死。最后，我们希望有一个可扩展的解决方案，可以在一夜之间运行具有多个 pod 的多个场景。

您知道为什么在这种情况下 pod 会被杀死吗？

当 Pod 一个接一个运行时（没有并行性），它们运行正常。当我们尝试同时运行很多它们时，它们会运行一段时间然后被杀死（被驱逐？）有时会产生这个错误：

卷“default-token-7td4s”的 MountVolume.SetUp 失败：无法传播对象缓存：等待条件超时

奇怪的是，我们这个作业使用的秘密不是 default-token-7td4s 而是 regcred-nextsys，如作业 YAML 文件中所示。这是预期的行为吗？如果是这样，为什么它实际上会失败？我怀疑竞争条件，或者只是不同的 pod 试图安装相同的资源，但我不确定这是否有意义。我怀疑的另一个原因是内存问题。

我们将 kubernetes 作为 DigitalOcean 的托管服务运行。

【问题讨论】：

标签： python kubernetes cluster-computing

【解决方案1】：

您使用的是 JOB 类型的 kubernetes 资源，而不是 POD。这些是非常不同的事情。而且您正在运行的作业甚至还没有开始，因为它无法安装默认令牌，这是您应该列为机密的另一个 kubernetes 资源。

最有可能的是，当您创建作业时，它会永远处于 ContainerCreating 状态。运行kubectl get pods 来查看。并运行kubectl get secrets 以查找默认令牌。

【讨论】：

另外，您是否在本地运行 kubernetes？
感谢您的回答！我确实对此很陌生，但我假设我正在运行一个应该创建 10 个 pod 的工作（基于parallelism: 10）。 pod 被创建，它们在经过ContainerCreating 后进入状态Running。几分钟后，他们被终止了。至于我们在哪里运行 Kubernetes 和 default-token，让我问我的朋友。

【解决方案2】：

我正在与 Pavlo 合作，遇到了这个问题。我从现在开始了解到的是，当 Pod 一个接一个运行时（没有并行性），它们运行正常。当我们尝试同时运行很多它们时，它们会运行一段时间然后被杀死（被驱逐？）有时会产生这个错误：

卷“default-token-7td4s”的 MountVolume.SetUp 失败：无法传播对象缓存：等待条件超时

我们将 kubernetes 作为 DigitalOcean 的托管服务运行。

【讨论】：

【解决方案3】：

抱歉，我没有注意到您不使用 minikube。我已经更正了我的答案。

检查您使用的 Kubernetes 版本。您的日志表明您正在运行 1.12.3。

这已在 1.12.7 的 #74755 中得到解决。

您可以在此处找到更多电子信息：cache secret/configmap behavior。

希望对你有帮助。

【讨论】：