Job pod는 4/4 Running이고 describe에도 특이 이벤트가 없는데 로그가 Pod is ready 이후로 더 이상 찍히지 않고 세션 화면에도 코드가 보이지 않는다. dashboards 테이블을 조회하면 k8s_started_at/k8s_finished_at 컬럼이 비어 있어, 스케줄은 성공했지만 실제 워크로드가 시작되지 못한 상태로 보인다.
원본 케이스에서는 정확히 어떤 시간 오차가 어떤 내부 컴포넌트의 대기 로직을 멈추게 했는지까지는 특정하지 않았고, '시간 동기화 문제 해결 뒤 재발하지 않음'이라는 결과만 확인됐다. 다른 원인으로 같은 증상이 재발할 가능성은 배제할 수 없다.
클러스터 노드 간 시간 동기화(NTP) 문제를 먼저 배제한다. 시간 동기화를 바로잡은 뒤로는 동일한 job stuck 현상이 재발하지 않았다.
확인 수준: 원본에서 해결 확인 · 실행 절차 보강
적용 조건: <...>와 예시 DB·테이블·경로·수치는 실제 확인값으로 바꾼다. 명령과 메뉴는 참고 문서를 바탕으로 보강한 예시이며 대상 시스템에서 실행하지 않았다. 버전·원인에 따른 분기와 남은 확인 사항은 아래에 명시한다.
Job pod가 Running/Ready 상태인데 실제 워크로드 로그가 멈춘 시점부터, DB(dashboards 등)에서 시작·종료 시각 컬럼이 비어 있는지 확인해 "스케줄은 성공했지만 실제 실행이 멈춘" 패턴인지 구분한다.
노드 간 시간 동기화 상태를 점검한다. Kubernetes 스케줄링, 인증서·토큰 검증, job의 heartbeat/lease 갱신은 노드 시계가 어긋나면 예기치 않게 지연되거나 멈출 수 있다.
chronyc tracking
timedatectl status
시간이 어긋난 노드가 있으면 NTP/chrony 서비스를 재구성하고 시간을 맞춘 뒤, 동일한 job을 반복 실행해 stuck 현상이 재현되는지 관찰한다. CDP 클러스터의 모든 노드는 공식적으로 NTP 서비스 구성이 요구된다.
재발 여부를 판단하기 위해 짧은 간격으로 반복 실행되는 job을 최소 며칠간 관찰한다. 한 번의 정상 실행만으로 재발하지 않는다고 단정하지 않는다.
시간 동기화를 맞춘 이후 동일 job을 여러 차례(스케줄 주기 기준 최소 며칠) 반복 실행해 Running 상태에서 멈추는 현상이 재발하지 않는지 확인한다.