Чтобы сделать вещи максимально простыми, я протестировал его, используя этот пример из официальной документации kubernetes, применив к нему небольшие изменения, чтобы проиллюстрировать, что действительно происходит в различных сценариях ios.
Я могу подтвердить, что когда backoffLimit
установлен на 0
и restartPolicy
на Never
, все работает точно так, как ожидалось, и нет повторных попыток . Обратите внимание, что каждый запуск вашего Job
, который в вашем примере запланирован для запуска с интервалами в 60 секунд (schedule: "*/1 * * * *"
) НЕ считается повторной попыткой .
Давайте подробнее рассмотрим следующий пример (база yaml
avialable здесь ):
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
backoffLimit: 0
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- non-existing-command
restartPolicy: Never
Он порождает новое задание cron every 60 seconds
в соответствии с schedule
, не имеет значения, если он не работает или работает успешно. В этом конкретном примере он настроен на сбой, так как мы пытаемся запустить non-existing-command
.
. Вы можете проверить, что происходит, запустив:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1587558720-pgqq9 0/1 Error 0 61s
hello-1587558780-gpzxl 0/1 ContainerCreating 0 1s
Как вы можете видеть, без попыток . Хотя первый Pod
потерпел неудачу, новый появился через 60 секунд в соответствии с нашей спецификацией. Я хотел бы подчеркнуть это еще раз. Это не повтор.
С другой стороны, когда мы модифицируем вышеприведенный пример и устанавливаем backoffLimit: 3
, мы можем наблюдать повторов . Как видите, теперь новые Pods
создаются гораздо чаще, чем каждые 60 секунд . Это повторные попытки.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1587565260-7db6j 0/1 Error 0 106s
hello-1587565260-tcqhv 0/1 Error 0 104s
hello-1587565260-vnbcl 0/1 Error 0 94s
hello-1587565320-7nc6z 0/1 Error 0 44s
hello-1587565320-l4p8r 0/1 Error 0 14s
hello-1587565320-mjnb6 0/1 Error 0 46s
hello-1587565320-wqbm2 0/1 Error 0 34s
То, что мы видим выше, это 3 попытки (Pod
попытки создания), связанные с hello-1587565260
заданием и 4 попытки (включая оригинал 1-я попытка , не учитываемые в backoffLimit: 3
), связанные с hello-1587565320
job .
Как вы можете видеть, заданий сами по-прежнему выполняются в соответствии с расписанием, с интервалом в 60 секунд :
kubectl get jobs
NAME COMPLETIONS DURATION AGE
hello-1587565260 0/1 2m12s 2m12s
hello-1587565320 0/1 72s 72s
hello-1587565380 0/1 11s 11s
Однако из-за нашего backoffLimit
установите это время до 3
, каждый раз, когда Pod
, ответственный за выполнение задания, терпит неудачу, происходит 3 дополнительные попытки .
Я надеюсь, что это помогло рассеять любые возможные путаницы в отношении выполнения cronJobs
в kubernetes .
Если вы заинтересованы в том, чтобы запускать что-то один раз, а не через регулярные промежутки времени, взгляните на простое Job вместо CronJob
.
Также рассмотрите возможность изменения конфигурации Cron , если вы все еще хотите запускать это конкретное задание на регулярной основе b но скажем раз в 24 часа, а не каждую минуту.