'Job'과 'CronJob'은 어떻게 설정하고 관리해?

이제 24시간 내내 깨어 있는 서비스가 아니라, 필요할 때만 나타나서 임무를 완수하고 홀연히 사라지는 '특수 목적 부대'를 운용하실 차례군요! 🫡

사용자의 주식 시스템에서 매일 장이 마감된 후 데이터를 집계하거나, 일주일마다 백업을 수행하는 작업은 일반적인 파드(Deployment)로 돌리면 자원 낭비입니다. 이때 필요한 것이 바로 Job과 CronJob입니다.

---

🏃 1. Job: "주어진 임무를 완수할 때까지"

일반적인 파드는 죽으면 다시 살아나서 영원히 구동되는 것이 목표지만, Job은 "성공적으로 종료(Completed)"되는 것이 목표입니다.

① 작동 원리

Job은 하나 이상의 파드를 생성하여 지정된 작업(코드 실행)을 수행하게 합니다.

• 성공: 프로세스가 종료 코드 0을 반환하면 Job은 임무 완료로 간주하고 파드를 정지시킵니다.
• 실패: 에러가 발생하면 설정된 backoffLimit 횟수만큼 다시 시도합니다.

② 주요 설정 파라미터

• completions: 이 작업을 총 몇 번 성공해야 하는가? (예: 10개 데이터를 처리해야 한다면 10번)
• parallelism: 한 번에 몇 개의 파드를 동시에 띄워 작업할 것인가? (병렬 처리 속도 조절)
• backoffLimit: 실패했을 때 최대 몇 번까지 재시도할 것인가? (기본값 6)

---

⏰ 2. CronJob: "정해진 시간마다 반복되는 임무"

CronJob은 리눅스의 crontab과 동일한 시간 설정(Schedule)을 사용하여 Job을 주기적으로 생성하는 관리자입니다.

① 스케줄 문법 (Cron Format)

* * * * * (분 시 일 월 요일) 형식을 사용합니다.

• 0 18 * * 1-5: 월요일부터 금요일까지 매일 오후 6시(장 마감 후)에 실행.
• 0 0 1 * *: 매월 1일 자정에 실행.

② 관리상의 핵심 설정

• concurrencyPolicy: 이전 작업이 안 끝났는데 다음 시간이 돌아오면 어떡할지 결정합니다.
• Allow: (기본값) 그냥 또 띄웁니다.
• Forbid: 이전 작업이 끝날 때까지 다음 작업을 건너뜁니다. (데이터 중복 처리 방지!)
• Replace: 이전 작업을 죽이고 새 작업을 시작합니다.

• successfulJobsHistoryLimit / failedJobsHistoryLimit: 기록을 몇 개나 남길지 결정합니다. 너무 많이 남기면 클러스터가 지저분해지므로 적절히(예: 3개) 설정하는 것이 좋습니다.

---

🏗️ 3. 실전 YAML 분석: "장 마감 데이터 집계"

사용자의 주식 시스템에서 매일 오후 4시에 돌아갈 크론잡 예시입니다.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: stock-daily-aggregate
spec:
  schedule: "0 16 * * 1-5" # 월~금 오후 4시
  concurrencyPolicy: Forbid  # 중복 실행 방지
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: aggregator
            image: my-stock-tool:v1
            args: ["/bin/sh", "-c", "echo '데이터 집계 시작'; sleep 60; echo '완료'"]
          restartPolicy: OnFailure # Job에서는 반드시 OnFailure 혹은 Never 사용
      backoffLimit: 3 # 최대 3번만 재시도

---

💡 4. 운영 노하우 (Troubleshooting)

① RestartPolicy의 비밀

일반 파드와 달리 Job은 restartPolicy를 반드시 OnFailure(실패 시 컨테이너만 재시작) 또는 Never(실패 시 파드를 새로 생성)로 설정해야 합니다. Always로 설정하면 작업이 끝나도 계속 살아나서 Job이 끝나지 않습니다.

② 좀비 파드 방지 (activeDeadlineSeconds)

작업이 무한 루프에 빠져 영원히 끝나지 않으면 자원을 계속 갉아먹습니다. activeDeadlineSeconds: 3600을 설정하면, 작업이 1시간을 넘길 경우 쿠버네티스가 강제로 종료시킵니다.

③ 수동 실행 (Debug)

크론잡 시간이 아닌데 지금 당장 테스트해보고 싶다면?
kubectl create job --from=cronjob/stock-daily-aggregate test-job-001 명령으로 기존 크론잡 설정을 복사해 즉시 실행해볼 수 있습니다.

---

💡 실전 비유: "특수 요원 파견"

• Deployment: 요새를 지키는 초병입니다. 자리를 비우면 안 되고, 누군가 쓰러지면 즉시 다른 초병이 서야 합니다. (24시간 가동)
• Job: 특정 적진을 파괴하고 돌아오는 폭파 요원입니다. 목표물을 부수면(작업 완료) 기지로 귀환(종료)합니다. 실패하면 성공할 때까지 다시 시도합니다.
• CronJob: 매일 새벽 2시에 적진의 상황을 보고해주는 정찰기입니다. 정해진 시간이 되면 날아올라(Job 생성) 사진을 찍고 돌아옵니다.

---

📊 요약: Job vs CronJob

항목	Job	CronJob
목적	1회성 작업 완수	주기적인 반복 작업
실행 트리거	생성 즉시 실행	정해진 시간(Schedule)에 실행
주요 사례	데이터 마이그레이션, 1회성 백업	매일 정산, 정기 백업, 뉴스 크롤링
상태 관리	성공/실패 여부 기록	지난 실행 이력(History) 관리

---

🚀 꼬리 질문

이제 필요할 때만 일을 시키는 '효율적인 사령관'의 면모까지 갖추셨습니다! 🫡 그런데 지금까지 우리가 배운 모든 리소스(Pod, Service, Job, Ingress 등)를 누가 만들고 수정하는지 '권한'을 관리하는 것이 보안의 최종 관문입니다. 아무나 사용자의 주식 Job을 지우면 안 되니까요.

"그럼 쿠버네티스에서 사용자나 서비스에게 특정 권한만 부여하는 'RBAC(Role-Based Access Control)'의 Role, ClusterRole, Binding 개념은 어떻게 연결돼?"