3

ATT : 我不知道为什么，但有时一个 pod 突然将状态变为未知，这就是新 pod 开始的地方

我在 gcloud 中使用 kubernetes。

我为需要运行的 cron 作业构建了 yaml 文件：

apiVersion: batch/v1beta1
kind: CronJob
metadata: 
  name: etl-table-feed-from-schema-vtex-to-schema-sale-all
spec:
  schedule: "* * * * *"
  concurrencyPolicy: "Forbid"
  failedJobsHistoryLimit: 3
  successfulJobsHistoryLimit: 1
  startingDeadlineSeconds: 60 # 1 min
  jobTemplate:
    spec:
      backoffLimit: 0
      #activeDeadlineSeconds: 3600 # 1 hora
      template:
        spec:
          containers:
            - name: etl-table-feed-from-schema-vtex-to-schema-sale-all
              image: (myimage)
              command: ["/bin/sh", "-c"]
              args: (mycommands)
              env:
              - name: PYTHONUNBUFFERED
                value: "1"
              envFrom:
              - secretRef:
                  name: etl-secret
          restartPolicy: Never
          nodeSelector:
        #<labelname>:value
            etlnode: etl-hi-cpu

我一次只需要运行一个 pod，只需要一个。但有时，我不知道为什么，而且我无法重现，一次运行多个 pod。

我已经将 concurrencyPolicy 写为 Forbid，但似乎还不够。

我在 gcloud 的抢占式池中运行它。

同时运行的两个 pod：

在此处输入图像描述在此处输入图像描述

4

2 回答 2

2

就我而言，问题在于这concurrencyPolicy: "Forbid"还activeDeadlineSeconds不够。我以前的 pod 收到SIGTERM但在它实际被杀死之前又运行了 30 秒，所以我最终得到了两个并行运行 30 秒的作业。

请参阅此问题：Kubernetes Cron Job Terminate Pod before creation of next schedule，在我的情况下，此答案提供了解决方案：https ://stackoverflow.com/a/63721120/5868044 。两种选择：

  1. 使 pod 立即停止SIGTERM（例如使用 bash trap 'exit' SIGTERM）
  2. 通过设置小于activeDeadlineSeconds计划间隔，在您的作业之间留出 30 多秒的时间间隔。
于 2020-09-04T07:28:10.663 回答
1

您已设置schedule: "* * * * *"这意味着，每分钟都会创建工作。

concurrencyPolicy：“禁止”按描述工作。

cron 作业不允许并发运行；如果是运行新作业的时间并且之前的作业运行尚未完成，则 cron 作业会跳过新作业运行

意思是，如果仍有未完成的工作，则不允许创建新工作。如果工作已完成，则concurrencyPolicy允许创建另一个。它不允许运行 2 个未完成的作业。

activeDeadlineSeconds:根据Kubernetes 文档

无论创建了多少 Pod，activeDeadlineSeconds 都适用于作业的持续时间。一旦 Job 达到 activeDeadlineSeconds，其所有正在运行的 Pod 都将终止，并且 Job 状态将变为 type: Failed with reason: DeadlineExceeded。

也如Jobs cleanup policy中所述。

如果 Job 由更高级别的控制器直接管理，例如 CronJobs，则可以由 CronJobs 根据指定的基于容量的清理策略来清理 Job。

为了测试我使用busybox了sleep 20命令，因为我不知道你的工作在做什么。

意思是，如果您保留默认设置

spec:
  failedJobsHistoryLimit: 3
  successfulJobsHistoryLimit: 1

它将保留successful工作直到创建下一个工作，如果您想检查日志等，它将保留一段时间。

$ kubectl get cronjob,job,pod
NAME                                                               SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all   * * * * *   False     1        17s             51s

NAME                                                                      COMPLETIONS   DURATION   AGE
job.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018780   0/1           14s        14s

NAME                                                                  READY   STATUS    RESTARTS   AGE
pod/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018h9pnh   1/1     Running   0          13s
---
$ kubectl get cronjob,job,pod
NAME                                                               SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all   * * * * *   False     1        33s             2m7s

NAME                                                                      COMPLETIONS   DURATION   AGE
job.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018780   1/1           23s        90s
job.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018840   1/1           21s        29s

NAME                                                                  READY   STATUS      RESTARTS   AGE
pod/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018h9pnh   0/1     Completed   0          89s
pod/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018k7b58   0/1     Completed   0          29s
---
$ kubectl get cronjob,job,pod
NAME                                                               SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all   * * * * *   False     0        34s             2m8s

NAME                                                                      COMPLETIONS   DURATION   AGE
job.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018840   1/1           21s        30s

NAME                                                                  READY   STATUS      RESTARTS   AGE
pod/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018k7b58   0/1     Completed   0          30s

但是，如果您将设置successfulJobsHistoryLimit为 0，它将在一段时间后删除作业，甚至在下一个预定作业之前。

spec:
  failedJobsHistoryLimit: 3
  successfulJobsHistoryLimit: 0

输出：

$ kubectl get cronjob,job,pod
NAME                                                               SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all   * * * * *   False     1        18s             31s

NAME                                                                      COMPLETIONS   DURATION   AGE
job.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018540   0/1           15s        15s

NAME                                                                  READY   STATUS    RESTARTS   AGE
pod/etl-table-feed-from-schema-vtex-to-schema-sale-all-15930182r5bn   1/1     Running   0          15s
---
$ kubectl get cronjob,job,pod
NAME                                                               SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all   * * * * *   False     1        31s             44s

NAME                                                                      COMPLETIONS   DURATION   AGE
job.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all-1593018540   1/1           22s        28s

NAME                                                                  READY   STATUS      RESTARTS   AGE
pod/etl-table-feed-from-schema-vtex-to-schema-sale-all-15930182r5bn   0/1     Completed   0          28s
---
$ kubectl get cronjob,job,pod
NAME                                                               SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob.batch/etl-table-feed-from-schema-vtex-to-schema-sale-all   * * * * *   False     0        34s             47s

这个时间也取决于工作持续时间。

此外，如果作业成功完成（退出代码 0），则 pod 将状态更改为已完成，它将不再使用 cpu/内存资源。

您还可以阅读有关TTL Mechanism的信息，但不幸的是，我认为它不会在这里工作，因为 Master 由 google 管理，并且此功能需要在Kubelet Feature Gates.

于 2020-06-24T17:36:54.390 回答