Incident Library

IL-0503 Binder Project · 2017-11-30kubernetesgcp

GKE 노드의 메모리가 바닥나 mybinder.org 의 proxy 파드가 OOM 으로 죽고 새 서버 실행이 실패했다

태평양 시간으로 2017년 11월 30일 16:22 에 mybinder.org 의 GKE 노드 하나가 메모리를 다 쓰면서 서비스에 문제가 생기기 시작했다. 그 노드에서 돌던 proxy 파드가 죽고 재시작하기를 되풀이했고, 새 서버 실행은 임시 사용자를 만들지 못하고 실패했다. 운영팀은 빌드에 메모리 제한이 없어서 빌드 컨테이너가 노드의 메모리를 다 썼을 가능성이 크다고 봤다.

16:59 에 엔지니어가 Grafana 가 이상한 것을 보고 조사를 시작했다. 처음에는 Google Cloud 의 storage 사고를 의심했고, 콘솔에서는 모든 노드가 Ready 였다. 17:04 에 proxy 파드가 CrashloopBackoff 에 빠진 것을 찾았다. 17:12 에 jupyterhub 파드를 kubectl replace --force 로 다시 만들었지만 이 때문에 사용자 파드가 모두 지워졌고 오류는 남았다. 17:14 에 proxy 가 돌던 노드에서 OOMKilling 이벤트를 찾았다. 17:18 에 그 노드를 cordon 하고 proxy 파드를 지우자는 제안이 나왔고, 17:20 에 proxy 파드가 다시 동작하는 것을 알아챘다. 그 proxy 파드는 그때 이미 10분째 돌고 있었다. 노드는 다시 uncordon 했고, 17:21 에 사용자 파드가 다시 뜨며 서비스가 돌아왔다.

심각도
–
영향 범위
mybinder.org: new server launches failed; restarting the jupyterhub pod also removed all running user pods
영향 사용자
–
지역
us-central1-a
감지까지
37m
복구까지
59m

증상

mybinder.org 에서 새 서버를 실행하면 임시 사용자를 만들지 못했다는 오류가 떴다. 엔지니어가 마침 Grafana 를 보다가 그래프가 이상한 것을 보고 알아챘다.

실행 화면에는 Found built image, launching... 과 Launching server... 다음에 Failed to create temporary user for gcr.io/binder-prod/r2d-<repository>:6be6d6329de99168d0a0b68f9d52228ecc61ac50 이 찍혔다.

proxy 파드는 CrashloopBackoff 상태로 13번쯤 재시작해 있었다. kubectl describe 의 이벤트에는 Back-off restarting failed container 와 Error syncing pod, 그리고 Readiness probe failed: Get http://10.12.5.36:10254/healthz: dial tcp 10.12.5.36:10254: getsockopt: connection refused 가 있었다. 컨테이너 이미지는 gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.15 였다.

proxy 가 돌던 노드를 kubectl describe 로 보니 Warning OOMKilling 58m kernel-monitor, gke-prod-a-default-pool-6ab3d8ec-0h28 Memory cgroup out of memory: Kill process 8339 (python) score 1576 or sacrific 이벤트가 있었다. 그런데 클라우드 콘솔의 Kubernetes clusters 페이지에서는 모든 노드가 Ready 로 보였다.

처음에는 Google Cloud 상태 페이지의 storage 사고 17006 과 관련이 있는지 의심했다. jupyterhub 파드 로그에는 타임아웃 나는 DELETE 요청과 트레이스백이 많았다. 기존 파드는 돌고 있었지만 새 파드가 생기지 않았다. jupyterhub 파드를 강제로 다시 만들었더니 사용자 파드가 모두 지워졌고 오류는 그대로였다.

증상 서비스 중단컨테이너 재시작 반복프로브 실패OOMKilled

원인

원인 용량 한계

구성 요소 인그레스 컨트롤러컨테이너 메모리 한도JupyterHub
기여 요인 리소스 요청과 한도 미설정수동 조치 악화한계 경보 부재
촉발
GKE 노드 하나의 메모리가 바닥났다. 빌드에 메모리 제한이 없어서 빌드 컨테이너가 노드의 메모리를 다 썼을 가능성이 크다고 봤다.

감지

엔지니어가 마침 Grafana 를 보다가 그래프가 이상한 것을 보고 알아챘다.

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 인그레스 컨트롤러, 컨테이너 메모리 한도, JupyterHub. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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