이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트로 간단한 웹 서비스를 Docker로 컨테이너화하고 Kubernetes로 로컬 클러스터에 배포해봤습니다. 처음에는 Pod가 계속 CrashLoopBackOff 상태가 됐는데, 메모리 리밋을 너무 낮게 설정한 게 원인이었습니다. 리밋을 조정하면서 리소스 요청과 한도를 따로 설정하는 이유를 이해했고, 실제 사용량을 먼저 측정한 뒤에 제한을 거는 방식이 맞다는 걸 배웠습니다.
롤링 업데이트 전략을 써보면서 무중단 배포가 어떻게 동작하는지 확인했고, 헬스체크 설정이 없으면 트래픽이 아직 준비 안 된 Pod로 들어간다는 것도 직접 겪었습니다. Kubernetes는 기능이 많은 만큼 잘못된 설정의 영향도 크다는 걸 그 경험에서 체감했습니다.
Kubernetes를 써보면서 느낀 가장 큰 장점은 롤링 업데이트와 자동 복구를 선언적으로 설정할 수 있다는 점입니다. Pod가 죽으면 자동으로 재시작되고, 배포 중에도 트래픽이 유지되는 구조를 설정으로 만들 수 있다는 것이 처음에 인상적이었습니다. 반면 설정이 많고 추상화 계층이 여러 단계라서 문제가 생겼을 때 원인을 찾기 어렵다는 것이 가장 큰 단점으로 느껴졌습니다. CrashLoopBackOff 상태에서 로그를 보고, 메모리 리밋을 의심하고, 실제로 사용량을 측정해보는 과정이 처음에는 막막했습니다.
기능이 많다는 것은 잘못 설정할 수 있는 것도 많다는 것과 같다는 것을 그때 이해했습니다. Kubernetes가 적합한 상황은 서비스 수가 많고 배포 빈도가 높을 때이고, 단순한 서비스에서는 오버엔지니어링이 될 수 있다는 것도 배웠습니다.
롤링 업데이트를 처음 적용했을 때 헬스체크 설정을 빠뜨렸다가 트래픽이 아직 준비 안 된 Pod로 들어가는 상황을 경험했습니다. 서비스는 올라가 있는 것처럼 보였는데 요청이 간헐적으로 실패했고, 로그를 보니 새 Pod가 초기화 중인 상태에서 트래픽을 받고 있었습니다.
readinessProbe를 추가해서 Pod가 실제로 요청을 받을 준비가 됐을 때만 트래픽이 들어가도록 설정하자 문제가 해결됐습니다. 이 경험을 통해 무중단 배포가 자동으로 보장되는 게 아니라 헬스체크를 정확히 설정해야 의도대로 작동한다는 것을 배웠습니다. Kubernetes는 기능을 제공하지만 올바르게 쓰는 책임은 사용자에게 있다는 것을 그때 가장 실감했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.