IL-0095 2i2c · 2025-08-12kubernetes
2025년 8월 12일, 2i2c 엔지니어가 새 temple 클러스터에 허브를 배포하다 NFS 문제를 만났다. NFS 배포 과정의 버그를 우회하려고 prod 네임스페이스를 지웠는데, 그때 작업 대상은 LEAP 클러스터였다. 엔지니어에게는 LEAP 허브로 넘어갔다는 단서가 보이지 않았다. LEAP 의 prod 네임스페이스에 있던 파드가 모두 종료됐고 허브는 약 1시간 동안 접속할 수 없었다.
엔지니어는 모니터링 알림보다 먼저 상황을 알아채고 17:00 BST 에 장애를 선언했다. 두 번째 엔지니어가 일찍 합류해 LEAP 커뮤니티에 상황을 알리는 일을 맡았다. 첫 엔지니어는 prod 를 다시 배포하면 된다는 것을 알았지만, 영구 데이터를 잃을 위험이 없는지 다른 시간대에 있는 테크 리드에게 확인받고 싶어 했고 연락이 닿기까지 시간이 걸렸다. 17:43 에 테크 리드가 재배포를 승인했다.
남아 있던 사용자 파드 하나를 지워 네임스페이스 삭제를 끝냈다. 재배포는 nfs-share-creator 잡이 막고 있어 그 잡을 종료했다. jupyterhub-home-nfs 배포와 PVC 가 쓰는 NFS 서버 IP 사이에 순환 의존이 있어 재배포에 몇 분이 더 걸렸다. 엔지니어는 바뀐 NFS 서버 IP 로 prod 를 다시 배포하고, 배포 중 사용자가 서버를 띄우지 못하게 인그레스를 지웠다. 18:08 에 허브를 다시 열었고 18:11 에 장애를 종료했다. 영구 스토리지를 Terraform 으로 따로 프로비저닝해 두었기 때문에 데이터는 잃지 않았다.
새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.
엔지니어는 처음에 kubeconfig 가 바뀌었거나 망가져 다른 클러스터가 지워지고 있다고 생각하고 17:00 BST 에 장애를 선언했다. 2분 뒤 지워진 쪽이 LEAP 클러스터이고 prod 에는 파드가 하나도 남지 않았다는 것을 확인했다.
17:32 BST 에 LEAP 업타임 검사가 실패했다. 알림에는 "An uptime check on two-eye-two-see Uptime Check URL labels {project_id=two-eye-two-see, host=leap.2i2c.cloud} is failing." 이 찍혔다. 17:37 에는 허브에 접속하면 404 오류가 난다는 사용자 제보가 처음 들어왔다.
복구 뒤 20:16 에 일부 사용자가 로그인에 어려움을 겪거나 커널 연결이 끊긴다는 제보가 들어왔다. 엔지니어가 확인해 보니 무거운 Dask 워크로드가 시작되면서 Dask 노드가 최대 200개까지 프로비저닝됐고, 워크로드는 결국 안정됐다.
원인 ? 운영 실수
네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.
쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 영구 볼륨과 스테이트풀셋
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 인그레스 컨트롤러