사례2건

2건 중 1~2번째

1. IL-0034 메트릭 에이전트 사이드카가 업그레이드 중 크래시하자 클러스터의 모든 파드가 준비되지 않은 상태가 되어 서비스가 트래픽을 받지 못했다

   Airbnb2019

   증상

   쿠버네티스의 메트릭 에이전트를 업그레이드하는 작업이 예정되어 있다는 공지가 나갔다. 공지에는 몇 분 동안 서비스가 메트릭을 쓰지 못할 수 있다고 적혀 있었다. 몇 분 뒤 한 서비스 담당자가 자기 쿠버네티스 서비스가 지금 모두 내려간 것 같다는 메시지를 보냈다.

   프로브 실패서비스 중단

   촉발

   예정된 작업으로 쿠버네티스의 메트릭 에이전트를 업그레이드하던 중, 파드마다 들어 있던 메트릭 에이전트 사이드카 컨테이너가 크래시했다.

   원인

   배포 결함

   구성 요소

   텔레메트리 에이전트서비스 디스커버리

   기여 요인

   미검증 가정과도한 영향 범위

   감지

   작업 공지가 나가고 몇 분 뒤 서비스 담당자가 자기 쿠버네티스 서비스가 모두 내려간 것 같다는 메시지를 보내와서 알았다.

   후속 조치

   • 로깅, 트레이싱, 메트릭 에이전트처럼 파드 준비 상태 판단에 넣지 않을 컨테이너를 중요하지 않은 컨테이너로 표시하고, 서비스 메시 로직이 파드 준비 상태를 판단할 때 이 컨테이너들을 건너뛰게 했다. 발표자는 이것을 임시 해결책이라고 했고 다른 방법도 검토했다고 했다.

   교훈

   헬스 체크는 컨테이너마다 걸리므로 파드 안의 각 컨테이너가 파드 전체의 준비 상태에 어떻게 영향을 주는지 따져서 설정해야 한다. 프로브를 설정하지 않은 사이드카도 크래시하면 준비되지 않은 상태가 된다.

   사례 보기
2. IL-0051 외부 업체의 로그 클라이언트가 새 컨테이너가 뜰 때마다 파일 디스크립터를 다시 열고 이전 것을 닫지 않아 쿠버네티스 노드가 too many open files 로 내려갔다

   thredUP2018

   증상

   쿠버네티스 마이그레이션이 순조로워 보이던 중 Datadog 에서 노드의 열린 파일 수가 계속 늘어나는 것이 보였다.

   서비스 중단파일 디스크립터 고갈

   촉발

   로그 파일을 쓰는 컨테이너가 여럿 떠 있는 노드에 새 컨테이너가 뜰 때마다, 외부 업체의 로그 클라이언트가 기존 로그 파일의 파일 디스크립터까지 새로 열고 이전 디스크립터를 닫지 않았다.

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트

   기여 요인

   미검증 가정

   감지

   Datadog 에서 노드의 열린 파일 수가 계속 오르는 것을 보고 알았다.

   조치

   • 문제가 난 노드를 죽이고 새 노드를 띄운 뒤 서비스를 다시 배포해 복구했다.

   후속 조치

   • 업체와 함께 문제를 다뤘고, 결국 그 로그 수집 업체의 서비스를 쓰지 않게 됐다.

   교훈

   EC2 에서 믿고 쓰던 서비스와 라이브러리가 쿠버네티스에서도 똑같이 잘 동작한다고 가정하면 안 된다. 그런 도구는 배포 방식과 수명 주기가 다른 환경을 전제로 만들어졌을 수 있다. 쿠버네티스에서는 배포할 때마다 컨테이너가 생기고 사라지고 노드 사이를 옮겨 다니므로, 쓰는 서비스마다 이런 수명 주기에 맞게 만들어졌는지 의심하고 확인해야 한다.

   사례 보기

원인별2