Incident Library

IL-0402 Binder Project · 2018-03-13kubernetesgcp

GKE 노드가 고장 나 NodeLost 가 된 JupyterHub 파드가 hub DB 의 PVC 를 놓지 않아 mybinder.org 가 몇 시간 동안 새 사용자를 받지 못했다

2018년 3월 13일 mybinder.org 의 JupyterHub 가 몇 시간 동안 새 사용자를 받지 못했다. 일부 GKE 노드가 고장 났고, JupyterHub 파드가 그런 노드에 있었는데 제대로 지워지지 않았다. 파드가 정리되지 않아 hub DB 가 든 PVC 를 놓지 못했고, 새 hub 파드는 DB 에 접근하지 못했다. 장애가 왜 시작됐는지는 조사할 일로 남았다.

07: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 상태 파드를 모두 지우자 그 서비스들이 회복했다.

심각도
–
영향 범위
mybinder.org could not launch any sessions for several hours; other services whose pods were on the failed nodes were down until 13:34
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2018년 3월 13일 07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. JupyterHub 가 새 사용자를 하나도 받지 못하고 있었다.

많은 파드가 "Unknown" 과 "NodeLost" 상태였고, 이상한 상태의 파드는 적어도 노드 10.128.0.7 과 10.128.0.5 에 있었다. hub 파드 hub-65d9f46698-dj4jb 는 Unknown 이었고, 두 번째 hub 파드 hub-65d9f46698-dmlcv 는 5시간째 ContainerCreating 이었다.

07:39 에 bhub 파드는 jhub 파드와 통신하지 못했지만 google.com 과 github.com 에는 연결됐다. 새 jhub 파드는 PVC 를 다른 옛 파드가 아직 잡고 있어 시작하지 못했다. 팀은 그 옛 파드가 죽었거나 사라진 채로 claim 을 놓지 않고 있다고 봤다.

팀은 나쁜 노드를 cordon 하고 두 hub 파드를 지웠다. 07:59 에 노드 -n2sk 의 파드를 모두 손으로 지웠지만 PVC 는 풀리지 않았다. 08:11 에 Unknown 상태 파드를 모두 지웠지만 파드는 목록에 그대로 남았다.

13:32 에 팀은 실패한 노드에 있던 파드에서 돌던 다른 서비스도 여럿 내려가 있는 것을 알았다.

증상 서비스 중단노드 NotReady파드 Terminating 정체파드 ContainerCreating 정체

원인

원인 unknown

구성 요소 영구 볼륨과 스테이트풀셋노드 풀
기여 요인 온콜 호출 미전달
촉발
–

감지

07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. Stackdriver 알림 메일은 오지 않았다. Stackdriver 메일은 스팸으로 분류되곤 했고 알림이 몇 시간 늦게 도착했다.

조치

후속 조치

교훈

문제를 찾은 뒤에는 조치를 잘 기록했고, 필요에 따라 더 강한 조치로 빠르게 넘어가서 hub 가 멈춘 시간은 짧았다. 오류를 알아채기까지는 꽤 오래 걸렸다. Stackdriver 메일이 오지 않았는데, Stackdriver 메일은 스팸으로 분류되고 알림이 몇 시간 뒤에야 도착했다.

출처

참고 문서

관련 사례

–

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

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

kubegap 열기

AI 도구와 스크립트용

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