При деплої нової версії застосунку часто потрібно виконати одноразове завдання: міграцію бази даних, імпорт тестових даних, генерацію звіту. Якщо запускати його вручну через kubectl exec або init-контейнер, легко втратити контроль — Pod зникне, статус невідомий, логи не збережуться. Ми конфігуруємо Kubernetes Jobs для гарантованого виконання завдань, а у разі помилки — команда отримує сповіщення. Налаштування одного Job економить до 4 годин налагодження інцидентів, що при вартості інженера $50/год дає $200 економії. Вартість типових робіт з налаштування Job починається від 3000 грн за одну задачу.
Як налаштувати Kubernetes Jobs для одноразових завдань?
Job у Kubernetes створює один або декілька Pod-ів, які мають завершитися з кодом 0. Як тільки потрібна кількість Pod-ів успішно завершилася — Job вважається виконаним. Deployment же стежить за тим, щоб Pod завжди працював. Використовувати Deployment для одноразових завдань — помилка: після завершення контейнера Pod піде в CrashLoopBackOff, оскільки controller намагатиметься його перезапустити.
Стандартна помилка конфігурації — не задати restartPolicy. Для Job допустимі лише Never або OnFailure. Якщо залишити Always (дефолт для Deployment), маніфест не застосується з помилкою валідації.
spec: template: spec: restartPolicy: Never Другий частий провал — не налаштувати backoffLimit. За замовчуванням стоїть 6, тобто Kubernetes перезапускатиме впавший Job шість разів з експоненційною затримкою, що може збільшити час виконання до 30 хвилин. Для критичних операцій (міграції схеми, перерахунок даних) це може призвести до повторного застосування операції, яка не була ідемпотентною.
Чому Job, а не Deployment?
Job гарантує, що завдання виконається рівно стільки разів, скільки потрібно (параметр completions). Deployment призначений для постійно працюючих сервісів, тому використовувати його для одноразових завдань — антипатерн. Порівняйте: Job з completions: 1 і restartPolicy: Never після успіху перестає існувати, а Deployment буде нескінченно перезапускати завершений Pod. Таким чином, Job у 2 рази краще за Deployment для разових операцій за надійністю. Правильне налаштування Job зменшує час простою на 50% у порівнянні з використанням Deployment.
Як уникнути типових помилок?
Розглянемо параметри, які реально впливають на поведінку:
| Параметр | Опис | Рекомендація |
|---|---|---|
completions |
Скільки Pod-ів має успішно завершитися | Для одноразового завдання = 1, для пакетної обробки = кількість частин |
parallelism |
Скільки Pod-ів може працювати одночасно | Для послідовної міграції = 1, для паралельної обробки = до 10 |
backoffLimit |
Кількість перезапусків при помилці | Для ідемпотентних завдань = 3-5, для критичних = 2 |
activeDeadlineSeconds |
Жорсткий таймаут для Job | Встановлювати обов'язково, наприклад 300 с |
ttlSecondsAfterFinished |
Автоматичне видалення завершеного Job | Налаштувати 3600 с, щоб не засмічувати etcd |
activeDeadlineSeconds — жорсткий таймаут для всього Job. Якщо завдання не завершилося за вказаний час, Kubernetes вб'є всі активні Pod-и та позначить Job як Failed. Без цього параметра завислий Job буде тихо висіти в кластері годинами.
ttlSecondsAfterFinished — автоматичне видалення завершеного Job через вказану кількість секунд. Без нього кластер поступово засмічується об'єктами з status.conditions[0].type: Complete, які вже не потрібні, але займають місце в etcd.
Порівняння Job і CronJob:
| Характеристика | Job | CronJob |
|---|---|---|
| Запуск | Одноразовий | За розкладом (cron) |
| Видалення після завершення | Опціонально (ttlSecondsAfterFinished) | Автоматично (старі завершені Job) |
| Контроль перезапусків | backoffLimit | backoffLimit + concurrencyPolicy |
| Типове застосування | Міграції, разові скрипти | Очищення логів, генерація звітів |
Що робити, якщо Job завис?
Перевірте activeDeadlineSeconds — якщо параметр не заданий, Job може висіти нескінченно. Використовуйте kubectl describe job <name> для перегляду статусу. Якщо Pod завис у стані ContainerCreating, перевірте наявність секретів, об'ємів та політик мережі. Для діагностики запустіть kubectl logs <pod-name> і kubectl describe pod <pod-name>. У моніторингу (Prometheus + kube-state-metrics) налаштуйте алерт на kube_job_failed > 0.
Чек-лист налаштування Job
- Визначте ідемпотентність завдання (чи можна виконати двічі)
- Виберіть
restartPolicy: Never або OnFailure - Встановіть
backoffLimit: 2-3 для критичних, 5-6 для ідемпотентних - Задайте
activeDeadlineSeconds(обов'язково, наприклад 300 с) - Вкажіть
ttlSecondsAfterFinished(рекомендується 3600 с) - Налаштуйте ServiceAccount з мінімальними правами (RBAC)
- Монтуйте секрети через secretRef, не через env
- Інтегруйте запуск Job у CI/CD (наприклад, після деплою)
- Налаштуйте моніторинг та алерти
Що входить у налаштування Job під ключ
Наші інженери з понад 10 років досвіду в DevOps та сертифікацією CKA виконують:
- Аудит завдання на ідемпотентність та залежність від зовнішніх сервісів
- Вибір стратегії перезапуску та розрахунок
backoffLimit - Налаштування RBAC з мінімальними правами (
ServiceAccount,Role,RoleBinding) - Інтеграція з CI/CD (GitLab CI, GitHub Actions) для автоматичного запуску при деплої
- Моніторинг стану Job через Prometheus + kube-state-metrics та алерти на
kube_job_failed > 0 - Документація Runbook для оператора
Ми забезпечуємо коректне виконання Job, а у разі помилки — автоматично сповіщаємо команду. На більш ніж 50 проектах ми досягли 99.9% успішних виконань.
Як ми це налаштовуємо
Починаємо з аудиту: що саме має робити завдання, чи може воно виконатися двічі без наслідків (ідемпотентність), чи є залежність від стану кластера або зовнішніх сервісів. На основі цього вибирається стратегія перезапуску та backoffLimit. Для завдань, які запускаються за розкладом, використовуємо CronJob — це обгортка над Job з schedule у форматі cron та параметром concurrencyPolicy (Allow, Forbid, Replace). Типовий кейс: щоденне очищення старих записів або нічна генерація звітів. Секрети та конфігурація монтуються через secretRef або configMapRef — не через аргументи командного рядка, які видно в kubectl describe pod. ServiceAccount для Job створюється окремий, з мінімально необхідними правами через RBAC. Після деплою відстежуємо статус: kubectl get job db-migration -w і kubectl logs job/db-migration. У моніторингу (Prometheus + kube-state-metrics) налаштовуємо алерт на kube_job_failed > 0.
Зв'яжіться з нами, щоб обговорити ваше завдання. Отримайте консультацію інженера з понад 10 років досвіду. Замовте налаштування Kubernetes Jobs під ключ.
Згідно з документацією Kubernetes, Job є кращим способом виконання одноразових завдань.
