SeniorКодРедкоЕщё не отвечали

Запуски CronJob накладываются и копятся — исправьте через concurrencyPolicy и лимиты истории.

Запуски этого CronJob иногда идут дольше интервала, поэтому новый стартует, пока прошлый ещё работает, а завершённые Job копятся.

Ограничения: не давать запускам накладываться и ограничить, сколько завершённых/упавших Job хранится. Меняйте только поля spec CronJob — не трогайте расписание и контейнер.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report
spec:
  schedule: "*/5 * * * *"
  # запуск может идти 8 мин и наложиться на следующий тик;
  # завершённые/упавшие Job копятся в namespace
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report
              image: report:1.4

Добавьте поля, которые убирают наложение и ограничивают историю Job.

Задайте concurrencyPolicy: Forbid, чтобы новый запуск пропускался, пока предыдущий Job ещё идёт (или Replace, чтобы отменить старый). Ограничьте историю через successfulJobsHistoryLimit и failedJobsHistoryLimit (например 3 и 1); startingDeadlineSeconds пропускает просроченные тики. Forbid убирает накопление, а лимиты — старые Job из namespace.

✗Думать, что concurrencyPolicy: Allow предотвращает наложение (он его разрешает)
✗Путать лимиты истории с настройками повторов или параллелизма
✗Использовать suspend (который останавливает все запуски) для фикса наложения

→Чем Forbid и Replace различаются, когда запуск ещё идёт?
→Что делает startingDeadlineSeconds, когда контроллер пропускает расписание?

Решение

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report
spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: Forbid          # новый запуск пропускается, пока идёт прошлый
  startingDeadlineSeconds: 120       # не запускать давно просроченные тики
  successfulJobsHistoryLimit: 3      # хранить 3 успешных Job
  failedJobsHistoryLimit: 1          # хранить 1 упавший Job
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report
              image: report:1.4

Job ещё не завершён (Replace вместо него отменил бы старый и запустил новый; Allow, дефолт, как раз и разрешает наложение).

остаётся, — это убирает засорение namespace, а не число повторов.

недоступен), очень старые тики не «доганяются».

concurrencyPolicy: Forbid — контроллер пропускает тик, если предыдущий
successful/failedJobsHistoryLimit ограничивают, сколько завершённых Job
startingDeadlineSeconds — если контроллер пропустил окно (например был

Открыть тему в роадмапе →

Запуски CronJob накладываются и копятся — исправьте через concurrencyPolicy и лимиты истории.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report
spec:
  schedule: "*/5 * * * *"
  # запуск может идти 8 мин и наложиться на следующий тик;
  # завершённые/упавшие Job копятся в namespace
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report
              image: report:1.4

Добавьте поля, которые убирают наложение и ограничивают историю Job.

Решение

apiVersion: batch/v1 kind: CronJob metadata: name: report spec: schedule: "*/5 * * * *" concurrencyPolicy: Forbid # новый запуск пропускается, пока идёт прошлый startingDeadlineSeconds: 120 # не запускать давно просроченные тики successfulJobsHistoryLimit: 3 # хранить 3 успешных Job failedJobsHistoryLimit: 1 # хранить 1 упавший Job jobTemplate: spec: template: spec: restartPolicy: OnFailure containers: - name: report image: report:1.4

остаётся, — это убирает засорение namespace, а не число повторов.

недоступен), очень старые тики не «доганяются».

concurrencyPolicy: Forbid — контроллер пропускает тик, если предыдущий

successful/failedJobsHistoryLimit ограничивают, сколько завершённых Job

startingDeadlineSeconds — если контроллер пропустил окно (например был