Job и CronJob
Тема дорожной карты · Kubernetes
Kubernetes Job и CronJob — контроллеры рабочих нагрузок для запуска конечных, задачно-ориентированных нагрузок, которые должны успешно завершиться, а не работать непрерывно, как Deployment или StatefulSet. Ресурс Job создаёт один или несколько Pod'ов для выполнения задачи — миграция базы данных, пакетная обработка данных или разовые скрипты — и отслеживает статус завершения через spec.completions и spec.parallelism, повторяя попытки при сбоях вплоть до spec.backoffLimit, после чего помечает Job как неудачный. CronJob оборачивает API Job стандартным Unix cron-выражением в spec.schedule (например, "0 2 * * *" для ночных запусков), автоматически создавая новый Job при каждом срабатывании расписания и управляя историей через spec.successfulJobsHistoryLimit и spec.failedJobsHistoryLimit. Kubernetes CronJob поддерживает spec.concurrencyPolicy: Forbid для предотвращения пересекающихся запусков, а Job'ы могут использовать ttlSecondsAfterFinished для автоматической очистки; при этом kubectl create job <name> --from=cronjob/<cron-name> — удобный паттерн для немедленного запуска вручную на основе шаблона CronJob.
Как это работает
Job и CronJob — один из workload-примитивов Kubernetes. Определяет желаемое состояние набора pods — число реплик, pod template, стратегия обновления — а контроллер непрерывно сводит реальное состояние к желаемому. При падении pod или ноды контроллер планирует замену. При обновлении pod template контроллер оркестрирует rolling update с health-проверками между батчами.
Когда применять
Выбирайте Job и CronJob по характеристикам нагрузки: Deployment для stateless-сервисов (HTTP API, воркеры), StatefulSet для stateful с stable network identity (БД, очереди), DaemonSet для one-pod-per-node инфраструктуры (log-коллекторы, CNI), Job для batch-задач, CronJob для запланированных batch. Смешивание типов без нужды создаёт операционную сложность; выбирайте простейший подходящий примитив.
Типичные ошибки
Workload-ловушки: слишком низкие resource requests (pods scheduled, но выселяются под нагрузкой) или слишком высокие (кластер выглядит полным при малом реальном использовании); отсутствие liveness/readiness-проб (load balancer шлёт трафик на полу-стартанутые pods); использование Deployment для stateful-нагрузок, которым нужна StatefulSet-упорядоченность. Всегда измеряйте реальное использование ресурсов до sizing.