IL-0034 Airbnb · 2019-11-22 (게시일)kubernetesobservability
Airbnb 의 Melanie Cebula 와 Bruce Sherrod 가 발표 "10 Weird Ways to Blow Up Your Kubernetes"에서 소개한 장애 열 가지 가운데 하나다. Airbnb 는 파드마다 서비스 컨테이너 옆에 로깅, 트레이싱, 메트릭 수집 같은 사이드카를 함께 두고 운영했다. 서비스 디스커버리에는 2013년에 오픈소스로 공개한 SmartStack 을 썼다.
쿠버네티스의 헬스 체크는 컨테이너마다 따로 건다. 레디니스 프로브가 실패하면 그 파드로 트래픽을 보내지 않고, 라이브니스 프로브가 실패하면 컨테이너를 교체한다. 대부분의 서비스는 두 프로브를 모두 /health 로 설정했다. 팀은 중요하지 않은 컨테이너가 서비스 상태를 좌우하면 안 된다고 보고 이 컨테이너들에 프로브를 설정하지 않았다. 하지만 크래시한 컨테이너는 프로브가 없어도 레디니스 검사에 실패한다는 사실을 몰랐다.
당시 서비스 메시 로직은 파드의 컨테이너를 하나씩 확인해서 하나라도 준비되지 않았으면 파드 전체를 준비되지 않은 것으로 판단했고, 준비된 파드만 트래픽을 받도록 등록했다. 예정된 작업으로 메트릭 에이전트를 업그레이드하다가 이 에이전트 컨테이너가 크래시하자 레디니스 검사에 실패했다. 그 결과 클러스터의 모든 파드가 준비되지 않은 상태가 되어 서비스가 트래픽을 받지 못했다. 발표는 장애를 어떻게 끝냈는지, 얼마나 걸렸는지는 말하지 않는다.
쿠버네티스의 메트릭 에이전트를 업그레이드하는 작업이 예정되어 있다는 공지가 나갔다. 공지에는 몇 분 동안 서비스가 메트릭을 쓰지 못할 수 있다고 적혀 있었다. 몇 분 뒤 한 서비스 담당자가 자기 쿠버네티스 서비스가 지금 모두 내려간 것 같다는 메시지를 보냈다.
업그레이드 중 메트릭 에이전트 컨테이너가 크래시했고, 이 컨테이너가 레디니스 검사에 실패했다. 서비스 메시 로직은 컨테이너 하나라도 준비되지 않으면 파드 전체를 준비되지 않은 것으로 보고 트래픽 대상에서 뺐다. 그래서 클러스터의 모든 파드가 준비되지 않은 상태가 되어 트래픽을 받지 못했다.
팀은 이 장애 전에 이미 메트릭 에이전트 때문에 서비스가 내려가면 안 된다고 정해 두었다. 그래서 로깅, 트레이싱, 메트릭 같은 중요하지 않은 컨테이너에는 프로브를 설정하지 않았고, 이 컨테이너들은 서비스 상태에 영향을 주지 않는다고 생각했다.
원인 ? 배포 결함
작업 공지가 나가고 몇 분 뒤 서비스 담당자가 자기 쿠버네티스 서비스가 모두 내려간 것 같다는 메시지를 보내와서 알았다.
–
헬스 체크는 컨테이너마다 걸리므로 파드 안의 각 컨테이너가 파드 전체의 준비 상태에 어떻게 영향을 주는지 따져서 설정해야 한다. 프로브를 설정하지 않은 사이드카도 크래시하면 준비되지 않은 상태가 된다.
같은 원인 · 공통 텔레메트리 에이전트
같은 원인 · 공통 텔레메트리 에이전트