사례1건

1건 중 1~1번째

1. IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.

   2i2c2020

   증상

   WER 허브의 학생들이 페이지가 멈춘다고 알려 왔다. 아무것도 쓸 수 없는 완전한 장애였다. 08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   서비스 중단노드 CPU 고부하

   촉발

   WER 학생들의 사용량이 늘어 사용자 파드와 코어 파드가 함께 도는 노드의 CPU 와 메모리를 다 썼다.

   원인

   용량 한계

   구성 요소

   노드 풀컨테이너 메모리 한도

   기여 요인

   리소스 요청과 한도 미설정미검증 가정과도한 영향 범위

   감지

   08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   조치

   • 09:23 PM 에 WER 학생 파드의 메모리 오버커밋을 없앴다. 학생들이 메모리 한도의 상당 부분을 쓰고 있었고, 새 노드가 하나 더 떠서 기존 노드의 부담을 덜 것으로 보았다.
   • 09:24 PM 에 모든 코어 파드의 자원 보장을 올려 노드가 가득 차도 코어 파드가 동작할 자원을 갖게 했다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌다.

   후속 조치

   • 사용자 파드를 별도 노드 풀로 옮겨 코어 파드에 부담을 주지 않게 한다.
   • prometheus, grafana, ingress 같은 지원 인프라에도 한도를 건다.
   • 메모리 오버커밋 비율을 검토하고 문서로 남긴다.
   • 자원 사용량을 감시할 Grafana 대시보드를 더 낫게 만든다.
   • 다른 사람도 문제를 살펴볼 수 있게 클러스터의 kubectl 접근 권한을 얻는 방법을 문서로 남긴다.

   교훈

   코어 파드와 사용자 파드가 같은 노드에 섞여 있으면 사용자 사용량이 몰릴 때 코어 파드까지 자원을 얻지 못한다. 코어 파드에는 노드가 가득 차도 동작할 만큼의 자원 보장이 있어야 한다. 메모리 오버커밋 비율은 관례대로 정하지 말고 실제 사용량에 맞춰야 한다. WER 학생들은 한도의 상당 부분을 실제로 쓰고 있어서 4배 오버커밋은 지나쳤다.

   사례 보기

원인별1