{"id":"IL-0468","org":"UC Berkeley","date":"2017-03-20","docs":["https://github.com/kubernetes/kubernetes/issues/24317","https://github.com/data-8/infrastructure/issues/16","https://github.com/data-8/infrastructure/issues/17"],"title":{"en":"New JupyterHub student pods stuck Pending on MaxVolumeCount after a memory limit cut with node size unchanged","ko":"노드당 볼륨 개수 한도에 걸려 새 학생 서버 파드가 Pending 에 머물고 학생들이 500 오류를 받았다"},"domain":["kubernetes","gcp"],"impact":{"scope":"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","users":"Students starting new servers on the JupyterHub","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://github.com/berkeley-dsep-infra/datahub/blob/staging/docs/incidents/2017-03-20-too-many-volumes.qmd","kind":"github","archived":null}],"summary":{"en":"On 18 March 2017 at 16:30 the memory limit of each student server on UC Berkeley's JupyterHub on Google Container Engine was cut from 2G to 1G to use resources better. The nodes kept their size of 26G RAM, and many of them were cordoned and slowly decommissioned over the following days. As a result, the nodes reached the limit on how many disks Kubernetes would place on one node, and from some time early on 20 March new student pods stayed Pending with the scheduler reason MaxVolumeCount. Google Compute Engine itself handles more than 16 disks per node, which the team had checked, but Kubernetes did not (kubernetes/kubernetes issue 24317).\n\nAt 13:03 the team copied the instance template that Google Container Engine uses, changed the copy to spawn smaller n1-highmem-2 nodes instead of n1-highmem-4, switched the managed instance group to the new template and set it to grow by 30 nodes of about 12 students each. This left students whose servers worked undisturbed. `populate.bash` was run so student pods would start on time on the new nodes, and at 13:04 the simple autoscaler was stopped in case the mixed state of the nodes confused it. By 13:11 the new nodes were online and pods left Pending.\n\nBecause those pods started after JupyterHub's 5-minute timeout, JupyterHub lost track of them and users got 'redirected too many times'; admins stopped and started affected user pods from the control panel as users reported it. At 14:23 the hub and proxy pods were restarted, which fixed most users' state, though some requests still failed with a 599 timeout. Admins kept restarting individual users' pods by hand over the following days.","ko":"2017-03-18 16:30 에 자원을 아끼려고 학생 한 명에게 주는 RAM 을 2G 에서 1G 로 줄였다. 노드 크기는 26G RAM 그대로였고, 기존 노드 여럿은 cordon 해 며칠에 걸쳐 천천히 내리는 중이었다. 2017-03-20 이른 시각부터 13:00 무렵까지 새 학생 서버 일부가 Pending 에 머물러 500 오류를 냈다. 스케줄러는 MaxVolumeCount 때문에 파드를 어느 노드에도 올리지 못했다. Google Compute Engine 은 노드당 16개가 넘는 디스크를 받지만 쿠버네티스는 아직 그러지 못했다. 팀은 이 점을 내다보지 못했다.\n\n13:03 에 Google Container Engine 이 쓰는 인스턴스 템플릿을 복사해 n1-highmem-4 대신 더 작은 n1-highmem-2 노드를 띄우게 고치고, 관리형 인스턴스 그룹이 새 템플릿을 쓰게 했다. 잘 쓰고 있는 학생을 건드리지 않으면서 새 학생이 로그인할 수 있게 하는 가장 쉬운 방법이었다. 인스턴스 그룹을 30노드 늘리고 populate.bash 를 돌렸다. 13:04 에는 노드가 섞인 상태에서 오작동할까 봐 간단한 오토스케일러를 멈췄다. 13:11 에 새 노드가 모두 붙어 파드가 Pending 을 벗어났다.\n\n그러나 이미 JupyterHub 가 파드를 기다리는 5분이 지나 있어서 JupyterHub 는 그 파드들을 알지 못했다. 그래서 'redirected too many times' 오류가 났다. 관리자들은 사용자가 알려 올 때마다 제어판에서 그 사용자의 파드를 멈췄다가 다시 켰다. 14:23 에는 허브와 프록시 파드를 재시작해 대부분의 사용자 상태를 바로잡았다. 일부 요청은 599 타임아웃으로 실패했고, 관리자가 손으로 하는 사용자 재시작은 며칠 더 이어졌다."},"trigger":{"en":"On 18 March at 16:30 the RAM per student was reduced from 2G to 1G to save resources while the nodes kept the same size of 26G RAM, and as a result the nodes hit the Google Cloud the limit on the number of disks per node.","ko":"2017-03-18 16:30 에 자원을 아끼려고 학생 한 명에게 주는 메모리를 2G 에서 1G 로 줄였지만, 노드 크기는 26G RAM 그대로 두었다. 그 결과 Google Cloud 의 노드당 디스크 개수 한도에 닿았다."},"severity":"unknown","symptoms":["pod-pending","high-error-rate"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"New student servers reported a 500 error that kept students from logging in. At 12:44 this was judged widespread, and at 12:53 `kubectl describe pod` showed the pods Pending on MaxVolumeCount.","ko":"12:44 에 새 학생 서버가 500 오류로 로그인을 막는다는 보고가 들어왔고, 팀은 이것이 한 사람의 문제가 아니라 널리 퍼진 장애라고 판단했다."},"components":["memory-limit","block-storage","node-pool"],"root_cause":"capacity","remediation":[{"text":{"en":"Copied the Google Container Engine instance template and changed it to spawn smaller n1-highmem-2 nodes","ko":"Google Container Engine 이 쓰는 인스턴스 템플릿을 복사해 n1-highmem-4 대신 더 작은 n1-highmem-2 노드를 띄우도록 고쳤다."}},{"text":{"en":"Switched the managed instance group to the new template","ko":"Google Container Engine 의 관리형 인스턴스 그룹이 새 템플릿을 쓰게 바꿨다."}},{"text":{"en":"Grew the instance group by 30 new nodes","ko":"새 인스턴스 그룹을 30노드 늘렸다. 노드 하나에 학생 12명쯤이 들어가는 용량이었다."}},{"text":{"en":"Ran populate.bash so student pods would start on time on the new nodes","ko":"populate.bash 를 돌려 새 노드에서 학생 파드가 제때 뜨게 했다."}},{"text":{"en":"Stopped the simple autoscaler","ko":"노드가 섞인 낯선 상태에서 오작동할까 봐 간단한 오토스케일러를 멈췄다."}},{"text":{"en":"Stopped and started affected user pods from the control panel","ko":"'redirected too many times' 오류를 알려 온 사용자마다 관리자가 제어판에서 그 사용자의 파드를 멈췄다가 다시 켰다."}},{"text":{"en":"Restarted the hub and proxy pods","ko":"'redirected too many times' 오류가 많이 나서 허브 파드와 프록시 파드를 재시작했다."}}],"action_items":[{"text":{"en":"Follow the status of kubernetes/kubernetes issue 24317","ko":"이번에 부딪힌 쿠버네티스 버그인 kubernetes/kubernetes 이슈 24317 의 진행을 지켜본다."}},{"text":{"en":"Find and fix the cause of the 'too many redirects' error in JupyterHub","ko":"JupyterHub 의 'too many redirects' 문제를 근원에서 찾아 고친다."}},{"text":{"en":"Delete the older, larger nodes that are no longer in use","ko":"더 이상 쓰지 않는 예전의 큰 노드를 모두 지운다."}},{"text":{"en":"Alert when any pods stay Pending for a non-negligible time","ko":"파드가 Pending 상태로 무시할 수 없을 만큼 오래 머물면 개수와 상관없이 알림을 보낸다."}}],"contributing":["limit-unknown"],"recurrence_of":null,"symptoms_text":{"en":"On 20 March 2017, from some time early in the day until about 13:00, some new student servers on UC Berkeley's JupyterHub stayed in Pending forever and the students got 500 errors that kept them from logging in.\n\nAt 12:44 the 500 errors were judged widespread rather than isolated. At 12:53 `kubectl describe pod` on an affected student's pod showed it Pending with \"pod failed to fit in any node fit failure on node (XX): MaxVolumeCount\", and all new student servers were Pending the same way. A search led to kubernetes/kubernetes issue 24317: Google Compute Engine can handle more than 16 disks per node, which the team had checked before deploying, but Kubernetes itself still could not.\n\nAfter new nodes came online at 13:11 and the pods left Pending, students hit the error 'redirected too many times'. The pods had started later than the 5 minutes JupyterHub waits for a pod before giving up, so JupyterHub did not know they existed and its state no longer matched the cluster. After the hub and proxy pods were restarted at 14:23, some requests still failed with a 599 timeout, less often than in an earlier proxy incident.","ko":"2017-03-20 12:44 에 새 학생 서버가 500 오류를 내며 로그인을 막는다는 보고가 들어왔다. 한 사람의 문제가 아니라 널리 퍼진 증상이었다.\n\n영향받은 학생의 파드를 kubectl describe pod 로 보니 Pending 상태에 머물러 있었고, 오류 메시지는 `pod failed to fit in any node fit failure on node (XX): MaxVolumeCount` 였다. 새 학생 서버 파드가 모두 같은 상태였다.\n\n오류를 검색해 보니 kubernetes/kubernetes 이슈 24317 이 나왔다. Google Compute Engine 은 노드 하나에 디스크를 16개보다 많이 붙일 수 있고, 팀은 배포 전에 이를 확인해 두었다. 그러나 쿠버네티스는 아직 그만큼 붙이지 못했다.\n\n새 노드를 붙여 파드가 Pending 을 벗어났을 때는 JupyterHub 가 파드를 기다리는 5분이 이미 지나 있었다. 그래서 JupyterHub 는 그 파드들을 알지 못했다. 클러스터의 상태와 JupyterHub 의 상태가 어긋나 사용자들은 'redirected too many times' 오류를 받았다. 허브와 프록시를 재시작한 뒤에도 일부 요청은 599 타임아웃으로 실패했다."},"updated_at":"2026-11-14T12:34:11.603617Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0468","org_slug":"uc-berkeley"}