时间戳

首页 > 解决方案 > 由于对象缓存的传播，作业的 Pod 被杀死

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

问题描述

我们正在尝试在 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。

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

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

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

你知道为什么在这种情况下豆荚会被杀死吗？

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

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

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

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

标签： pythonkubernetescluster-computing

解决方案

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

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

推荐阅读