예시 답변 1
약 90초
Kubernetes 파드 장애 원인 추적 결
Linux와 Kubernetes 환경에서 기억에 남는 트러블슈팅은 파드가 재시작을 반복하는 문제를 해결했을 때입니다. kubectl logs로 로그를 확인했지만 이미 종료된 파드라 이전 로그가 남아있지 않아, --previous 플래그로 마지막 실행 로그를 가져오는 방법을 알게 됐습니다.
환경변수 누락이 원인이었는데, ConfigMap이 올바르게 마운트됐는지 확인하는 과정에서 kubectl describe pod로 이벤트 로그를 보는 방법을 배웠습니다. Linux에서는 메모리 부족으로 프로세스가 강제 종료되는 경우를 경험했는데, dmesg로 커널 로그를 확인해 원인을 찾았습니다. 리소스 limit과 request 설정이 없으면 파드가 노드의 메모리를 과다하게 사용할 수 있다는 것도 이 경험에서 배웠습니다. 쿠버네티스 트러블슈팅은 로그→이벤트→리소스 상태 순서로 좁혀가는 것이 결임을 배웠습니다.
이 결의 특징
파드 재시작 반복 문제를 --previous 로그와 describe pod 이벤트로 좁히고, dmesg로 메모리 부족 강제 종료를 확인한 흔적이 있습니다.
이 결이 통하는 자리
로그에서 이벤트, 리소스 상태 순서로 좁혀가는 방식이 실제 원인 추적 절차로 뒷받침될 때 통합니다.