이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴십 중 EKS 클러스터 운영 보조 역할을 맡아, 파드 재시작 이슈와 리소스 설정 최적화 작업을 담당했습니다. 처음에는 kubectl 명령으로 이벤트 로그를 보며 OOMKilled 패턴을 추적하는 것부터 시작했는데, 메모리 제한이 실제 사용량보다 너무 빡빡하게 잡혀 있었습니다. 각 서비스별 실측 메모리 사용 그래프를 뽑아 requests와 limits 값을 서비스 특성에 맞게 조정했고, 이후 비정상 재시작 빈도가 눈에 띄게 줄었습니다. 클러스터 운영에서 느낀 건, 설정 파일 한 줄이 전체 서비스 안정성에 직결된다는 점이었고, 이 경험이 인프라 설정을 코드 리뷰 수준으로 꼼꼼히 보게 된 계기가 됐습니다.
EKS 운영 중 파드가 Pending 상태에서 벗어나지 않는 문제를 마주했습니다. kubectl describe로 이벤트를 확인했지만 Insufficient CPU 메시지와 실제 노드 여유량 사이가 맞지 않아 혼자 해결하지 못했습니다. 선임 엔지니어에게 상황을 공유했더니, 노드 리소스 중 일부가 시스템 파드에 예약돼 있어 실제 사용 가능 CPU가 생각보다 작다는 것을 알려줬습니다. Node Allocatable 값과 실제 사용량을 비교하는 방법을 배우고 나서 문제를 빠르게 해결했습니다. 이 경험으로 쿠버네티스 리소스 예약 구조를 제대로 이해하지 못하면 용량 계획에서 착오가 생긴다는 것을 배웠고, 선임에게 먼저 물어보는 것이 삽질 시간을 크게 줄인다는 것도 실감했습니다. 이후에는 새 클러스터를 구성할 때 Node Allocatable을 먼저 확인하는 습관이 생겼습니다.
OOMKilled 이슈를 해결하고 나서, 같은 문제가 새 서비스를 추가할 때마다 반복되지 않도록 절차로 남기는 것이 중요하다고 생각했습니다. 서비스별 실측 메모리 그래프와 설정 기준을 정리해 팀 위키에 기록했습니다. requests는 평균 사용량의 1.2배, limits는 피크의 1.5배를 기준으로 설정하는 가이드라인을 만들었고, 새 파드 배포 시 이 기준을 리뷰 체크리스트에 넣었습니다.
HorizontalPodAutoscaler 설정도 함께 정리해 부하가 몰릴 때 파드를 자동으로 늘리는 구조를 표준으로 잡았습니다. 이후 새 서비스를 추가한 팀원이 가이드를 보고 스스로 설정한 경우가 생겼고, 리뷰에서 메모리 설정 관련 지적이 줄었습니다.
한 번 겪은 장애에서 배운 것이 팀 전체의 기준이 되는 과정이 인프라 운영의 핵심이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.