완료된 Job의 자동 정리

완료된 Job의 자동 정리 (Automatic Cleanup for Finished Jobs)

실행이 끝난 오래된 Job을 정리하는 time-to-live(TTL) 메커니즘에 대해 설명할게요.

기능 상태: Kubernetes v1.23 [stable]

Job이 완료되면, 그 Job이 성공했는지 실패했는지 알 수 있도록 Job을 API에 (즉시 삭제하지 않고) 보관해 두는 게 유용해요.

쿠버네티스의 TTL-after-finished 컨트롤러는 실행이 끝난 Job 객체의 수명을 제한하는 TTL(생존 시간) 메커니즘을 제공해요.

출처: Kubernetes 공식 문서 — Automatic Cleanup for Finished Jobs

완료된 Job 정리

TTL-after-finished 컨트롤러는 Job만 지원해요. 이 메커니즘을 사용해 Job의 .spec.ttlSecondsAfterFinished 필드를 지정하면 완료된 Job(Complete 또는 Failed)을 자동으로 정리할 수 있어요. 이 예시를 참고하세요.

TTL-after-finished 컨트롤러는 Job이 완료된 후 TTL 초가 지나면 정리 대상이 된다고 가정해요. 타이머는 Job의 상태 조건이 Complete 또는 Failed로 바뀌는 것을 보여줄 때 시작돼요. TTL이 만료되면 그 Job은 연쇄(cascading) 제거 대상이 돼요. TTL-after-finished 컨트롤러가 Job을 정리할 때는 연쇄적으로 삭제하는데, 즉 의존 객체도 함께 삭제한다는 뜻이에요.

쿠버네티스는 finalizer를 기다리는 것 같은 Job의 객체 수명주기 보장을 존중해요.

TTL 초는 언제든 설정할 수 있어요. Job의 .spec.ttlSecondsAfterFinished 필드를 설정하는 예시는 다음과 같아요.

  • Job 매니페스트에 이 필드를 지정해서, Job이 완료된 후 일정 시간이 지나면 자동으로 정리되게 해요.
  • 이미 완료된 기존 Job에 이 필드를 수동으로 설정해 정리 대상이 되게 해요.
  • mutating admission webhook을 사용해 Job 생성 시점에 이 필드를 동적으로 설정해요. 클러스터 관리자는 이렇게 해서 완료된 Job에 대한 TTL 정책을 강제할 수 있어요.
  • mutating admission webhook을 사용해 Job이 완료된 후 이 필드를 동적으로 설정하고, Job 상태나 라벨에 따라 다른 TTL 값을 선택해요. 이 경우 webhook은 Job의 .status 변경을 감지해야 하고 Job이 완료로 표시될 때만 TTL을 설정해야 해요.
  • Job의 특정 셀렉터와 일치하는 Job의 정리 TTL을 관리하는 자체 컨트롤러를 작성해요.

주의사항 (Caveats)

완료된 Job의 TTL 업데이트

Job이 생성된 후나 완료된 후에 TTL 기간(예: Job의 .spec.ttlSecondsAfterFinished 필드)을 수정할 수 있어요. 기존 ttlSecondsAfterFinished 기간이 만료된 후에 TTL 기간을 연장하는 경우, TTL 연장 업데이트가 성공적인 API 응답을 반환해도 쿠버네티스가 그 Job을 보존한다는 보장은 없어요.

시간 왜곡 (Time skew)

TTL-after-finished 컨트롤러는 쿠버네티스 Job에 저장된 타임스탬프를 사용해 TTL이 만료됐는지 판단하기 때문에, 이 기능은 클러스터의 시간 왜곡(time skew)에 민감해요. 이는 컨트롤 플레인이 잘못된 시점에 Job 객체를 정리하게 할 수 있어요.

시계가 항상 정확한 것은 아니지만, 그 차이는 매우 작아야 해요. 0이 아닌 TTL을 설정할 때 이 위험을 인지하고 있어야 해요.

다음으로 볼 것 (What's next)