IL-0094 2i2c · 2020-10-28kubernetesgcp

JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.

2i2c 가 운영하는 WER 허브에서 학생들이 페이지가 멈춘다고 알려 왔고, 허브는 아무것도 쓸 수 없는 상태였다. 조사해 보니 허브의 코어 파드에 알맞은 자원 보장이 설정되어 있지 않았고, 코어 파드만 도는 전용 노드 풀도 없었다. 자원 보장은 노드가 가득 차도 파드가 확보하는 최소 자원이다. 학생들의 사용량이 노드의 CPU 와 RAM 을 다 써 버리자 모든 파드가 자원을 얻지 못했다.

메모리 설정도 실제 사용량과 맞지 않았다. 팀은 WER 에 필요한 RAM 을 시험한 뒤 학생마다 한도 2G, 보장 512M 으로 늘 하던 대로 4배 오버커밋을 걸어 두었다. 오버커밋은 보장보다 한도를 크게 잡아 노드의 실제 메모리보다 많은 사용을 허용하는 설정이다. 그런데 시험 결과를 보면 학생들은 거의 항상 1G 바로 아래를 썼으므로 오버커밋은 2배였어야 했다. 팀은 학생 파드의 메모리 오버커밋을 없애고 모든 코어 파드의 자원 보장을 올렸다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌고, 상황은 정상으로 돌아왔다. 09:46 PM 에 이슈를 닫았다.

심각도: –
영향 범위: The WER hub was completely unusable for its students
영향 사용자: WER students
지역: –
감지까지: –
복구까지: 54m

증상

WER 허브의 학생들이 페이지가 멈춘다고 알려 왔다. 아무것도 쓸 수 없는 완전한 장애였다. 08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

09:02 PM 에 사용량이 늘어난 것을 알아챘지만, 시크릿 창으로 접속하기나 서버 재시작 같은 평소의 조치로는 나아지지 않았다.

09:21 PM 에 노드 자원 사용률을 보자 자원 고갈이 분명했다. kubectl top node 출력에서 gke-low-touch-hubs-cluster-core-pool-b7edea69-gwrg 노드는 CPU 1944m 로 100%, 메모리 10432Mi 로 98% 였다. 다른 코어 노드인 gke-low-touch-hubs-cluster-core-pool-b7edea69-00sc 는 CPU 220m 로 11%, 메모리 6151Mi 로 58% 였다. 클러스터에는 코어 노드만 있고 사용자 노드가 따로 없었기 때문에, 팀은 사용자 파드가 자원을 차지해 코어 파드가 자원을 얻지 못한다고 의심했다.

증상 서비스 중단 노드 CPU 고부하

원인

원인 용량 한계

구성 요소 노드 풀 컨테이너 메모리 한도

기여 요인 리소스 요청과 한도 미설정 미검증 가정

감지

08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

조치

09:23 PM 에 WER 학생 파드의 메모리 오버커밋을 없앴다. 학생들이 메모리 한도의 상당 부분을 쓰고 있었고, 새 노드가 하나 더 떠서 기존 노드의 부담을 덜 것으로 보았다.
09:24 PM 에 모든 코어 파드의 자원 보장을 올려 노드가 가득 차도 코어 파드가 동작할 자원을 갖게 했다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌다.

후속 조치

사용자 파드를 별도 노드 풀로 옮겨 코어 파드에 부담을 주지 않게 한다.
prometheus, grafana, ingress 같은 지원 인프라에도 한도를 건다.
메모리 오버커밋 비율을 검토하고 문서로 남긴다.
자원 사용량을 감시할 Grafana 대시보드를 더 낫게 만든다.
다른 사람도 문제를 살펴볼 수 있게 클러스터의 kubectl 접근 권한을 얻는 방법을 문서로 남긴다.

교훈

코어 파드와 사용자 파드가 같은 노드에 섞여 있으면 사용자 사용량이 몰릴 때 코어 파드까지 자원을 얻지 못한다. 코어 파드에는 노드가 가득 차도 동작할 만큼의 자원 보장이 있어야 한다. 메모리 오버커밋 비율은 관례대로 정하지 말고 실제 사용량에 맞춰야 한다. WER 학생들은 한도의 상당 부분을 실제로 쓰고 있어서 4배 오버커밋은 지나쳤다.

출처

https://github.com/2i2c-org/incident-reports/blob/main/reports/2020-10-28-memory-overload.md · github

참고 문서

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

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

kubegap 열기

AI 도구와 스크립트용

이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0094
가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0094/similar
MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

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

증상

원인

감지

조치

후속 조치

교훈

출처

참고 문서

관련 사례

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

AI 도구와 스크립트용