사례2건

2건 중 1~2번째

1. IL-0011 HAProxy 인그레스 템플릿이 백엔드 파드를 IP 순으로 정렬해 일부 파드에 요청이 몰리고 인그레스 컨테이너가 OOMKilled 됐다

   Skyscanner2019

   증상

   어느 일요일, 클러스터 사용자 한 명이 지연 시간이 올라갔다며 쿠버네티스 업무 시간 외 지원 담당을 직접 호출했다. 특히 p90 과 최댓값 지연이 높았다.

   지연 시간 증가부하 불균형OOMKilled간헐적 연결 실패

   촉발

   HAProxy 인그레스 컨트롤러를 v0.6 으로 올렸다. v0.5 문서는 sort-backends 플래그의 기본값이 false 이고 백엔드 서버를 기본으로 무작위로 섞는다고 설명했다. 그러나 템플릿이 pod_ip:port 를 키로 하는 맵을 순회할 때 Go 의 text/template 이 키 순서대로 방문해, 파드는 늘 IP 오름차순으로 설정 파일에 들어갔다. 운영 클러스터처럼 변화가 잦은 곳에서는 설정이 자주 다시 쓰였고, HAProxy 가 무중단 리로드를 하지 못해 재시작하는 일이 잦았다. 그때마다 모든 HAProxy 인스턴스가 같은 목록의 처음부터 라운드 로빈을 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러HAProxy설정 템플릿

   기여 요인

   스테이징 불일치미검증 가정초기 신호 무시

   감지

   클러스터 사용자가 p90 과 최댓값 지연이 오른 것을 보고 업무 시간 외 쿠버네티스 지원 담당을 직접 호출했다. 그 전에도 한 사용자가 파드 사이 요청 분포가 고르지 않다고 알렸지만 팀은 우선순위를 낮게 두었다.

   조치

   • 내부 배포 도구 Slingshot 의 설정을 바꿔, 영향받은 서비스의 매니페스트가 파드 IP 대신 Service VIP 를 쓰게 했다.
   • 컨트롤러가 맵에 넣은 순서를 슬라이스에 보관하고 템플릿이 그 슬라이스를 순회하도록 컨트롤러 코드와 설정 템플릿을 패치했다.
   • 패치를 샌드박스 클러스터에서 테스트한 뒤 운영 클러스터에 배포했다.

   후속 조치

   • 컨트롤러 패치를 운영에서 돌리고, 백엔드 주소는 다시 파드 IP 를 기본으로 쓴다.
   • 업스트림 프로젝트에 GitHub 이슈와 PR 을 올려 문제를 알렸다.
   • 클러스터 컴포넌트를 바꿀 때는 구체적인 동작과 조건을 염두에 두고 테스트한다.

   교훈

   클러스터 컴포넌트를 바꿀 때는 특정 동작과 조건을 염두에 두고 테스트해야 한다. 팀은 백엔드 목록이 정렬되면 hot-podding 이 생긴다는 것을 이미 알았지만, 새 플래그가 기대대로 동작하는지 충분히 테스트하지 않았다. 같은 키워드라도 언어의 한 곳에서 동작하는 방식이 다른 곳에서도 같으리라고 기대하면 안 된다. Go 의 range 와 text/template 의 range 는 맵을 순회하는 순서가 달랐다. 쿠버네티스 클러스터의 작은 컴포넌트 하나만 바꿔도 클러스터 사용자와 고객에게 큰 피해를 줄 수 있다.

   사례 보기
2. IL-0031 API 서버가 OOMKill로 죽자 Skipper 인그레스가 라우트를 잃었고, 고객 트래픽이 끊기며 IAM 서비스에서 404 오류가 났다

   Zalando2018

   증상

   고객에게 영향이 간 장애였다. IAM 서비스에서 404 오류가 나기 시작했다.

   오류율 상승컨트롤 플레인 무응답OOMKilled

   촉발

   발표는 문제의 출발점으로 CronJob 매니페스트 하나를 보여 주었다. 이 매니페스트에는 concurrencyPolicy, successfulJobsHistoryLimit, failedJobsHistoryLimit 필드가 CronJob spec이 아니라 파드 템플릿 spec 안에 들어 있었다. 실행 일정은 평일 9시부터 19시까지 15분마다였다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버인그레스 컨트롤러

   기여 요인

   단일 장애점과도한 영향 범위

   조치

   • CronJob 매니페스트를 고쳤다. concurrencyPolicy와 이력 보존 개수 필드를 CronJob spec으로 옮기고, Job에 activeDeadlineSeconds: 120을 넣고, 실행 일정을 바꿨다.

   후속 조치

   • API 서버에 문제가 생겨도 인그레스가 healthy 상태를 유지하도록 고친다.
   • API 서버가 응답하지 않아도 인그레스가 마지막으로 받은 라우트 목록을 계속 쓰도록 고친다.
   • ResourceQuota로 파드 수 상한을 1500개로 둔다.

   교훈

   ALB는 등록된 호스트가 모두 unhealthy를 보고하면 모든 호스트로 트래픽을 보낸다. 인그레스는 API 서버에 문제가 생겨도 healthy 상태를 유지해야 하고, 마지막으로 받은 라우트 목록을 계속 써야 한다. 파드 수에는 ResourceQuota로 상한을 걸어 둔다.

   사례 보기

원인별2