1) 워크로드 선택의 기준

• Deployment(+HPA)

  • 성격: 상시 처리(큐 워커, 이벤트 소비).
  • 요구: at-least-once 전제, 재시도/내구성, 수평 확장.
  • 의미: 종료코드 143(TERM)은 롤링 등 “정상”일 확률↑ → 알림에서 노이즈 제거.

• Job

  • 성격: 끝이 있는 배치(백필, 리인덱스, 마이그). 완료 후 자원 0.
  • 핵심: completions/parallelism로 작업량·동시성 제어, Indexed로 샤딩/추적.
  • 정책: 실패 분류(podFailurePolicy), TTL 청소로 누적 방지.

• CronJob

  • 성격: 스케줄러(백업, 청소, 리포트).
  • 핵심: 겹침 방지(concurrencyPolicy) + 놓친 스케줄 보전(startingDeadlineSeconds) + 타임존.
  • 정책: 성공/실패 히스토리 제한 + TTL로 “작업 쓰레기” 제어.

2) 필수 파라미터의 “의미”

• concurrencyPolicy (Forbid/Replace/Allow)

  • 재진입 불가 작업이면 Forbid(중복 처리 차단), 최신만 중요하면 Replace.

• startingDeadlineSeconds

  • 컨트롤플레인/스케줄 지연 시 놓친 실행을 보전. 없으면 통째로 건너뜀.

• completionMode: Indexed (Job)

  • 각 완료 인덱스를 고유 샤드로 간주 → 누가 무엇을 처리했는지 추적 가능.

• backoffLimit / activeDeadlineSeconds

  • 재시도 한계/전체 시간 한계로 무한 재시도·좀비 작업 방지.

• ttlSecondsAfterFinished

  • 완료 리소스 자동 정리(운영 디폴트로 활성 가정).

• resources(requests/limits)

  • OOM/Evict 예방의 1순위. 긴 작업은 체크포인트로 재시작 가능 설계.

• topologySpreadConstraints / priorityClassName

  • 배치 분산/중요도 보장(노드 한쪽 치우침·자원 쟁탈 완화).

• timeZone (CronJob)

  • 운영 타임존과 스케줄 혼선 제거(Asia/Seoul 명시).

3) 장애/운영 인사이트

• 중복 실행의 진짜 비용: 재처리·데이터 이중 반영·다운스트림 폭발 → CronJob 겹침 방지가 가장 빠른 보험.
• 스케줄 유실의 진짜 원인: 컨트롤플레인 이벤트 로스·스케줄 지연 → startingDeadlineSeconds로 회복 탄력 확보.
• 배치 실패의 분류 필요성: OOM/스케줄 불가/일시적 디스크압박 등 원인별 대응이 달라짐 → podFailurePolicy로 즉시 Fail/무시/재시도 분기.
• 운영 쓰레기 누적: Job/CronJob은 기본적으로 잔해가 남음 → TTL/HistoryLimit로 SRE 위생 유지.

4) 종료코드의 해석과 앱 행동

• 0: 정상 완료(Completed).

• 143(=128+SIGTERM): 롤링/스케일다운/드레인 등 정상 시나리오에서 흔함.

  • 대응: 배포 이벤트가 있는 윈도우에선 알림 제외(노이즈 컷).

• 137(=128+SIGKILL): Grace 초과 또는 OOMKilled.

  • 대응: terminationGracePeriodSeconds 상향 + preStop 훅으로 우아한 종료, 또는 리소스 증설/메모리 튜닝.

• 앱 관점 가이드

  • SIGTERM 핸들러: 현재 작업 체크포인트/재큐 → Deployment 워커는 exit 0로 빠르게 교체; Job 워커는 미완료면 non-zero로 재시도 유도(단, 안전 재큐 시 0 허용).
  • 블로킹 호출: 타임아웃·주기적 TERM 체크 필수.

5) 관측성 최소 셋

• 라벨/추적키: jobId, commitSha, shardIndex(Indexed) → 문제 재현·영향도 파악 단축.

• 진행률/하트비트: 장시간 작업은 하트비트 파일/키 + 커맨드형 liveness로 “멈춤”을 신호화.

• 메트릭: 완료/실패/재시도 카운트, 실행시간 히스토그램(또는 로그 집계라도).

• 알림 룰:

  • 롤링 중 143은 정상으로 취급(윈도우 제한).
  • OOMKilled는 항상 경고/심각.

6) Redis로 직접 at-least-once 큐 만들 때의 본질

• 수신/확인 분리: BRPOPLPUSH queue → inprogress로 유실 방지(워커 크래시 시 inprogress 스캔).

• 하트비트: 처리 중 task:<id>.lastBeat 갱신 → Reaper CronJob이 타임아웃 항목을 원 큐로 복원.

• 종료 시맨틱:

  • Deployment 워커: 재큐 후 0(교체 신속).
  • Job 워커: 미완료면 non-zero로 컨트롤러 재시도.

7) GitOps에서 안전장치의 위치

• 폴더 = 네임스페이스 바인딩(하드코딩 금지, 파이프라인에서 주입).
• 공통 패치로 기본 가드 주입: ttlSecondsAfterFinished, backoffLimit, activeDeadlineSeconds(Kustomize/Helm).
• 드리프트 억제: kubectl diff / server-side apply / prune.
• HistoryLimit로 컨트롤러 히스토리 관리(관측성 + 청결 균형).

현업에서 가장 효과 큰 5가지

1. CronJob 겹침 방지 안 하면 데이터 이중처리 난리 난다.
2. startingDeadlineSeconds 없으면 스케줄 유실이 “조용히” 지나간다.
3. Job Indexed는 대규모 배치 추적/리트라이 단위의 사실상 표준.
4. TTL + HistoryLimit로 잡 잔해를 자동 청소하라.
5. 143은 정상, 137은 위험 신호—알림 룰을 분리하라.