사례2건

2건 중 1~2번째

1. IL-0015 GKE 가 노드마다 IP 256개를 미리 잡아 /16 파드 주소 범위가 바닥나고 노드 증설과 배포가 멈췄다

   loveholidays2020

   증상

   동료가 슬랙으로 애플리케이션 배포가 오래 걸린다고 알려 왔다. 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 머물러 있었다. 새 파드의 절반쯤은 트래픽을 받고 있었고 나머지 절반은 Pending 상태였다.

   파드 PendingIP 주소 고갈노드 증설 실패

   촉발

   클러스터의 노드 수가 256개에 이르렀다. GKE 는 노드당 최대 파드 수를 기본 110 으로 두고, 그 두 배 이상을 담을 수 있는 서브넷 마스크를 노드마다 미리 할당한다. 노드 하나가 IP 256개를 차지하므로 /16 보조 범위의 65,536개 주소가 노드 256개에서 바닥났다.

   원인

   용량 한계

   구성 요소

   VPC 서브넷 또는 파드 주소 범위클러스터 오토스케일러노드 풀

   기여 요인

   기본 설정 방치한계 미인지

   감지

   동료가 슬랙으로 배포가 오래 걸린다고 알려 왔다. 확인해 보니 평소 몇 분이면 끝나는 배포가 한 시간째 새 파드 일부만 띄운 채 멈춰 있었다.

   조치

   • 파드가 많이 뜨지 않을 노드 풀에서 노드당 최대 파드 수를 줄여 전체 IP 사용량을 약 30% 줄였다.
   • 일부 노드 풀의 인스턴스 크기를 키워 노드당 더 많은 파드를 돌리게 했다.

   후속 조치

   • 상태 저장 애플리케이션, 캐시, 보안을 강화한 워크로드처럼 노드에 파드가 많이 뜨지 않는 노드 풀은 노드당 최대 파드 수를 낮춰 운영한다.
   • 일부 노드 풀에 더 큰 인스턴스를 쓴다.

   교훈

   GKE 는 기본으로 노드마다 IP 256개를 할당한다. /16 처럼 큰 범위도 노드가 256개면 바닥난다. 노드당 최대 파드 수가 파드 IP 소비량을 정하므로, 노드 풀마다 실제로 띄울 파드 수에 맞춰야 한다. 큰 노드를 쓰면 IP 를 효율적으로 쓰고 자원 활용도도 높아지지만, 노드 하나가 죽을 때 더 많은 파드가 함께 내려간다.

   사례 보기
2. IL-0468 노드당 볼륨 개수 한도에 걸려 새 학생 서버 파드가 Pending 에 머물고 학생들이 500 오류를 받았다

   UC Berkeley2017

   증상

   2017-03-20 12:44 에 새 학생 서버가 500 오류를 내며 로그인을 막는다는 보고가 들어왔다. 한 사람의 문제가 아니라 널리 퍼진 증상이었다.

   파드 Pending오류율 상승

   촉발

   2017-03-18 16:30 에 자원을 아끼려고 학생 한 명에게 주는 메모리를 2G 에서 1G 로 줄였지만, 노드 크기는 26G RAM 그대로 두었다. 그 결과 Google Cloud 의 노드당 디스크 개수 한도에 닿았다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도클라우드 블록 스토리지노드 풀

   기여 요인

   한계 미인지

   감지

   12:44 에 새 학생 서버가 500 오류로 로그인을 막는다는 보고가 들어왔고, 팀은 이것이 한 사람의 문제가 아니라 널리 퍼진 장애라고 판단했다.

   조치

   • Google Container Engine 이 쓰는 인스턴스 템플릿을 복사해 n1-highmem-4 대신 더 작은 n1-highmem-2 노드를 띄우도록 고쳤다.
   • Google Container Engine 의 관리형 인스턴스 그룹이 새 템플릿을 쓰게 바꿨다.
   • 새 인스턴스 그룹을 30노드 늘렸다. 노드 하나에 학생 12명쯤이 들어가는 용량이었다.
   • populate.bash 를 돌려 새 노드에서 학생 파드가 제때 뜨게 했다.
   • 노드가 섞인 낯선 상태에서 오작동할까 봐 간단한 오토스케일러를 멈췄다.
   • 'redirected too many times' 오류를 알려 온 사용자마다 관리자가 제어판에서 그 사용자의 파드를 멈췄다가 다시 켰다.
   • 'redirected too many times' 오류가 많이 나서 허브 파드와 프록시 파드를 재시작했다.

   후속 조치

   • 이번에 부딪힌 쿠버네티스 버그인 kubernetes/kubernetes 이슈 24317 의 진행을 지켜본다.
   • JupyterHub 의 'too many redirects' 문제를 근원에서 찾아 고친다.
   • 더 이상 쓰지 않는 예전의 큰 노드를 모두 지운다.
   • 파드가 Pending 상태로 무시할 수 없을 만큼 오래 머물면 개수와 상관없이 알림을 보낸다.

   사례 보기

원인별1