Job/CronJob — '계속 떠 있기'가 아니라 '끝까지 완료하기'가 목표인 워크로드
Kubernetes Job/CronJob 및 RBAC 공식 문서 종합 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/workloads/controllers/job, reference/access-authn-authz/rbac) Kubernetes 공식문서 Jobs
이 모듈을 다 읽으면
- Job이 Deployment(k8s-learn-02)와 근본적으로 다른 목표(상시 가동 vs 완료)를 가진다는 것을 설명할 수 있다
- backoffLimit과 activeDeadlineSeconds가 각각 어떤 실패 시나리오를 제한하는지 설명할 수 있다
k8s-learn-02에서 다룬 Deployment(항상 지정된 replica 수를 유지)와 대비해, '끝까지 실행돼 성공적으로 완료되는 것'이 목표인 Job과 그걸 스케줄에 맞춰 반복 실행하는 CronJob을 정리한다.
Deployment와의 근본적 차이 — '유지'가 아니라 '완료'가 목표
k8s-learn-02의 Deployment는 Pod가 죽으면 replica 수를 맞추기 위해 계속 새 Pod를 만들어 '상시 가동' 상태를 유지하는 게 목표다. Job은 반대다 — completions(성공적으로 완료돼야 할 Pod 수, 기본 1)만큼 성공하면 그것으로 끝이고, 더 이상 새 Pod를 만들지 않는다. parallelism(동시에 실행할 Pod 수, 기본 1)으로 병렬 처리량을 조절할 수 있다. Job Pod의 restartPolicy는 Always가 아니라 OnFailure나 Never여야 한다 — '완료'라는 개념 자체가 성립하려면 무한정 재시작되면 안 되기 때문이다.
핵심 포인트
- Deployment(k8s-learn-02): 항상 replica 수 유지가 목표 / Job: completions(기본 1)만큼 성공하면 종료, 더 안 만듦
- parallelism으로 동시 실행 수 조절, restartPolicy는 Always 불가(OnFailure/Never만) — '완료' 개념이 성립하려면 무한 재시작 불가
backoffLimit과 activeDeadlineSeconds — 서로 다른 종류의 실패 제한
backoffLimit(기본 6)은 Job이 실패로 간주되기 전까지 허용하는 재시도 횟수다 — 이 횟수를 넘으면 Job 자체가 실패 처리된다. activeDeadlineSeconds는 이와 다른 축이다 — 재시도 횟수와 무관하게, Job이 시작된 뒤 이 시간을 넘기면 무조건 강제 종료시키는 절대적 시간 상한이다. 즉 backoffLimit은 '몇 번까지 봐줄까'이고 activeDeadlineSeconds는 '아무리 재시도 중이어도 이 시간을 넘기면 무조건 끝'이라는 하드 타임아웃이다.
핵심 포인트
- backoffLimit(기본 6): 실패로 간주되기 전 허용 재시도 횟수
- activeDeadlineSeconds: 재시도 횟수와 무관하게 Job 시작 후 이 시간을 넘기면 무조건 강제 종료하는 절대 시간 상한
CronJob — Job을 스케줄에 맞춰 찍어낸다
CronJob은 cron 문법의 schedule(예: */5 * * * *, 5분마다)에 맞춰 Job을 반복 생성하는 상위 컨트롤러다. 이전 실행이 아직 안 끝났는데 다음 스케줄이 도래하면 어떻게 할지는 concurrencyPolicy가 정한다 — Allow(기본값, 겹쳐서 동시 실행 허용)/Forbid(새 실행을 건너뜀)/Replace(기존 실행을 취소하고 새 걸로 교체) 세 가지다. 배치 집계처럼 겹치면 안 되는 작업에는 Forbid가 흔히 쓰인다.
핵심 포인트
- CronJob: schedule(cron 문법)에 맞춰 Job을 반복 생성
- concurrencyPolicy: Allow(기본, 겹침 허용)/Forbid(새 실행 건너뜀)/Replace(기존 취소 후 교체) — 겹치면 안 되는 배치 집계 등엔 Forbid가 흔히 쓰임