이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Kubernetes 클러스터에 Pod를 배포했는데, 특정 노드에서만 `Pending` 상태에 멈추는 현상이 생겼습니다. kubectl describe pod로 확인해보니 리소스 요청량이 노드 여유 용량을 초과하는 메시지가 있었습니다. 그런데 kubectl top nodes로 보면 해당 노드에 여유가 있어 보였습니다. 알고 보니 `requests`와 `limits` 설정 차이 때문이었습니다. 실제 사용량이 아니라 requests로 선언한 값으로 스케줄링 판단을 한다는 걸, 그때 처음으로 내부 구조로 이해하게 됐습니다. 이후로는 requests와 limits를 명시적으로 분리해서 설정하는 습관이 생겼습니다.
인턴 프로젝트에서 배포 직후 `CrashLoopBackOff` 상태가 반복됐습니다. 로그를 보니 OOMKilled 메시지가 있었고, 메모리 `limits`가 실제 사용량보다 너무 낮게 설정된 게 원인이었습니다. 처음에는 코드 문제라고 생각해서 앱 코드를 먼저 뒤졌는데, kubectl describe pod로 이벤트 로그를 보고 나서야 인프라 설정 문제라는 걸 파악했습니다.
limits를 수정하고 재배포했더니 바로 해결됐습니다. 이 경험에서 Kubernetes 트러블슈팅의 출발점은 항상 이벤트 로그라는 걸 배웠고, 이후에는 코드보다 인프라 설정을 먼저 확인하는 순서가 생겼습니다.
사이드 프로젝트에서 롤링 업데이트 중에 일부 요청이 실패하는 현상이 있었습니다. 새 버전 Pod가 뜨자마자 트래픽을 받기 시작했는데, 앱 초기화가 완료되기 전이었습니다. readinessProbe를 설정하지 않은 게 원인이었습니다. readinessProbe가 `Pod`가 실제로 요청을 처리할 준비가 됐을 때만 트래픽을 받도록 제어한다는 걸 그때 이해했습니다.
HTTP 헬스체크 엔드포인트를 만들고 readinessProbe를 연결하니 배포 중 에러가 사라졌습니다. Kubernetes의 `probe` 설계가 왜 있는지를 장애를 겪고 나서야 체감으로 알게 됐습니다. 이후로는 배포 체크리스트에 헬스체크 설정 확인을 항상 포함시키고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.