Question

我正在运行定义为here的作业，即“使用工作队列的并行处理” 在GKE上

每个pod运行一个容器，并且该容器具有R脚本，大约需要5分钟才能完成，然后Pod成功完成。

当我完成少量工作时，

completions: 606
parallelism: 450
backoffLimit: 1

一切正常，Cluster正确扩展和缩小，Job完成。

但是当我以诸如

completions: 37572
parallelism: 1610
backoffLimit: 1

Pod成功计数增加了一段时间，但之后保持不变在1000到1500之间，并且永远无法完成

尽管pod成功完成，但我可以在google cloud kubernetes仪表板上看到它们，并且输出文件也正在成功生成。队列也非常准确地显示进度

每次我以很高的并行度运行这项工作时，事情就发生了。我针对群集类型为64-CPU，32-CPU，16-CPU的机器类型尝试了不同的自动扩展节点池设置。

目前，我的处理方式是
=>当队列有使用者数量时==并行性或files_in_output ==完成次数
=>我删除作业并删除自动扩展节点池。

请找到群集详细信息

运行期间群集状态始终为绿色。

问题

为什么工作完成计数在某个点之后永远不会增加（在我的情况下，即低于并行计数）？即使广告连播成功完成了。
最糟糕的是工作完成次数也减少了吗？我什至不明白。 kubernetes如此行为的原因是什么？
我是否需要在规范模板中添加一些其他字段，以便它可以正确跟踪工作完成情况吗？

更新：

我有足够的CPU配额
每个容器（Pod）只能使用1个CPU和1GB RAM。
我还将群集和节点池升级到1.10.6-gke.2版本。没有运气。

已报告GKE问题=> https://issuetracker.google.com/issues/114650730

job.yml

apiVersion: batch/v1
kind: Job
metadata:
  # Unique key of the Job instance
  name: my-job
spec:
  completions: 37572
  parallelism: 1610
  backoffLimit: 1
  template:
    metadata:
      name: my-job
      labels:
        jobgroup: my-jobs
    spec:
      volumes:
      - name: jobs-pv-storage
        persistentVolumeClaim:
          claimName: fileserver-claim
          readOnly: false
      containers:
      - name: rscript
        image: gcr.io/project/image:v1
        resources:
          limits:
            cpu: "1"
            memory: 1200Mi
          requests:
            cpu: "1"
            memory: 1000Mi
        env:
        - name: BROKER_URL
          value: amqp://user:pwd@rabbitmq-service:5672
        - name: QUEUE
          value: job-queue
        volumeMounts:
        - mountPath: /opt/work/output
          name: jobs-pv-storage
      # Do not restart containers after they exit
      restartPolicy: Never

Answer 1

发布为社区Wiki。

如@Rahul Gautam原始问题所述：https://issuetracker.google.com/issues/114650730不可见，因为其中包含一些私人信息。出现了一个新的公开问题：https://issuetracker.google.com/issues/172663707，其发布日期为Intended behavior

简而言之，这种情况与Pod Garbage Collector的行为有关。

Pod垃圾收集器会干扰作业的完成。垃圾收集器的阈值由here中记录的--terminated-pod-gc-threshold中的kube-controller-manager标志控制。默认值为12500，它是整个群集的，因此它计算所有名称空间中的所有作业。

--terminated-pod-gc-threshold int32     Default: 12500
Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. If <= 0, the terminated pod garbage collector is disabled.

由于这个事实，当工作数量少于12500时，您将不会遇到此问题。

作为解决方法，您可以更改--terminated-pod-gc-threshold标志以使其不达到此阈值。但是，由于GKE控制器管理器由Google管理，因此GKE用户无法更改该值。

此外，已经有关于重新实现此行为的公开Github thread。

kubernetes不会跟踪Pod成功完成的次数

1 个答案: