{"id":"IL-0402","org":"Binder Project","date":"2018-03-13","docs":["https://github.com/jupyterhub/mybinder.org-deploy/issues/365","https://github.com/jupyterhub/mybinder.org-deploy/pull/512"],"title":{"en":"mybinder.org launches dropped to zero for hours because a JupyterHub pod on a lost GKE node kept its hub database PVC","ko":"GKE 노드가 고장 나 NodeLost 가 된 JupyterHub 파드가 hub DB 의 PVC 를 놓지 않아 mybinder.org 가 몇 시간 동안 새 사용자를 받지 못했다"},"domain":["kubernetes","gcp"],"impact":{"scope":"mybinder.org could not launch any sessions for several hours; other services whose pods were on the failed nodes were down until 13:34","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The error went unnoticed for a long time because Stackdriver alert emails were marked as spam and arrived hours late. Once the problem was found, each step was logged and the steps were made more forceful as needed, so the hub was down only briefly after detection.","ko":"문제를 찾은 뒤에는 조치를 잘 기록했고, 필요에 따라 더 강한 조치로 빠르게 넘어가서 hub 가 멈춘 시간은 짧았다. 오류를 알아채기까지는 꽤 오래 걸렸다. Stackdriver 메일이 오지 않았는데, Stackdriver 메일은 스팸으로 분류되고 알림이 몇 시간 뒤에야 도착했다."},"related":[],"sources":[{"url":"https://github.com/jupyterhub/mybinder.org-deploy/blob/main/docs/source/incident-reports/2018-03-13-PVC-hub-locked.md","kind":"github","archived":null}],"summary":{"en":"Some GKE nodes of the mybinder.org cluster went bad, and the JupyterHub pod was on one of them. The pod was not deleted properly, so it never released the PVC that held the hub database, and new hub pods could not get the database, which stopped all launches. The team only noticed after several hours, because the Stackdriver alert emails went to spam and arrived hours late. After cordoning the bad nodes and deleting pods did not release the PVC, the team reset node `gke-prod-a-ssd-pool-32-134a959a-n2sk` from the GCP web interface. At 08:05 a new hub pod was scheduled on another node, pulled its image and started, and launches worked again.\n\nPods in \"Unknown\" or \"NodeLost\" state could not be removed with a normal delete. At 13:34 the team found that `kubectl --namespace=prod delete pod <pod-name> --grace-period=0 --force` removes them, ran it in a script for every such pod in the prod namespace, and the remaining services recovered. Why the nodes failed was left open for investigation.","ko":"2018년 3월 13일 mybinder.org 의 JupyterHub 가 몇 시간 동안 새 사용자를 받지 못했다. 일부 GKE 노드가 고장 났고, JupyterHub 파드가 그런 노드에 있었는데 제대로 지워지지 않았다. 파드가 정리되지 않아 hub DB 가 든 PVC 를 놓지 못했고, 새 hub 파드는 DB 에 접근하지 못했다. 장애가 왜 시작됐는지는 조사할 일로 남았다.\n\n07:28 에 문제를 알아챈 팀은 나쁜 노드를 cordon 하고 hub 파드 둘을 지웠다. 새 hub 파드가 PVC 때문에 뜨지 못하자 07:59 에 노드 gke-prod-a-ssd-pool-32-134a959a-n2sk 의 파드를 모두 지웠고, 효과가 없자 GCP 웹 화면에서 그 노드를 reset 했다. 08:05 에 hub-65d9f46698-454cf 가 gke-prod-a-ssd-pool-32-134a959a-1j33 에 떠 서비스가 다시 돌았다. Unknown 상태 파드는 보통의 삭제로는 지워지지 않았다. 팀은 Kubernetes 가 그 파드의 상태를 전혀 알 수 없기 때문이라고 봤다. 13:32 에 팀은 실패한 노드에 있던 파드에서 돌던 다른 서비스들도 내려가 있는 것을 알았다. 13:34 에 --grace-period=0 --force 로 강제 삭제할 수 있다는 것을 찾았고, Unknown 과 NodeLost 상태 파드를 모두 지우자 그 서비스들이 회복했다."},"trigger":null,"severity":"unknown","symptoms":["service-unavailable","node-not-ready","pod-stuck-terminating","pod-stuck-container-creating"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"The team noticed only after several hours, when the launch success rate on the Grafana dashboard had been at zero for a long time. No Stackdriver alert email arrived in time, because those emails were marked as spam and reached the team hours later.","ko":"07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. Stackdriver 알림 메일은 오지 않았다. Stackdriver 메일은 스팸으로 분류되곤 했고 알림이 몇 시간 늦게 도착했다."},"components":["persistent-volume","node-pool"],"root_cause":"unknown","remediation":[{"text":{"en":"Cordoned the bad nodes","ko":"07:33 에 상태가 나쁜 노드를 cordon 했다."}},{"text":{"en":"Deleted the hub pod in Unknown state and the hub pod stuck in ContainerCreating","ko":"Unknown 상태의 hub 파드와 5시간째 ContainerCreating 이던 두 번째 hub 파드를 지워, 정상 노드에 다시 스케줄되는지 봤다."}},{"text":{"en":"Reset node gke-prod-a-ssd-pool-32-134a959a-n2sk from the GCP web interface to force the PVC to be released","ko":"GCP 웹 화면에서 노드 gke-prod-a-ssd-pool-32-134a959a-n2sk 를 손으로 reset 해 PVC 를 강제로 풀려고 했다. 08:05 에 새 hub 파드가 다른 노드에 떠 실행됐다."}},{"text":{"en":"Force-deleted every pod in Unknown or NodeLost state with kubectl delete --grace-period=0 --force","ko":"13:34 에 kubectl --namespace=prod delete pod <pod-name> --grace-period=0 --force 로 Unknown, NodeLost 상태 파드를 모두 강제 삭제했고, 그 파드에서 돌던 서비스들이 회복했다."}}],"action_items":[{"text":{"en":"Investigate why the outage started, through Stackdriver logs and Google Cloud incidents","ko":"장애가 왜 시작됐는지 조사한다. 문제를 일으킨 파드가 있었는지, GCE 장애였는지 Stackdriver 로그와 Google Cloud 장애 공지를 살핀다."}},{"text":{"en":"Set up an alerting service that does not depend on Stackdriver","ko":"Stackdriver 가 아닌 알림 서비스를 두어 이런 문제를 더 일찍 잡는다. 이 일은 지금 #365 에 막혀 있다."}},{"text":{"en":"Document how to check whether a PVC has not been released","ko":"PVC 가 풀리지 않았는지 확인하는 방법을 문서로 남겨, 다음에 이 문제를 빨리 알아볼 수 있게 한다."}},{"text":{"en":"Document how to restart a node by hand when commands are not working","ko":"명령이 대부분 통하지 않을 때 노드를 손으로 재시작하는 방법을 문서로 남긴다."}},{"text":{"en":"Document how to delete pods that are in Unknown state","ko":"Unknown 상태가 된 파드를 지우는 방법을 문서로 남긴다. 이 문서는 #512 에서 다룬다."}}],"contributing":["paging-failed"],"recurrence_of":null,"symptoms_text":{"en":"On 13 March 2018 at 07:28 CET the mybinder.org team noticed that JupyterHub had not been spawning new users and that the launch success rate on the Grafana dashboard had been at zero for several hours. Many pods were in the states \"Unknown\" and \"NodeLost\", on at least the nodes `10.128.0.7` and `10.128.0.5`.\n\nThe hub pod `hub-65d9f46698-dj4jb` was in state `Unknown`, and a second hub pod, `hub-65d9f46698-dmlcv`, had been in `ContainerCreating` for 5 hours. A new hub pod could not start because the PVC holding the hub database was still claimed by the old hub pod, which was lost and did not release it. The bhub pod could not talk to the jhub pod although it could reach google.com and github.com.\n\nCordoning the bad nodes and deleting the two hub pods did not free the PVC, and neither did deleting every pod on node `-n2sk`. Deleting pods in \"Unknown\" state with a normal delete did nothing; the pods stayed listed. At 13:32 the team found that many other services were also down because their pods had been on the failed nodes and were stuck in `Unknown` or `NodeLost`.","ko":"2018년 3월 13일 07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. JupyterHub 가 새 사용자를 하나도 받지 못하고 있었다.\n\n많은 파드가 \"Unknown\" 과 \"NodeLost\" 상태였고, 이상한 상태의 파드는 적어도 노드 10.128.0.7 과 10.128.0.5 에 있었다. hub 파드 hub-65d9f46698-dj4jb 는 Unknown 이었고, 두 번째 hub 파드 hub-65d9f46698-dmlcv 는 5시간째 ContainerCreating 이었다.\n\n07:39 에 bhub 파드는 jhub 파드와 통신하지 못했지만 google.com 과 github.com 에는 연결됐다. 새 jhub 파드는 PVC 를 다른 옛 파드가 아직 잡고 있어 시작하지 못했다. 팀은 그 옛 파드가 죽었거나 사라진 채로 claim 을 놓지 않고 있다고 봤다.\n\n팀은 나쁜 노드를 cordon 하고 두 hub 파드를 지웠다. 07:59 에 노드 -n2sk 의 파드를 모두 손으로 지웠지만 PVC 는 풀리지 않았다. 08:11 에 Unknown 상태 파드를 모두 지웠지만 파드는 목록에 그대로 남았다.\n\n13:32 에 팀은 실패한 노드에 있던 파드에서 돌던 다른 서비스도 여럿 내려가 있는 것을 알았다."},"updated_at":"2026-11-14T12:34:05.344588Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0402","org_slug":"binder-project"}