IL-0055 Target · 2018-09-20 (게시일)kubernetes
Target 에서 일했던 발표자가 쿠버네티스 클러스터가 내려간 원인이 된 실수들을 소개했다. 이 사례는 발표자가 가장 흔하게 본 원인으로 꼽은 CronJob 건이다.
CronJob 의 concurrencyPolicy 기본값은 작업을 동시에 실행하도록 허용한다. 그래서 작업이 실패해 재시작하는 동안에도 다음 작업이 새로 만들어졌고, 새 작업이 앞선 작업을 대신하지 않고 나란히 쌓였다. 발표자의 계산으로는 매분 실행되는 작업 하나가 사흘 동안 실패하면 재시작하는 파드가 4320개가 된다. 이 클러스터에서는 파드가 약 4천 개에 이르렀다.
클러스터는 오토스케일링을 쓰고 있어서 파드가 늘어나는 만큼 커졌고, 가상 CPU 수백 개 규모가 됐다. 클러스터는 내려갔고 비용도 크게 들었다.
발표자는 CronJob 의 concurrencyPolicy 를 Replace 나 Forbid 로 정하고, 애플리케이션이 실패를 안전하게 다루도록 만들라고 권했다. init 컨테이너와 readiness 검사, liveness 검사를 쓰고, 데이터베이스 같은 의존 대상이 없을 때는 바로 죽어 재시작을 반복하지 말고 지수 백오프로 정해진 시간 동안 재시도하라고 했다.
CronJob 하나가 계속 실패했다. 실패한 작업이 끝나지 않은 채 다음 작업이 계속 만들어졌고, 재시작을 거듭하는 파드가 수천 개로 쌓였다. 발표자의 계산으로는 매분 실행되는 작업 하나가 사흘 동안 실패하면 재시작하는 파드가 4320개가 된다.
클러스터는 오토스케일링을 쓰고 있어서 파드 수를 따라 커졌다. 파드가 약 4천 개에 이르렀을 때 클러스터의 가상 CPU 는 수백 개까지 늘어 있었고, 비용도 크게 들었다. 결국 클러스터가 내려갔다.
증상 ? 서비스 중단
–
–
–
CronJob 을 배포할 때는 concurrencyPolicy 를 Replace 나 Forbid 로 정한다. 기본값에서는 실패한 작업이 쌓여 한꺼번에 재시작한다. 오토스케일링이 켜진 클러스터에서는 이렇게 늘어난 파드가 그대로 노드 증가와 비용 증가로 이어진다. 발표자는 의존 대상에 연결하지 못할 때 바로 죽어 재시작을 반복하기보다 지수 백오프로 일정 시간 재시도한 뒤 종료하라고 권했다. readiness 검사와 liveness 검사도 쓰라고 했다.
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀