Как мне убедиться, что моя работа cronjob НЕ повторяется при неудаче? - PullRequest
Новая
       73

Как мне убедиться, что моя работа cronjob НЕ повторяется при неудаче?

0 голосов
/ 22 апреля 2020

У меня есть Kubernetes Cronjob, который работает на GKE и выполняет тесты Cucumber JVM. В случае сбоя шага из-за ошибки утверждения, когда какой-то ресурс недоступен, и т. Д. c., Cucumber справедливо выдает исключение, которое приводит к сбою задания Cronjob, и состояние модуля Kubernetes изменяется на ERROR. Это приводит к созданию нового модуля, который снова пытается выполнить те же тесты на огурец, что снова дает сбой и повторяет попытку.

Я не хочу, чтобы какое-либо из этих повторений повторялось. В случае сбоя задания Cronjob я хочу, чтобы оно оставалось в состоянии сбоя и вообще не повторялось. Исходя из этого , я уже пытался установить backoffLimit: 0 в сочетании с restartPolicy: Never в сочетании с concurrencyPolicy: Forbid, но он все еще повторяется, создавая новые модули и снова выполняя тесты.

Чего мне не хватает? Вот мой манифест кубе для Cronjob: 

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: quality-apatha
  namespace: default
  labels:
    app: quality-apatha
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      backoffLimit: 0
      template:
        spec:
          containers:
            - name: quality-apatha
              image: FOO-IMAGE-PATH
              imagePullPolicy: "Always"
              resources:
                limits:
                  cpu: 500m
                  memory: 512Mi
              env:
                - name: FOO
                  value: BAR
              volumeMounts:
                - name: FOO
                  mountPath: BAR
              args:
                - java
                - -cp
                - qe_java.job.jar:qe_java-1.0-SNAPSHOT-tests.jar
                - org.junit.runner.JUnitCore
                - com.liveramp.qe_java.RunCucumberTest
          restartPolicy: Never
          volumes:
            - name: FOO
              secret:
                secretName: BAR

Есть ли другие Kubernetes Kind, которые я могу использовать, чтобы остановить повтор?

Спасибо!

1 Ответ

1 голос
/ 22 апреля 2020

Чтобы сделать вещи максимально простыми, я протестировал его, используя этот пример из официальной документации 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 часа, а не каждую минуту.

...