이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Linux와 Kubernetes 환경에서 기억에 남는 트러블슈팅은 파드가 재시작을 반복하는 문제를 해결했을 때입니다. kubectl logs로 로그를 확인했지만 이미 종료된 파드라 이전 로그가 남아있지 않아, --previous 플래그로 마지막 실행 로그를 가져오는 방법을 알게 됐습니다.
환경변수 누락이 원인이었는데, ConfigMap이 올바르게 마운트됐는지 확인하는 과정에서 kubectl describe pod로 이벤트 로그를 보는 방법을 배웠습니다. Linux에서는 메모리 부족으로 프로세스가 강제 종료되는 경우를 경험했는데, dmesg로 커널 로그를 확인해 원인을 찾았습니다. 리소스 limit과 request 설정이 없으면 파드가 노드의 메모리를 과다하게 사용할 수 있다는 것도 이 경험에서 배웠습니다. 쿠버네티스 트러블슈팅은 로그→이벤트→리소스 상태 순서로 좁혀가는 것이 결임을 배웠습니다.
Kubernetes 클러스터에서 특정 네임스페이스 간 파드 통신이 갑자기 차단되는 장애가 발생했습니다. kubectl logs와 kubectl describe pod로는 에러가 보이지 않았고, 네트워크 레이어 문제임을 의심해 NetworkPolicy 설정을 확인했습니다. 신규 보안 정책 배포 시 egress 규칙이 의도치 않게 기존 서비스 간 통신을 차단하고 있었습니다.
kubectl exec로 파드 내부에서 curl을 직접 테스트해 차단 방향을 특정하고, NetworkPolicy의 podSelector와 namespaceSelector를 수정해 해결했습니다. 이 경험에서 Kubernetes 트러블슈팅은 애플리케이션 레이어보다 네트워크와 정책 레이어를 먼저 의심하는 순서가 중요함을 배웠습니다.
운영 중 서비스 파드가 아무 에러 없이 간헐적으로 종료되는 현상이 반복됐습니다. kubectl logs에는 아무 기록이 없었고, kubectl describe pod에서 OOMKilled 이유를 발견했습니다. Linux dmesg 로그를 확인하니 OOM Killer가 메모리 부족 시 해당 파드를 선택해 종료하고 있었습니다. 파드의 resources.limits.memory 설정이 실제 사용량보다 낮게 설정돼 있던 것이 원인이었고, Prometheus의 메모리 사용 메트릭을 분석해 적절한 limit 값으로 조정했습니다. 이후 OOMKilled 빈도가 0으로 감소했고, 리소스 설정을 정기적으로 검토하는 운영 루틴도 팀에 도입했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.