{"id":"IL-0507","org":"UC Berkeley","date":"2017-10-10","docs":[],"title":{"en":"Student pods on UC Berkeley DataHub got stuck in Terminating or would not start because Docker hung on two Azure nodes","ko":"Azure 쿠버네티스 노드 두 대에서 Docker 데몬이 멈춰 학생 파드가 시작되거나 종료되지 않았다"},"domain":["kubernetes","azure"],"impact":{"scope":"UC Berkeley DataHub: student servers whose pods ran on two nodes could not start or stop","users":"students whose pods were placed on the two nodes","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-10-10-hung-nodes.qmd","kind":"github","archived":null}],"summary":{"en":"On 10 October 2017 some DataHub user pods did not start or terminate correctly. All affected pods ran on two nodes, k8s-pool1-19522833-13 and k8s-pool2-19522833-9, where the Docker daemon had hung and did not respond, so pods on those nodes could neither start nor stop. On k8s-pool1-19522833-13 the hypercube process was at 766% CPU, while it was normal on the other node. The write-up concludes that Docker hung on the two nodes and does not say why; at 17:25 the team noticed that /var/lib/docker on k8s-pool1-19522833-13 was on the root disk (sda) rather than on /mnt (sdb).\n\nThe stuck pods were force-deleted with `kubectl --namespace=prod delete pod jupyter-<name> --grace-period=0 --force` and both nodes were cordoned, after which the students' servers started. k8s-pool1-19522833-13 came back with a responsive Docker only after it was stopped and then started from the Azure portal at 14:30, and it was uncordoned; k8s-pool2-19522833-9 was stopped from the Azure portal at 14:30 and started again there once it had finished stopping at 14:45. A third node, pool1-...-14, cordoned on an earlier day, was rebooted, came back online and was uncordoned.","ko":"2017년 10월 10일 UC Berkeley DataHub 의 Azure 쿠버네티스 클러스터에서 일부 학생 파드가 제대로 시작되거나 종료되지 않았다. 영향받은 파드는 모두 k8s-pool1-19522833-13 과 k8s-pool2-19522833-9 두 노드에서 돌고 있었고, 두 노드 모두 Docker 데몬이 응답하지 않았다. 보고서는 두 노드에서 Docker 가 멈춰 파드가 제대로 시작되거나 멈추지 못했다고 결론지었다.\n\n오전 10:45 에 학생 두 명의 서버가 시작되지 않는다는 신고가 왔고, 12:29 에 Terminating 에 멈춘 파드를 --grace-period=0 --force 로 강제로 지우자 서버가 시작됐다. 13:27 에 다른 학생의 신고를 살피다가 그 파드가 돌던 노드 pool1-...-13 에 Terminating 파드가 많고 docker ps 가 멈춘 것을 찾아 노드를 cordon 했다. 클러스터 전체를 살펴 pool2-...-9 도 같은 상태인 것을 찾았고, 그 노드의 파드를 강제로 지우고 cordon 했다. 다른 날 cordon 해 둔 pool1-...-14 는 재부팅하자 돌아와 uncordon 했다.\n\npool1-...-13 은 셸 재부팅과 Azure 포털 재시작으로도 돌아오지 않았다. 14:30 에 Azure 포털에서 이 노드를 멈췄다가 다시 시작하자 Docker 가 다시 응답했고, 운영팀은 노드를 uncordon 했다. pool2-...-9 도 Azure 포털에서 멈춘 뒤 14:45 에 다시 시작했다. 17:25 에 pool1-19522833-13 의 /var/lib/docker 가 /mnt 의 sdb 가 아니라 / 의 sda 에 있는 것을 발견했다."},"trigger":null,"severity":"unknown","symptoms":["pod-stuck-terminating"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Students reported on the course Piazza at 10:45 AM, and later in the course Slack, that their servers would not start.","ko":"학생들이 강의 Piazza 와 강의 slack 에 서버가 시작되지 않는다고 알렸다."},"components":["container-runtime"],"root_cause":"unknown","remediation":[{"text":{"en":"Force-deleted the stuck user pods with kubectl --namespace=prod delete pod jupyter-<name> --grace-period=0 --force","ko":"Terminating 에 멈춘 사용자 파드를 kubectl --namespace=prod delete pod jupyter-<name> --grace-period=0 --force 로 강제로 지웠다. 그 뒤 /hub/admin 에서 서버가 제대로 시작됐다."}},{"text":{"en":"Cordoned node k8s-pool1-19522833-13","ko":"docker ps 가 멈춘 노드 k8s-pool1-19522833-13 을 cordon 했다."}},{"text":{"en":"Force-deleted the stuck pods on k8s-pool2-19522833-9 and cordoned that node","ko":"같은 상태인 k8s-pool2-19522833-9 에서 멈춘 파드를 모두 강제로 지우고 그 노드도 cordon 했다."}},{"text":{"en":"Stopped and started k8s-pool1-19522833-13 from the Azure portal, after which Docker responded, and uncordoned it","ko":"pool1-...-13 을 Azure 포털에서 손으로 멈췄다가 다시 시작했다. 노드가 돌아와 Docker 가 응답하자 uncordon 했다."}},{"text":{"en":"Stopped and started k8s-pool2-19522833-9 from the Azure portal","ko":"pool2-...-9 가 완전히 멈춘 뒤 Azure 포털에서 손으로 다시 시작했다."}}],"action_items":[{"text":{"en":"When several student servers fail to start or stop, check whether their pods ran on the same nodes","ko":"학생 서버가 시작되거나 멈추지 않는다는 신고가 여러 건 오면 그 사용자 파드들이 같은 노드에서 돌았는지 확인한다."}},{"text":{"en":"Find out how many nodes do not mount /var/lib/docker on sdb1","ko":"/var/lib/docker 를 sdb1 에 마운트하지 않은 노드가 몇 대인지 알아본다."}},{"text":{"en":"Watch for elevated counts of pods stuck in Terminating","ko":"Terminating 에 멈춘 파드 수가 늘어나는지 지켜본다. 예를 들어 kubectl --namespace=prod get pod -o wide| grep Terminating 으로 본다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"On 10 October 2017 at 10:45 AM, a post on the course Piazza reported that two students could not start their servers on UC Berkeley's DataHub, and the /hub/admin interface could not start them either. At first it was thought the students might have run out of memory.\n\nThe students' pods were stuck in Terminating and did not respond to an explicit delete. After another report in the course Slack at 13:27, an operator saw that node k8s-pool1-19522833-13 also hosted many more pods stuck in Terminating and that `docker ps` hung on it; a check of the whole cluster for nodes with an unusual number of Terminating pods found k8s-pool2-19522833-9 in the same state. The two nodes had loads of 476 and 530.\n\nOn k8s-pool2-19522833-9, `systemctl status docker` showed errors such as \"containerd: container did not start before the specified timeout\", \"Create container failed with error: containerd: container did not start before the specified timeout\" and \"write unix /var/run/docker.sock->@: write: broken pipe\", and `ps aux | grep exe | wc -l` counted 520 matching processes, the first of them `/proc/self/exe init` in state Dsl. Rebooting k8s-pool1-19522833-13 from the shell, and then restarting it from the Azure portal, did not bring it back online.","ko":"학생 두 명이 서버를 시작할 수 없다고 강의 Piazza 에 알렸고, /hub/admin 화면에서도 서버가 시작되지 않았다. 처음에는 학생들이 메모리를 다 썼을 수 있다는 말이 나왔다.\n\n사용자 파드는 Terminating 상태에 멈춰 일반 삭제에 응하지 않았다. 영향받은 파드는 모두 특정 노드 두 대에서 돌고 있었고, 그 노드에는 Terminating 에 멈춘 파드가 그 밖에도 많았다.\n\n두 노드에서 docker ps 가 멈췄다. pool2-...-9 의 load average 는 530, pool1-...-13 은 476 이었고, pool1-...-13 에서는 hypercube 가 CPU 766% 를 쓰고 있었다.\n\npool2-...-9 의 systemctl status docker 에는 level=error msg=\"containerd: start container\" error=\"containerd: container did not start before the specified timeout\" 와 Create container failed with error: containerd: container did not start before the specified timeout 이 되풀이됐다. 그 뒤로 Handler for GET /v1.24/containers/json returned error: write unix /var/run/docker.sock->@: write: broken pipe, http: multiple response.WriteHeader calls, No such container 가 이어졌다.\n\n같은 노드에서 ps aux | grep exe | wc -l 의 결과는 520 이었고, 프로세스는 Dsl 상태의 /proc/self/exe init 였다.\n\npool1-...-13 은 셸에서 재부팅해도, Azure 포털에서 재시작해도 돌아오지 않았다."},"updated_at":"2026-11-14T12:34:15.191926Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0507","org_slug":"uc-berkeley"}