Kubernetes Cronjob 只运行一半的时间答案

【问题标题】：Kubernetes Cronjob Only Runs Half the TimeKubernetes Cronjob 只运行一半的时间
【发布时间】：2018-05-08 01:08:01
【问题描述】：

我希望每 15 分钟触发一次作业，但它始终每 30 分钟触发一次。

更新：

我已经通过运行简化了问题：

kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster"

这里的文档中指定：https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

但作业仍然拒绝按时运行。

$ kubectl get cronjobs
NAME               SCHEDULE      SUSPEND   ACTIVE    LAST SCHEDULE   AGE
hello              */1 * * * *   False     1         5m              30m
hello2             */1 * * * *   False     1         5m              12m

命令行创建的 cronjob 需要 25 分钟才能运行，而从 yaml 创建的 cronjob 需要 7 分钟。他们最终都被安排在同一时间，所以这几乎就像 etcd 终于醒来并做了什么？

原始问题：

当我深入到一个活跃的工作时，我看到 Status: Terminated: Completed 但是 Age: 25 minutes 或大于 15 的值。

在日志中，我看到要运行的 python 脚本已经完成了它的最终打印语句。根据 s3 中的输出文件，该脚本大约需要 2 分钟才能完成。然后再过 28 分钟就不会安排新作业了。

我尝试过不同的配置：

Schedule: */15 * * * * 和 Schedule: 0,15,30,45 * * * *

还有

Concurrency Policy: Forbid 和 Concurrency Policy: Replace

这里还有什么问题？

修改了标识行的完整配置：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  labels:
    type: f-c
  name: f-c-p
  namespace: extract
spec:
  concurrencyPolicy: Forbid
  failedJobsHistoryLimit: 1
  jobTemplate:
    metadata:
      creationTimestamp: null
    spec:
      template:
        metadata:
          creationTimestamp: null
          labels:
            type: f-c
        spec:
          containers:
          - args:
            - /f_c.sh
            image: identifier.amazonaws.com/extract_transform:latest
            imagePullPolicy: Always
            env:
            - name: ENV
              value: prod
            - name: SLACK_TOKEN
              valueFrom:
                secretKeyRef:
                  key: slack_token
                  name: api-tokens
            - name: AWS_ACCESS_KEY_ID
              valueFrom:
                secretKeyRef:
                  key: aws_access_key_id
                  name: api-tokens
            - name: AWS_SECRET_ACCESS_KEY
              valueFrom:
                secretKeyRef:
                  key: aws_secret_access_key
                  name: api-tokens
            - name: F_ACCESS_TOKEN
              valueFrom:
                secretKeyRef:
                  key: f_access_token
                  name: api-tokens
            name: s-f-c
            resources: {}
            terminationMessagePath: /dev/termination-log
            terminationMessagePolicy: File
          dnsPolicy: ClusterFirst
          restartPolicy: Never
          schedulerName: default-scheduler
          securityContext: {}
          terminationGracePeriodSeconds: 30
  schedule: '*/15 * * * *'
  successfulJobsHistoryLimit: 1
  suspend: false
status: {}

【问题讨论】：

*/15 * * * * 时间表应该可以正常工作，您可以发布您的 cronjob 规范吗？其他字段可能会影响它（例如startingDeadlineSeconds）
当然，已添加。谢谢！
@Sosdoc 想再看看？即使是最简单的命令也不会按时运行
我会将这个：imagePullPolicy: Always 更改为这个：imagePullPolicy: IfNotPresent 并寻找结果。 AFAIK 它花费更多时间在互联网上提取图像并因此陷入问题
@ProGirlXOXO 我检查了更改日志，但没有提到这个问题，我能提供的最好建议是尝试在主服务器上重新启动 docker 进程（也许是 api-server，尝试更改一些配置在 master 上强制重新加载）。

标签： kubernetes

【解决方案1】：

在测试集群中运行这些作业后，我发现外部环境阻止它们按预期运行。

在原始集群上，有大约 20k 个计划作业。 Kubernetes 的内置调度程序尚不能一致地处理此卷。

可以可靠运行的作业的最大数量（在预期时间的一分钟内）可能取决于您的主节点的大小。

【讨论】：

【解决方案2】：

这不是设计的吗？

一个 cron 作业大约在其计划的每个执行时间创建一个作业对象。我们说“约”是因为在某些情况下可能会创造两个工作岗位，或者可能不会创造任何工作岗位。我们试图使这些罕见，但不完全阻止它们。因此，作业应该是幂等的。

参考。 https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitations

【讨论】：

“我们试图让这些变得稀有。”这个问题并不罕见，它是一贯的。