직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 oomkilled2 Kubernetes OOMKilled 해결: 메모리 limit·request·노드 압박 점검 순서 Kubernetes Pod가 반복 재시작되고 상태에 OOMKilled가 보인다면 먼저 '어느 컨테이너가 언제 왜 종료됐는지'를 확인하세요. 메모리 한도를 바로 올리면 잠시 안정될 수 있지만 누수, 동시 요청 증가, 메모리 기반 임시 볼륨 사용 같은 원인을 놓칠 수 있습니다. 이 글은 읽기 전용 명령으로 증거를 모으고, 애플리케이션 사용량과 클러스터 용량을 함께 고려해 수정하는 순서를 설명합니다.1. 종료 원인을 먼저 확정하세요Pod 이름·네임스페이스·컨테이너 이름을 실제 값으로 바꿔 다음 명령을 실행합니다. describe의 Last State, Reason, Exit Code, Events를 읽고 이전 컨테이너 로그를 보관하세요. 여러 컨테이너가 있는 Pod라면 문제가 난 컨테이너를 정확히 지정해야 합.. 2026. 9. 30. Kubernetes CrashLoopBackOff 해결 순서: 이전 로그·종료 코드·프로브·메모리 점검 그림: 반복 재시작은 이전 실행의 종료 이유부터 확인하세요.CrashLoopBackOff는 컨테이너가 반복 종료되어 Kubernetes가 재시작 사이 대기 시간을 늘리는 상태입니다. 하나의 원인 이름이 아닙니다. 이전 실행의 로그, 종료 이유, 이벤트를 모아야 재시작 루프를 고칠 수 있습니다.1. 파드와 실패 컨테이너를 특정한다kubectl get pods -n NAMESPACEkubectl describe pod POD_NAME -n NAMESPACEkubectl logs POD_NAME -c CONTAINER_NAME -n NAMESPACE --previous--previous는 이전에 종료된 컨테이너 로그를 보여줍니다. 여러 컨테이너가 있으면 -c로 대상을 지정하세요. describe의 Last S.. 2026. 9. 25. 이전 1 다음
