Incident Library

IL-0468 UC Berkeley · 2017-03-20kubernetesgcp

노드당 볼륨 개수 한도에 걸려 새 학생 서버 파드가 Pending 에 머물고 학생들이 500 오류를 받았다

2017-03-18 16:30 에 자원을 아끼려고 학생 한 명에게 주는 RAM 을 2G 에서 1G 로 줄였다. 노드 크기는 26G RAM 그대로였고, 기존 노드 여럿은 cordon 해 며칠에 걸쳐 천천히 내리는 중이었다. 2017-03-20 이른 시각부터 13:00 무렵까지 새 학생 서버 일부가 Pending 에 머물러 500 오류를 냈다. 스케줄러는 MaxVolumeCount 때문에 파드를 어느 노드에도 올리지 못했다. Google Compute Engine 은 노드당 16개가 넘는 디스크를 받지만 쿠버네티스는 아직 그러지 못했다. 팀은 이 점을 내다보지 못했다.

13:03 에 Google Container Engine 이 쓰는 인스턴스 템플릿을 복사해 n1-highmem-4 대신 더 작은 n1-highmem-2 노드를 띄우게 고치고, 관리형 인스턴스 그룹이 새 템플릿을 쓰게 했다. 잘 쓰고 있는 학생을 건드리지 않으면서 새 학생이 로그인할 수 있게 하는 가장 쉬운 방법이었다. 인스턴스 그룹을 30노드 늘리고 populate.bash 를 돌렸다. 13:04 에는 노드가 섞인 상태에서 오작동할까 봐 간단한 오토스케일러를 멈췄다. 13:11 에 새 노드가 모두 붙어 파드가 Pending 을 벗어났다.

그러나 이미 JupyterHub 가 파드를 기다리는 5분이 지나 있어서 JupyterHub 는 그 파드들을 알지 못했다. 그래서 'redirected too many times' 오류가 났다. 관리자들은 사용자가 알려 올 때마다 제어판에서 그 사용자의 파드를 멈췄다가 다시 켰다. 14:23 에는 허브와 프록시 파드를 재시작해 대부분의 사용자 상태를 바로잡았다. 일부 요청은 599 타임아웃으로 실패했고, 관리자가 손으로 하는 사용자 재시작은 며칠 더 이어졌다.

심각도
–
영향 범위
Some new student servers on the JupyterHub could not start and returned 500 errors from early on 20 March 2017 until about 13:00, followed by 'redirected too many times' errors, some 599 timeouts and manual restarts over the following days
영향 사용자
Students starting new servers on the JupyterHub
지역
–
감지까지
–
복구까지
–

증상

2017-03-20 12:44 에 새 학생 서버가 500 오류를 내며 로그인을 막는다는 보고가 들어왔다. 한 사람의 문제가 아니라 널리 퍼진 증상이었다.

영향받은 학생의 파드를 kubectl describe pod 로 보니 Pending 상태에 머물러 있었고, 오류 메시지는 `pod failed to fit in any node fit failure on node (XX): MaxVolumeCount` 였다. 새 학생 서버 파드가 모두 같은 상태였다.

오류를 검색해 보니 kubernetes/kubernetes 이슈 24317 이 나왔다. Google Compute Engine 은 노드 하나에 디스크를 16개보다 많이 붙일 수 있고, 팀은 배포 전에 이를 확인해 두었다. 그러나 쿠버네티스는 아직 그만큼 붙이지 못했다.

새 노드를 붙여 파드가 Pending 을 벗어났을 때는 JupyterHub 가 파드를 기다리는 5분이 이미 지나 있었다. 그래서 JupyterHub 는 그 파드들을 알지 못했다. 클러스터의 상태와 JupyterHub 의 상태가 어긋나 사용자들은 'redirected too many times' 오류를 받았다. 허브와 프록시를 재시작한 뒤에도 일부 요청은 599 타임아웃으로 실패했다.

증상 파드 Pending오류율 상승

원인

원인 용량 한계

구성 요소 컨테이너 메모리 한도클라우드 블록 스토리지노드 풀
기여 요인 한계 미인지
촉발
2017-03-18 16:30 에 자원을 아끼려고 학생 한 명에게 주는 메모리를 2G 에서 1G 로 줄였지만, 노드 크기는 26G RAM 그대로 두었다. 그 결과 Google Cloud 의 노드당 디스크 개수 한도에 닿았다.

감지

12:44 에 새 학생 서버가 500 오류로 로그인을 막는다는 보고가 들어왔고, 팀은 이것이 한 사람의 문제가 아니라 널리 퍼진 장애라고 판단했다.

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 컨테이너 메모리 한도, 클라우드 블록 스토리지, 노드 풀. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.