Application이 stopped로 바뀌지만 실행 로그가 없거나 수집 스크립트가 빈 폴더만 생성한다.
원본은 재현 및 최종 해결 확인 없이 종료됐다. 빈 로그는 수집 오류와 실제 로그 부재를 구분해야 한다. 아래 절차는 조사로 보완한 진단·조건부 복구이며 고객 환경에서 실행한 결과가 아니다.
한 번 생성한 경로에 Pod 상태·현재 및 이전 로그를 보존하고, 종료 원인에 맞춰 자원·실행 스크립트·Runtime을 수정한다.
확인 수준: 추가 조사 해법 · 해당 케이스 적용 결과 미확인
적용 조건: <...>와 예시 DB·테이블·경로·수치는 실제 확인값으로 바꾼다. 명령과 메뉴는 참고 문서를 바탕으로 보강한 예시이며 대상 시스템에서 실행하지 않았다. 버전·원인에 따른 분기와 남은 확인 사항은 아래에 명시한다.
ns='<workspace-namespace>'
pod='<application-pod>'
container='<application-container>'
out="app-diagnostics-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$out"
kubectl -n "$ns" get pod "$pod" -o yaml > "$out/pod.yaml" 2> "$out/pod.err"
kubectl -n "$ns" describe pod "$pod" > "$out/describe.txt" 2>&1
kubectl -n "$ns" logs "$pod" -c "$container" --timestamps > "$out/current.log" 2>&1
kubectl -n "$ns" logs "$pod" -c "$container" --previous --timestamps > "$out/previous.log" 2>&1
kubectl -n "$ns" get events --field-selector "involvedObject.name=$pod" --sort-by=.metadata.creationTimestamp > "$out/events.txt" 2>&1
state/lastState, reason, exitCode와 이벤트를 읽는다. OOMKilled와 메모리 한도 도달이 확인되면 데이터·worker 수를 줄이거나 Application 자원 프로필의 메모리를 조정한다. 137이라는 숫자만으로 OOM을 단정하지 않는다. Evicted/노드 장애면 노드와 스토리지를 먼저 복구한다.main.py의 app 객체를 읽는 Python Application script는 다음과 같다.import os
import uvicorn
if __name__ == "__main__":
uvicorn.run("main:app", host="127.0.0.1",
port=int(os.environ["CDSW_APP_PORT"]))
PYTHONUNBUFFERED=1을 적용한다. Jupyter 등 다른 서버가 APP 포트를 점유하면 공식 포트 제한에 맞춰 READONLY 포트 또는 별도 Application으로 분리한다.이전 중단 주기를 넘겨 Application을 관찰하고 HTTP 응답, 상태, 자원 사용량과 로그 수집 파일의 실제 내용을 확인한다.