IL-0094 2i2c · 2020-10-28kubernetesgcp
2i2c 가 운영하는 WER 허브에서 학생들이 페이지가 멈춘다고 알려 왔고, 허브는 아무것도 쓸 수 없는 상태였다. 조사해 보니 허브의 코어 파드에 알맞은 자원 보장이 설정되어 있지 않았고, 코어 파드만 도는 전용 노드 풀도 없었다. 자원 보장은 노드가 가득 차도 파드가 확보하는 최소 자원이다. 학생들의 사용량이 노드의 CPU 와 RAM 을 다 써 버리자 모든 파드가 자원을 얻지 못했다.
메모리 설정도 실제 사용량과 맞지 않았다. 팀은 WER 에 필요한 RAM 을 시험한 뒤 학생마다 한도 2G, 보장 512M 으로 늘 하던 대로 4배 오버커밋을 걸어 두었다. 오버커밋은 보장보다 한도를 크게 잡아 노드의 실제 메모리보다 많은 사용을 허용하는 설정이다. 그런데 시험 결과를 보면 학생들은 거의 항상 1G 바로 아래를 썼으므로 오버커밋은 2배였어야 했다. 팀은 학생 파드의 메모리 오버커밋을 없애고 모든 코어 파드의 자원 보장을 올렸다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌고, 상황은 정상으로 돌아왔다. 09:46 PM 에 이슈를 닫았다.
WER 허브의 학생들이 페이지가 멈춘다고 알려 왔다. 아무것도 쓸 수 없는 완전한 장애였다. 08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.
09:02 PM 에 사용량이 늘어난 것을 알아챘지만, 시크릿 창으로 접속하기나 서버 재시작 같은 평소의 조치로는 나아지지 않았다.
09:21 PM 에 노드 자원 사용률을 보자 자원 고갈이 분명했다. kubectl top node 출력에서 gke-low-touch-hubs-cluster-core-pool-b7edea69-gwrg 노드는 CPU 1944m 로 100%, 메모리 10432Mi 로 98% 였다. 다른 코어 노드인 gke-low-touch-hubs-cluster-core-pool-b7edea69-00sc 는 CPU 220m 로 11%, 메모리 6151Mi 로 58% 였다. 클러스터에는 코어 노드만 있고 사용자 노드가 따로 없었기 때문에, 팀은 사용자 파드가 자원을 차지해 코어 파드가 자원을 얻지 못한다고 의심했다.
증상 ? 서비스 중단노드 CPU 고부하
원인 ? 용량 한계
08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.
코어 파드와 사용자 파드가 같은 노드에 섞여 있으면 사용자 사용량이 몰릴 때 코어 파드까지 자원을 얻지 못한다. 코어 파드에는 노드가 가득 차도 동작할 만큼의 자원 보장이 있어야 한다. 메모리 오버커밋 비율은 관례대로 정하지 말고 실제 사용량에 맞춰야 한다. WER 학생들은 한도의 상당 부분을 실제로 쓰고 있어서 4배 오버커밋은 지나쳤다.
같은 원인 · 공통 컨테이너 메모리 한도, 노드 풀
같은 원인 · 공통 컨테이너 메모리 한도, 노드 풀
같은 원인 · 공통 컨테이너 메모리 한도, 노드 풀
같은 원인 · 공통 컨테이너 메모리 한도, 노드 풀
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 노드 풀
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도
같은 원인 · 공통 컨테이너 메모리 한도