사례14건

14건 중 11~14번째

1. IL-0037 imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다

   Datadog2019

   증상

   사용자들이 작업이 시작되지 않는다고 알려 왔다. 평소에는 모니터링이 먼저 잡아내는 편이었지만 이번에는 사용자 보고가 먼저였다. 처음부터 이미지 풀과 관련된 흔적이 보였다.

   이미지 풀 실패서비스 중단

   촉발

   애플리케이션 하나가 읽어야 하는 버킷의 권한을 바꾸면서 그 애플리케이션이 시작하지 못하게 됐다. 이 애플리케이션은 약 1,000대 노드에서 도는 DaemonSet이었고 크래시 루프에 빠졌다. imagePullPolicy가 Always여서 재시작할 때마다 노드에 이미 있는 이미지를 다시 받았다.

   원인

   용량 한계

   구성 요소

   컨테이너 레지스트리와 자격 증명NAT 게이트웨이애플리케이션 데이터베이스어드미션 웹훅

   기여 요인

   자동화 증폭단일 장애점한계 미인지수동 조치 악화과도한 영향 범위

   감지

   사용자들이 작업이 시작되지 않는다고 알려 와서 알았다. 모니터링보다 사용자 보고가 먼저였다. 팀은 파드 상태, 이미지 풀 지표, 레지스트리 응답 코드를 차례로 확인해 429 속도 제한을 찾았다.

   조치

   • 영향을 받은 NAT 인스턴스를 교체해 레지스트리로 나가는 출발지 IP를 바꿨다.
   • Cloud SQL 접속에 쓰던 고정 IP 설정과 방화벽 규칙을 다시 맞춰 데이터베이스 연결을 되살렸다.

   후속 조치

   • latest 같은 유동 이미지 태그를 막는 어드미션 웹훅을 만들어 워크로드 리소스와 파드에 걸었다.
   • 웹훅이 클러스터가 만드는 파드까지 거부하자, 파드 객체에서는 빼고 워크로드 객체에만 적용하도록 바꿨다.

   교훈

   imagePullPolicy가 Always인 DaemonSet이 크래시 루프에 빠지면 노드 수만큼 이미지 풀이 반복된다. 레지스트리 트래픽이 NAT 몇 대로 모이면 출발지 IP 몇 개가 속도 제한에 걸려 리전 전체가 이미지를 받지 못한다. NAT를 바꾸면 그 IP를 허용해 둔 외부 서비스 연결도 함께 끊긴다. 파드에 거는 어드미션 웹훅은 사용자가 아니라 컨트롤러가 만드는 파드까지 막는다. 발표자들은 대규모 클러스터에서는 DaemonSet을 특히 조심하라고 했다. DaemonSet이 기대는 DNS, Vault, 이미지 저장소도 모두 망가뜨려 본 적이 있다고 했다. 수천 대 단위로 무언가를 다루면 그만큼 망가뜨리기 쉽다는 것이다. kubelet 아래에도 인프라가 있다는 것을 잊지 말라고도 했다.

   사례 보기
2. IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.

   Moonlight2019

   증상

   1월 18일 금요일, Moonlight API 가 가끔 오류를 냈다. 처음 오류는 Redis 데이터베이스와 연결이 안 되는 문제로 보였다. Moonlight API 는 인증된 요청마다 Redis 에서 세션을 확인한다.

   오류율 상승간헐적 연결 실패노드 NotReady서비스 중단노드 CPU 고부하

   촉발

   쿠버네티스 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 같은 노드에 배치했다. 이 파드들이 노드 CPU 를 100% 쓰자 노드 VM 이 커널 패닉으로 죽었다.

   원인

   용량 한계

   구성 요소

   파드 스케줄링과 배치리눅스 커널애플리케이션 데이터베이스

   기여 요인

   단일 장애점미검증 가정자동화 증폭

   감지

   API 오류가 가끔 나면서 문제가 드러났다. 쿠버네티스 모니터링이 일부 노드와 파드가 응답하지 않는다고 보고했다. 노드가 CPU 100% 상태에서 커널 패닉으로 죽는다는 패턴은 Google Cloud 지원팀이 찾아냈다.

   조치

   • 주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드에 흩어 놓았다.

   후속 조치

   • Google Cloud 지원팀과 함께 노드 커널 패닉의 근본 원인을 찾아 고친다.

   교훈

   복제본을 세 개 두어도 스케줄러가 한 노드에 몰아 놓으면 그 노드가 단일 장애점이 된다. 사용자에게 응답하는 서비스에는 안티 어피니티 규칙을 넣어 파드를 여러 노드에 나눠 놓아야 한다. 팀은 처음에 클라우드 업체의 네트워크 장애를 원인으로 짐작했지만 실제 원인은 노드의 CPU 포화와 커널 패닉이었다.

   사례 보기
3. IL-0055 실패하는 CronJob 이 기본 concurrencyPolicy 때문에 겹겹이 쌓여 재시작하는 파드가 수천 개로 늘었고 클러스터가 내려갔다

   Target2018

   증상

   CronJob 하나가 계속 실패했다. 실패한 작업이 끝나지 않은 채 다음 작업이 계속 만들어졌고, 재시작을 거듭하는 파드가 수천 개로 쌓였다. 발표자의 계산으로는 매분 실행되는 작업 하나가 사흘 동안 실패하면 재시작하는 파드가 4320개가 된다.

   서비스 중단

   촉발

   CronJob 하나가 계속 실패했다.

   원인

   설정 변경

   구성 요소

   잡과 크론잡노드 풀

   기여 요인

   기본 설정 방치자동화 증폭

   교훈

   CronJob 을 배포할 때는 concurrencyPolicy 를 Replace 나 Forbid 로 정한다. 기본값에서는 실패한 작업이 쌓여 한꺼번에 재시작한다. 오토스케일링이 켜진 클러스터에서는 이렇게 늘어난 파드가 그대로 노드 증가와 비용 증가로 이어진다. 발표자는 의존 대상에 연결하지 못할 때 바로 죽어 재시작을 반복하기보다 지수 백오프로 일정 시간 재시도한 뒤 종료하라고 권했다. readiness 검사와 liveness 검사도 쓰라고 했다.

   사례 보기
4. IL-0036 재시도를 멈추지 않는 쿠버네티스 Job 이 노드 자원을 다 써 버려 클러스터의 노드가 차례로 죽고 검색과 리포트가 멈췄다.

   Universe2017

   증상

   재색인 Job 을 띄운 직후 Universe 의 리포트 API 와 검색 API 에 문제가 생겼다. 쿠버네티스 클러스터 UI 도 함께 영향을 받았다.

   서비스 중단노드 NotReady노드 재생성 반복

   촉발

   Discover 검색 색인에서 일부 데이터 필드를 빼는 변경을 배포하고, 새 설정을 적용하려고 쿠버네티스 Job 으로 재색인 작업을 띄웠다.

   원인

   용량 한계

   구성 요소

   잡과 크론잡파드 스케줄링과 배치

   기여 요인

   미검증 가정자동화 증폭과도한 영향 범위

   감지

   재색인 Job 을 띄운 직후 팀이 리포트 API, 검색 API, 쿠버네티스 클러스터 UI 의 문제를 알아챘다. 팀은 상태 페이지에 검색과 리포트를 쓸 수 없다는 보고를 조사하고 있다고 올렸다.

   조치

   • 문제의 재색인 Job 을 스케줄러에서 지웠다.
   • 노드들이 자동으로 회복해 모두 정상으로 돌아왔다.

   교훈

   RestartPolicy=Never 는 파드에만 적용되고 Job 에는 적용되지 않는다. Job 은 실패하면 항상 다시 시작되고 두 번 이상 실행될 수 있다. 노드 자원을 다 쓰는 작업을 Job 으로 돌리면 그 Job 이 노드를 옮겨 다니며 클러스터의 노드를 모두 쓰러뜨릴 수 있다.

   사례 보기

원인별5