# Автоматичне очищення завершених задач

> Механізм визначення часу життя для автоматичного очищення старих задач, які завершили виконання.

---

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->








  <div class="feature-state-notice feature-stable">
      <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span>
      <code>Kubernetes v1.23 [stable]</code>
    </div>
  



Коли ваша задача завершилася, корисно залишити цю задачу в API (і не видаляти її відразу), щоб ви могли визначити, чи вдалося, чи не вдалося завдання.

<a class='glossary-tooltip' title='Контролер — цикл управління, що спостерігає за загальним станом кластера через apiserver і вносить зміни в намаганні наблизити поточний стан до бажаного.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/controller/' target='_blank' aria-label='Контролер'>Контролер</a> часу життя Kubernetes після завершення забезпечує механізм TTL (time to live), щоб обмежити термін життя обʼєктів задачі, які завершили виконання.

<!-- body -->

## Очищення завершених задач {#cleanup-for-finished-jobs}

Контролер часу життя після завершення підтримується лише для задач. Ви можете використовувати цей механізм для автоматичного очищення завершених завдань (як `Complete`, так і `Failed`), автоматично вказавши поле `.spec.ttlSecondsAfterFinished` задачі, як у цьому [прикладі](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).

Контролер часу життя після завершення передбачає, що задачу можна очистити через TTL секунд після завершення роботи. Відлік починається, коли умова статусу задачі змінюється, щоб показати, що задача є або `Complete`, або `Failed`; як тільки TTL закінчився, ця задача стає придатною для [каскадного](/docs/concepts/architecture/garbage-collection/#cascading-deletion) видалення. Коли контролер часу життя після завершення очищає задачу, він видалить її каскадно, іншими словами, він видалить її залежні обʼєкти разом з нею.

Kubernetes дотримується гарантій життєвого циклу обʼєкта для задачі, таких як очікування [завершувачів](/docs/concepts/overview/working-with-objects/finalizers/).

Ви можете встановити TTL секунд у будь-який момент. Ось деякі приклади встановлення поля `.spec.ttlSecondsAfterFinished` задачі:

* Вказуйте це поле в маніфесті задачі, щоб задачу можна було автоматично очистити через певний час після її завершення.
* Вручну встановлюйте це поле вже наявним завершеним завданням, щоб вони стали придатними для очищення.
* Використовуйте [змінний вебхук доступу](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) для динамічного встановлення цього поля під час створення задачі. Адміністратори кластера можуть використовувати це, щоб накладати політику TTL для завершених задач.
* Використовуйте [змінний вебхук доступу](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) для динамічного встановлення цього поля після завершення задачі та вибору різних значень TTL на основі статусу завдання, міток. У цьому випадку вебзапит повинен виявляти зміни в полі `.status` задачі та встановлювати TTL лише тоді, коли задача позначається як завершена.
* Напишіть свій власний контролер для управління часом життя TTL для задач, які відповідають певному <a class='glossary-tooltip' title='Дозволяє користувачам фільтрувати ресурси за мітками.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/labels/' target='_blank' aria-label='селектору'>селектору</a>.

## Обмеження {#caveats}

### Оновлення TTL для завершених задач {#updating-ttl-for-finished-jobs}

Ви можете змінювати період TTL, наприклад, поле `.spec.ttlSecondsAfterFinished` для задач, після створення або завершення задачі. Якщо ви збільшуєте період TTL після закінчення поточного періоду `ttlSecondsAfterFinished`, Kubernetes не гарантує збереження цієї задачі, навіть якщо оновлення для збільшення TTL повертає успішну API відповідь.

### Зсув часу {#time-skew}

Оскільки контролер часу життя після завершення використовує відмітки часу, збережені в задачах Kubernetes, для визначення того, чи TTL минув, чи ні, ця функція чутлива до зсуву часу в кластері, що може призвести до очищення обʼєктів задачі в неправильний час.

Годинники не завжди вірні, але різниця повинна бути дуже мала. Будь ласка, будьте уважні при встановленні ненульового TTL.

## Що далі

* Прочитайте [Автоматичне очищення задач](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)

* Зверніться до [Пропозиції з покращення Kubernetes](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md) (KEP) для додавання цього механізму.