IL-0031 Zalando · 2018-12-05 (게시일)kubernetesaws
Henning Jacobs가 2018년 12월 DevOpsCon Munich에서 발표한 Zalando 장애 사례 가운데 첫 번째다. Zalando는 클러스터 100개와 AWS 계정 373개를 운영했다. 요청은 ALB를 거쳐 노드마다 떠 있는 Skipper 인그레스로 들어오고, Skipper는 API 서버에서 라우트 정보를 받아 앱 파드로 요청을 보낸다. 이 구조에서 API 서버가 OOMKill로 죽자 Skipper가 라우트를 유지하지 못했다. 고객 트래픽이 끊겼고 IAM 서비스에서 404 오류가 났다.
발표는 원인으로 CronJob 매니페스트 하나를 보여 주었다. 원래 매니페스트에서는 동시 실행 정책과 이력 보존 개수 필드가 파드 템플릿 안에 있었다. 고친 매니페스트는 이 필드들을 CronJob spec으로 옮기고, Job에 activeDeadlineSeconds: 120을 넣고, 일정을 "*/15 9-19 * * Mon-Fri"에서 "7 8-18 * * Mon-Fri"로 바꿨다. 발표는 이 사고의 교훈으로, 모든 호스트가 unhealthy를 보고하면 ALB가 모든 호스트로 트래픽을 보낸다는 점을 꼽았다.
고객에게 영향이 간 장애였다. IAM 서비스에서 404 오류가 나기 시작했다.
발표는 이어서 클러스터의 파드 수를 다룬 슬라이드를 보여 주었다.
그다음 API 서버가 OOMKill로 죽었다. Zalando의 요청은 ALB를 지나 각 노드의 Skipper 인그레스로 들어오고, Skipper는 API 서버에서 받은 라우트로 앱 파드에 요청을 보낸다. API 서버가 죽자 Skipper가 라우트를 받을 곳이 사라졌고, 클러스터 인그레스를 지나는 고객 트래픽이 영향을 받았다.
원인 ? 용량 한계
–
ALB는 등록된 호스트가 모두 unhealthy를 보고하면 모든 호스트로 트래픽을 보낸다. 인그레스는 API 서버에 문제가 생겨도 healthy 상태를 유지해야 하고, 마지막으로 받은 라우트 목록을 계속 써야 한다. 파드 수에는 ResourceQuota로 상한을 걸어 둔다.
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 인그레스 컨트롤러
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버