{"id":"IL-0094","org":"2i2c","date":"2020-10-28","docs":["https://github.com/2i2c-org/docs/issues/27","https://github.com/2i2c-org/docs/issues/15","https://github.com/2i2c-org/infrastructure/commit/88767d85c306784754560dedc1d5ac7abdb8a2a0","https://github.com/2i2c-org/infrastructure/pull/88","https://github.com/2i2c-org/infrastructure/issues/87","https://github.com/2i2c-org/infrastructure/issues/89","https://github.com/2i2c-org/infrastructure/issues/90","https://github.com/2i2c-org/infrastructure/issues/91","https://github.com/2i2c-org/infrastructure/issues/92"],"title":{"en":"Student pods filled the shared nodes of a JupyterHub cluster and starved the hub's core pods, freezing the hub","ko":"JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다."},"domain":["kubernetes","gcp"],"impact":{"scope":"The WER hub was completely unusable for its students","users":"WER students","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Core pods without resource guarantees get whatever is left on a node, so when user pods on the same nodes fill the CPU and memory, the hub that serves everyone freezes. The memory overcommit ratio has to come from measured use: WER students used just under 1G against a 512M guarantee, which a 4x overcommit could not hold.","ko":"코어 파드와 사용자 파드가 같은 노드에 섞여 있으면 사용자 사용량이 몰릴 때 코어 파드까지 자원을 얻지 못한다. 코어 파드에는 노드가 가득 차도 동작할 만큼의 자원 보장이 있어야 한다. 메모리 오버커밋 비율은 관례대로 정하지 말고 실제 사용량에 맞춰야 한다. WER 학생들은 한도의 상당 부분을 실제로 쓰고 있어서 4배 오버커밋은 지나쳤다."},"related":[],"sources":[{"url":"https://github.com/2i2c-org/incident-reports/blob/main/reports/2020-10-28-memory-overload.md","kind":"github","license":"unknown","archived":null}],"summary":{"en":"2i2c runs a JupyterHub for WER on a GKE cluster. The core pods did not have appropriate resource guarantees, and there was no dedicated pool for them, so the students' pods ran on the same nodes. Each student had a memory limit of 2G and a guarantee of only 512M, the 4x overcommit 2i2c often uses, but earlier tests had shown that students almost always use just under 1G, so the overcommit should have been only 2x. The students filled the CPU and RAM of the nodes, everything was starved of resources, and the hub froze.\n\nThe team removed memory overcommit for the WER students, which was also expected to spawn another node and relieve the existing ones, and raised resource guarantees for all core pods so they could keep working on full nodes. That change restarted the pods and moved some to a new node, and things returned to normal; the issue was closed at 09:46 PM.","ko":"2i2c 가 운영하는 WER 허브에서 학생들이 페이지가 멈춘다고 알려 왔고, 허브는 아무것도 쓸 수 없는 상태였다. 조사해 보니 허브의 코어 파드에 알맞은 자원 보장이 설정되어 있지 않았고, 코어 파드만 도는 전용 노드 풀도 없었다. 자원 보장은 노드가 가득 차도 파드가 확보하는 최소 자원이다. 학생들의 사용량이 노드의 CPU 와 RAM 을 다 써 버리자 모든 파드가 자원을 얻지 못했다.\n\n메모리 설정도 실제 사용량과 맞지 않았다. 팀은 WER 에 필요한 RAM 을 시험한 뒤 학생마다 한도 2G, 보장 512M 으로 늘 하던 대로 4배 오버커밋을 걸어 두었다. 오버커밋은 보장보다 한도를 크게 잡아 노드의 실제 메모리보다 많은 사용을 허용하는 설정이다. 그런데 시험 결과를 보면 학생들은 거의 항상 1G 바로 아래를 썼으므로 오버커밋은 2배였어야 했다. 팀은 학생 파드의 메모리 오버커밋을 없애고 모든 코어 파드의 자원 보장을 올렸다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌고, 상황은 정상으로 돌아왔다. 09:46 PM 에 이슈를 닫았다."},"trigger":{"en":"WER students' pods used a good chunk of their memory limit (tests had shown they almost always use just under 1G of their 2G limit, against a 512M guarantee) on nodes shared with the hub's core pods.","ko":"WER 학생들의 사용량이 늘어 사용자 파드와 코어 파드가 함께 도는 노드의 CPU 와 메모리를 다 썼다."},"severity":"unknown","symptoms":["service-unavailable","node-high-cpu"],"timeline":{"detected_after":null,"resolved_after":"54m"},"date_kind":"incident","detection":{"en":"WER reported stuck pages and students unable to reach the hub in a GitHub issue (2i2c-org/docs#27).","ko":"08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다."},"components":["node-pool","memory-limit"],"root_cause":"capacity","remediation":[{"text":{"en":"removed memory overcommit for the WER students","ko":"09:23 PM 에 WER 학생 파드의 메모리 오버커밋을 없앴다. 학생들이 메모리 한도의 상당 부분을 쓰고 있었고, 새 노드가 하나 더 떠서 기존 노드의 부담을 덜 것으로 보았다."}},{"text":{"en":"raised resource guarantees for all core pods, which restarted them and moved some to a new node","ko":"09:24 PM 에 모든 코어 파드의 자원 보장을 올려 노드가 가득 차도 코어 파드가 동작할 자원을 갖게 했다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌다."}}],"action_items":[{"text":{"en":"Put user pods in a separate pool so they do not create pressure on the core pods (infrastructure#89)","ko":"사용자 파드를 별도 노드 풀로 옮겨 코어 파드에 부담을 주지 않게 한다."}},{"text":{"en":"Set limits on the support infrastructure (Prometheus, Grafana, ingress) as well (infrastructure#90)","ko":"prometheus, grafana, ingress 같은 지원 인프라에도 한도를 건다."}},{"text":{"en":"Document and think about overcommit ratios for memory usage (infrastructure#91)","ko":"메모리 오버커밋 비율을 검토하고 문서로 남긴다."}},{"text":{"en":"Set up better Grafana dashboards to monitor resource usage (infrastructure#92)","ko":"자원 사용량을 감시할 Grafana 대시보드를 더 낫게 만든다."}},{"text":{"en":"Document how people can get kubectl access to the cluster so others can look into issues too (infrastructure#87)","ko":"다른 사람도 문제를 살펴볼 수 있게 클러스터의 kubectl 접근 권한을 얻는 방법을 문서로 남긴다."}}],"contributing":["no-resource-limits","assumption-unverified","blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"At 08:52 PM IST a report came in from WER that many students could not access the JupyterHub and that it was frozen; pages were stuck and nothing was usable. A rise in activity was visible by 09:02 PM, but the usual fixes, such as opening an incognito window and restarting servers, did not help.\n\nAt 09:21 PM the node resource use made the exhaustion clear. kubectl top node showed gke-low-touch-hubs-cluster-core-pool-b7edea69-gwrg at 1944m CPU (100%) and 10432Mi memory (98%), and gke-low-touch-hubs-cluster-core-pool-b7edea69-00sc at 220m (11%) and 6151Mi (58%). The cluster had only core nodes and no separate user nodes, so the suspicion was that the student pods used just enough resources to starve the core pods.","ko":"WER 허브의 학생들이 페이지가 멈춘다고 알려 왔다. 아무것도 쓸 수 없는 완전한 장애였다. 08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.\n\n09:02 PM 에 사용량이 늘어난 것을 알아챘지만, 시크릿 창으로 접속하기나 서버 재시작 같은 평소의 조치로는 나아지지 않았다.\n\n09: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% 였다. 클러스터에는 코어 노드만 있고 사용자 노드가 따로 없었기 때문에, 팀은 사용자 파드가 자원을 차지해 코어 파드가 자원을 얻지 못한다고 의심했다."},"updated_at":"2026-11-10T00:00:32.571163Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0094","org_slug":"2i2c"}