사례6건

6건 중 5~6번째

1. IL-0029 CPU 한도를 건 컨테이너가 사용량이 한도에 한참 못 미치는데도 스로틀링되어 사용자 대면 서비스의 지연 시간이 늘었다.

   Buffer2020

   증상

   Buffer 엔지니어가 컨테이너의 스로틀링 지표를 살펴보니, CPU 사용량이 한도 근처에도 가지 않은 컨테이너가 많이 스로틀링되고 있었다.

   CPU 스로틀링지연 시간 증가노드 NotReady

   촉발

   Buffer 는 노드를 지키려고 컨테이너에 CPU 한도를 걸어 두었는데, 노드 커널에는 CPU 한도가 걸린 컨테이너를 필요 없이 스로틀링하는 버그가 남아 있었다.

   원인

   소프트웨어 결함

   구성 요소

   컨테이너 CPU 한도리눅스 커널노드 운영체제 이미지

   기여 요인

   미패치 알려진 버그미검증 가정

   감지

   엔지니어가 컨테이너의 스로틀링 지표를 살피다가, CPU 사용량이 한도보다 훨씬 낮은 컨테이너도 많이 스로틀링되는 것을 보고 알았다.

   조치

   • 사용자에게 직접 또는 간접으로 닿는 경로에 있는 모든 서비스에서 CPU 한도를 없앴다.
   • 한도를 없앤 서비스에 톨러레이션을 더해 테인트를 건 노드에서만 돌게 하고, 한도가 있는 서비스와 떼어 놓았다.
   • 서비스마다 몇 달 치 사용량을 분석해 최대 CPU 사용량에 20% 넘는 여유를 더한 값을 CPU 요청값으로 정했고, 메모리 요청값도 같은 방식으로 정했다.

   후속 조치

   • 커널 수정이 들어간 노드 이미지로 올린다. Buffer 는 kops 1.18 이상에서 기본 이미지가 되는 Ubuntu 20.04 를 기다리고 있다.
   • 수정된 커널로 올린 뒤 스로틀링이 정말 사라졌는지 확인하고, 그 결과로 글을 고친다.

   교훈

   리눅스에서 컨테이너를 돌리면 쿠버네티스든 Mesos 든 Swarm 이든 스로틀링 때문에 컨테이너가 제 성능을 내지 못할 수 있다. 먼저 커널을 수정된 버전으로 올리고 스로틀링 지표를 지켜보는 편이 낫다. CPU 한도를 없애면 지연 시간은 줄지만 위험하다. 한도를 없앤다면 CPU 요청값을 제대로 잡고, 노드의 CPU 와 메모리 사용량을 꼼꼼히 모니터링한다. 사용량이 높으면 Horizontal Pod Autoscaler 로 파드를 늘려 여유 있는 노드에 배치되게 한다. 클러스터에 여유가 없으면 알림을 받거나 노드 오토스케일러로 노드를 늘린다.

   사례 보기
2. IL-0143 GKE 1.13 과 1.14 의 특정 버전으로 업그레이드한 노드에서 커널 패닉이 늘었다.

   Google Cloud2019

   증상

   2019-11-04 11:46 US/Pacific, Google 은 최근 업그레이드한 GKE 클러스터의 일부 노드에서 커널 패닉이 늘었다며 조사를 시작했다. 영향은 특정 GKE 버전으로 업그레이드한 노드에 한정됐다.

   노드 커널 패닉

   촉발

   노드 풀을 영향받은 GKE 1.13, 1.14 버전으로 업그레이드했다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지리눅스 커널

   기여 요인

   –

   조치

   • 영향받은 버전에 들지 않는 이전 릴리스로 노드를 내리는 우회 방법을 안내했고, Release Channel 사용자는 지원팀을 통해 다운그레이드하게 했다.
   • Container-Optimized OS 를 cos-73-11647-293-0 으로 내린 수정 버전 1.13.11-gke.14, 1.13.12-gke.8, 1.14.7-gke.23, 1.14.8-gke.12 를 내놓았다.
   • 노드 자동 업그레이드를 켠 노드 풀에 수정 버전을 배포했고, 수동 업그레이드를 쓰는 고객은 직접 노드를 올리게 했다.

   후속 조치

   • 다음 GKE 릴리스에서 커널을 올리고 커널 패닉을 고친다.

   교훈

   커널 수정이 나올 때까지 노드 운영체제 이미지를 이전 버전으로 내리는 것을 임시 완화책으로 썼다.

   사례 보기

원인별1