이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 쿠버네티스 롤링 업데이트 배포 중 기존 파드가 종료되기 전에 신규 파드가 아직 준비 안 됐는데 트래픽을 받아서 500 에러가 30초간 발생하는 사고가 있었습니다.
원인은 readinessProbe 설정이 없었던 것이었습니다. 신규 파드가 헬스체크를 통과하기 전에 트래픽이 라우팅됐습니다. readinessProbe를 추가하고 initialDelaySeconds를 실제 스타트업 시간에 맞게 설정하니 이후 배포에서 중단 없이 전환됐습니다.
쿠버네티스 설정 하나를 빠뜨리는 게 사용자 경험에 바로 영향을 준다는 걸 그때 처음 체감했습니다. 배포 시 가장 중요한 건 파드 준비 상태를 정확하게 정의하는 것이라는 게 지금도 제 첫 번째 점검 항목입니다.
인턴 때 동일 클러스터에 여러 서비스가 배포된 환경에서 특정 배치 서비스가 메모리를 급격히 소모하면서 같은 노드의 다른 서비스 파드들이 OOM으로 강제 종료되는 사고가 있었습니다.
배치 서비스에 메모리 limit이 설정되지 않아 노드 전체 메모리를 점유한 것이었습니다. resources.limits.memory를 명시하고 노드 어피니티로 배치 서비스를 별도 노드 그룹으로 격리했습니다.
클러스터 공유 환경에서 리소스 limit을 안 쓰는 건 '내 코드가 남의 서비스를 죽일 수 있다'는 것이라는 걸 그때 배웠습니다. 이후 새 서비스를 배포할 때 리소스 request와 limit 설정이 배포 체크리스트의 첫 번째 항목이 됐습니다.
사이드 프로젝트에서 파드 3개로 분산된 서비스에서 간헐적 에러가 났는데, 어느 파드에서 난 건지 kubectl logs를 파드마다 수동으로 보느라 원인 파악에 20분이 걸렸습니다.
중앙 로그 수집 설정을 추가해 모든 파드 로그를 한 곳에서 볼 수 있게 했습니다. 로그에 파드 이름을 태그로 포함하니 어느 인스턴스에서 문제가 났는지 바로 찾을 수 있었습니다. 같은 에러가 다음에 났을 때 원인 파악이 2분으로 줄었습니다.
쿠버네티스 운영에서 *가시성을 처음부터 갖추지 않으면 장애 때 고생이 몇 배라는 걸 배웠습니다. 배포 전에 '이 서비스에서 문제가 나면 어디서 어떻게 찾을 것인가'를 먼저 생각하는 습관이 그때 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.