사례3건

3건 중 1~3번째

1. IL-0091 Terraform 으로 노드 인스턴스 타입을 바꾸자 노드가 한꺼번에 교체되어 사용자 운영 파드가 모두 지워지고 서비스가 내려갔다

   UK Ministry of Justice2023

   증상

   2023-06-06 10:23 에 한 사용자가 운영 파드가 한꺼번에 지워졌다고 알렸다. 여러 사용자가 같은 문제를 알렸고, 애플리케이션이 몇 분 동안 내려갔다는 Pingdom 알림을 받았다고 했다.

   서비스 중단

   촉발

   팀이 Terraform 으로 노드 인스턴스 타입을 바꾸었다.

   원인

   설정 변경

   구성 요소

   노드 풀Terraform

   기여 요인

   과도한 영향 범위런북 부재

   감지

   사용자들이 운영 파드가 한꺼번에 지워졌다고 알렸고, 애플리케이션이 내려갔다는 Pingdom 알림을 받았다고 전했다. 첫 감지 시각은 10:26 이다.

   후속 조치

   • 중단 없이 노드 인스턴스 타입을 바꾸는 절차를 묻는 티켓을 AWS 에 열었다.
   • Terraform 으로 하는 노드 인스턴스 타입 변경을 중단 없이 할 방법을 정하고, 그 절차를 런북으로 만든다.

   사례 보기
2. IL-0070 dask-gateway로 워커를 대량으로 띄우자 노드가 1분 만에 100대 늘었고, Prometheus가 메모리를 거의 다 쓰던 코어 노드에서 hub 파드를 비롯한 중요한 파드들이 축출되거나 재시작됐다

   2i2c2023

   증상

   2023년 2월 1일 leap 클러스터의 prod 허브에서 노드가 대량으로 늘었고, hub 파드가 알 수 없는 이유로 재시작됐다. 사용자 지원 티켓도 들어왔다.

   파드 축출파드 Pending

   촉발

   한 사용자의 dask-gateway 작업이 1분 사이에 dask-worker 노드를 100대쯤 늘렸고, Prometheus 는 노드 200대쯤의 지표 내보내기 대상을 수집하기 시작했다.

   원인

   용량 한계

   구성 요소

   Prometheus노드 풀

   기여 요인

   여유 용량 부재과도한 영향 범위모니터링 사각지대

   감지

   2i2c Freshdesk에 들어온 사용자 지원 티켓 414로 드러났다. 이후 엔지니어가 Grafana와 클러스터의 노드, event를 살폈다. 조사 내용은 같은 날 UTC+1 기준 저녁 8시에서 9시 사이에 이슈에 정리됐다.

   후속 조치

   • basehub에서 hub와 proxy 파드의 CPU와 메모리 요청을 넉넉히 설정한다. 이슈 #2127이다.
   • Grafana의 OOMKiller 대시보드가 제대로 동작하게 고친다. 이슈 #2213이다.
   • LEAP 클라우드 인프라를 공유 노드 구성으로 옮긴다. 이슈 #2209다.
   • ingress-nginx와 Prometheus의 리소스 요청과 한도를 고친다. Prometheus 서버는 메모리 요청을 한도와 같게 맞춘다. 이슈 #2324다.
   • Prometheus가 daskhub 워커 파드를 수집하도록 넣은 설정이 필요한지 다시 본다. 이슈 #2366이다.

   교훈

   Prometheus 서버처럼 메모리를 많이 쓰는 파드가 요청보다 훨씬 많이 쓰면 같은 노드의 중요한 파드가 축출된다. 노드가 한꺼번에 100대 늘면 Prometheus가 수집할 대상도 함께 늘어난다. hub와 proxy처럼 중요한 파드는 실제 사용량보다 요청을 넉넉히 잡아야 축출과 CPU 부족을 피할 수 있다. 쿠버네티스 event는 60분이 지나면 사라지므로, OOMKill 여부를 나중에 확인하려면 따로 기록해 두어야 한다.

   사례 보기
3. 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배 오버커밋은 지나쳤다.

   사례 보기

원인별2