직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 Kubernetes6 Kubernetes ProgressDeadlineExceeded 해결: rollout timeout·readiness·새 Pod 점검 Kubernetes 배포에서 “ProgressDeadlineExceeded”가 표시되거나 kubectl rollout status가 시간 초과로 끝나나요? 먼저 Deployment가 새 버전으로 진행하지 못한 것인지, 명령줄의 대기 제한만 끝난 것인지 구분해야 합니다. 새 Pod의 이벤트·준비 상태·실제 가용 복제본을 읽으면 이미지 문제, 스케줄링, readiness, 자원 제한을 분리할 수 있습니다. 제한 시간을 무작정 늘리기 전에 멈춘 단계를 확인하세요.1. 명령의 --timeout과 Deployment 진행 제한은 다릅니다kubectl rollout status 안내의 --timeout은 상태 확인 명령이 얼마나 기다릴지를 정합니다. Deployment의 spec.progressDeadlineSec.. 2026. 10. 7. Kubernetes Service 연결 안 될 때: selector·EndpointSlice·targetPort·DNS 점검 Pod는 Running인데 Kubernetes Service로 접속하면 연결이 거부되거나 시간이 초과되나요? Service의 selector, EndpointSlice, 애플리케이션이 실제로 듣는 포트, DNS와 네트워크 정책을 순서대로 확인하면 원인을 좁힐 수 있습니다. 이 글은 selector로 Pod를 선택하는 일반적인 ClusterIP Service를 기준으로 설명합니다. ExternalName이나 selector가 없는 Service는 엔드포인트를 다루는 방식이 다르므로 같은 절차를 그대로 적용하지 마세요.1. 어느 클러스터·네임스페이스·주소에 접속하는지 확인먼저 현재 context와 Service의 네임스페이스를 확인합니다. 동일한 이름의 Service가 다른 네임스페이스에 있으면 짧은 이름으.. 2026. 10. 5. Kubernetes OOMKilled 해결: 메모리 limit·request·노드 압박 점검 순서 Kubernetes Pod가 반복 재시작되고 상태에 OOMKilled가 보인다면 먼저 '어느 컨테이너가 언제 왜 종료됐는지'를 확인하세요. 메모리 한도를 바로 올리면 잠시 안정될 수 있지만 누수, 동시 요청 증가, 메모리 기반 임시 볼륨 사용 같은 원인을 놓칠 수 있습니다. 이 글은 읽기 전용 명령으로 증거를 모으고, 애플리케이션 사용량과 클러스터 용량을 함께 고려해 수정하는 순서를 설명합니다.1. 종료 원인을 먼저 확정하세요Pod 이름·네임스페이스·컨테이너 이름을 실제 값으로 바꿔 다음 명령을 실행합니다. describe의 Last State, Reason, Exit Code, Events를 읽고 이전 컨테이너 로그를 보관하세요. 여러 컨테이너가 있는 Pod라면 문제가 난 컨테이너를 정확히 지정해야 합.. 2026. 9. 30. Kubernetes Pod Pending 해결: 자원 부족·taint·PVC·스케줄링 점검 Kubernetes Pod가 Pending에 머무르면 이미지를 다시 빌드하기 전에 스케줄러가 노드를 배정했는지부터 보세요. Pending은 노드 배정을 기다릴 때뿐 아니라 컨테이너 설정이나 이미지 다운로드를 기다리는 단계에도 나타날 수 있습니다. FailedScheduling 이벤트와 Pod의 Node 값이 원인 분기의 출발점입니다.1. 먼저 이벤트와 Node 배정 여부를 확인하세요아래 예시는 읽기 전용 조회입니다. app은 실제 네임스페이스로, my-pod는 실제 Pod 이름으로 바꾸세요.kubectl get pod my-pod -n app -o widekubectl describe pod my-pod -n appkubectl get events -n app --sort-by=.lastTimestamp.. 2026. 9. 29. Kubernetes ImagePullBackOff 해결: 이미지 태그·imagePullSecrets·네트워크 점검 Kubernetes Pod가 ImagePullBackOff에 머물면 애플리케이션 로그부터 찾기보다 Pod의 이벤트를 먼저 확인하세요. 이미지를 내려받지 못해 컨테이너가 시작되지 않은 상태일 수 있습니다. 이미지 주소·태그, 인증정보와 네임스페이스, 노드의 네트워크·TLS·지원 아키텍처를 순서대로 좁히면 불필요한 재배포를 줄일 수 있습니다.1. ImagePullBackOff와 실행 뒤 장애 구분하기Kubernetes 이미지 공식 문서는 ImagePullBackOff를 이미지 다운로드 실패 후 간격을 늘려 재시도하는 상태로 설명합니다. 상태 이름 자체가 근본 원인은 아닙니다. 이벤트에 적힌 상세 오류를 읽어야 합니다. 다운로드가 끝난 뒤 프로세스가 반복 종료되는 CrashLoopBackOff와도 구분하세요... 2026. 9. 28. 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 다음
