사례14건

14건 중 9~13번째

1. IL-0163 자동 테스트가 잡지 못한 API 변경이 배포돼 LKE 클러스터 크기를 바꿀 때 노드가 잘못된 수만큼 만들어졌고, 고객 계정에 과금되는 노드가 늘었다

   Linode2023

   증상

   2023년 5월 31일 16시 UTC 무렵부터 일부 고객의 LKE 클러스터 크기가 예상하지 못한 방식으로 바뀌었다. 클러스터 크기를 조정하면 잘못된 수의 노드가 만들어졌고, 고객 계정에 과금되는 자원이 추가됐다.

   오토스케일러 오동작

   촉발

   5월 31일 16시 UTC 무렵 LKE 클러스터를 잘못 스케일링하게 만드는 API 변경이 운영에 배포됐다. 자동 테스트에 빈틈이 있어 이 실패를 잡지 못했다.

   원인

   배포 결함

   구성 요소

   노드 풀

   기여 요인

   자동 테스트 공백

   감지

   Linode 는 6월 1일 05시 07분 UTC 에 LKE 클러스터 크기를 조정하면 잘못된 수의 노드가 생기는 문제를 알고 있다고 공지했다. 변경이 나간 지 약 13시간 뒤였다.

   조치

   • 6월 1일 05시 07분 UTC 고객에게 가능하면 클러스터 크기 조정을 피하라고 안내했다.
   • 09시 40분 UTC 잘못된 스케일링을 바로잡는 핫픽스를 적용했다.
   • 고객 워크로드에 영향을 주지 않도록 늘어난 워커 노드를 지우지 않고 그대로 두었다.
   • 영향받은 고객에게 티켓으로 요금 조정과 추가 조치 방법을 알렸다.

   후속 조치

   • 자동 테스트를 점검한다.
   • 같은 일이 다시 일어나지 않도록 배포 전 체크리스트 항목을 추가했다.

   교훈

   자동 테스트가 잡지 못한 API 변경 하나가 고객 클러스터의 노드 수를 바꾸고 요금까지 늘렸다. Linode 는 테스트를 점검하고 배포 전 체크리스트를 늘리는 것으로 대응했다. 잘못 늘어난 노드라도 지우면 고객 워크로드에 영향을 줄 수 있어서, Linode 는 노드를 지우지 않고 요금 조정으로 보정했다.

   사례 보기
2. IL-0164 이전 릴리스의 변경이 빠진 LKE 운영 업데이트 때문에 클러스터 업그레이드와 노드 추가가 오류 없이 실패했다

   Linode2022

   증상

   2022년 6월 15일 18:30 UTC 무렵부터 LKE 고객이 클러스터를 업그레이드하거나 노드를 추가하려 하면 작업이 아무 오류 없이 실패했다. 19:54 UTC 에 상태 페이지에 LKE 문제를 조사 중이라는 공지가 올라왔다. 영향을 받은 곳은 US-East 뉴어크, US-Central 댈러스, US-West 프리몬트, US-Southeast 애틀랜타, CA-Central 토론토, EU-West 런던, EU-Central 프랑크푸르트, AP-South 싱가포르, AP-Northeast 도쿄 2, AP-West 뭄바이, AP-Southeast 시드니 리전의 LKE 였다.

   업그레이드 정체

   촉발

   6월 15일 18:30 UTC 무렵 LKE 운영 환경에 증분 업데이트를 배포했고, 이 업데이트에는 이전 릴리스의 변경이 빠져 있었다.

   원인

   배포 결함

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   상태 페이지 첫 공지는 업데이트 배포 약 1시간 24분 뒤인 19:54 UTC 에 올라왔다.

   조치

   • 빠진 변경을 다음 업데이트에 넣어 21:00 UTC 무렵 배포했다.

   후속 조치

   • 같은 문제를 막으려고 업데이트 절차에 단계와 자동화를 더했다.

   사례 보기
3. IL-0086 테스트 Kubernetes 클러스터용 배포가 운영 클러스터의 Traefik 과 Calico 리소스까지 지워 CircleCI UI 와 runner.circleci.com 이 1시간 54분 동안 내려갔다.

   CircleCI2021

   증상

   2021년 3월 11일 15:35 EST 에 CircleCI UI 에 접속할 수 없게 됐다. API 는 별도 인그레스로 들어오기 때문에 계속 응답했고 빌드도 계속 돌았다.

   서비스 중단리소스 삭제

   촉발

   테스트 Kubernetes 클러스터를 대상으로 한 배포가 테스트 클러스터와 운영 클러스터 양쪽에서 Traefik 과 Calico 리소스를 지웠다.

   원인

   배포 결함

   구성 요소

   인그레스 컨트롤러Calico

   기여 요인

   과도한 영향 범위런북 부재모니터링 사각지대

   감지

   알림을 받은 엔지니어들이 조사를 시작했다. 상태 페이지에는 20:45 UTC 에 첫 공지가 올라왔다.

   조치

   • 지워진 Traefik 을 복구했다.
   • Calico 를 복구해 운영 클러스터의 파드가 다시 고객 요청을 처리하게 했다.

   후속 조치

   • Kubernetes 네트워크의 여러 계층을 모두 다루도록 네트워크 수준 문서와 런북을 보강한다.
   • 네트워크 인프라 쪽 모니터링과 알림을 개선했다.
   • 운영 클러스터와 스테이징 클러스터가 서로 간섭하지 않도록 둘을 더 확실히 떼어 놓는 안전장치를 추가한다.

   교훈

   테스트 클러스터용 배포가 운영 클러스터의 리소스를 건드릴 수 있으면 스테이징 작업이 곧 운영 장애가 된다. 스테이징 배포가 운영에 영향을 줬다는 사실이 바로 보이지 않아 조사가 DNS 와 AWS 에서 시작됐다. Traefik 만 되살려서는 복구되지 않았고 Calico 와 Traefik 의 관계까지 알아야 했다. CircleCI 는 Kubernetes 네트워크의 모든 계층을 담은 문서와 런북이 필요하다고 정리했다.

   사례 보기
4. IL-0088 팀별 ingress 컨트롤러 모듈 0.1.0 이 만든 검증 웹훅이 live-1 클러스터에서 새 Ingress 생성을 모두 x509 오류로 막았다

   UK Ministry of Justice2020

   증상

   2020-09-07 12:39 에 Cloud Platform 의 live-1 클러스터에서 새 Ingress 규칙이 만들어지지 않는 문제가 처음 감지되었다. Ingress API 가 POST 요청을 100% 거부하고 있었다.

   배포 실패

   촉발

   팀별 ingress 컨트롤러 모듈 0.1.0 은 ValidatingWebhookConfiguration 리소스를 만들도록 바뀌었다. live-1 클러스터에서는 새 0.1.0 컨트롤러 하나가 AWS 리소스 한도에 걸려 만들어지지 않았다.

   원인

   배포 결함

   구성 요소

   어드미션 웹훅인그레스 컨트롤러

   기여 요인

   단일 장애점

   감지

   문제는 2020-09-07 12:39 에 처음 감지되었다. 확인해 보니 Ingress API 가 POST 요청을 100% 거부하고 있었다. 팀은 Slack 스레드에서 조사를 시작했고 12:54 에 장애를 선언했다.

   조치

   • 0.1.0 이 만든 추가 admission 컨트롤러를 손으로 모두 지웠다.
   • 모듈에서 admission 웹훅을 빼고 새 릴리스 0.1.1 을 냈다.
   • 0.1.0 을 쓰던 ingress 모듈을 모두 0.1.1 로 올렸다.

   교훈

   검증 웹훅을 켜는 옵션 하나가 네임스페이스에 있는 ingress 컨트롤러 파드 전체의 단일 장애점이 되었다. 컨트롤러 하나가 뜨지 못하자 그 웹훅이 클러스터 전체의 새 Ingress 생성을 막았다.

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

   Airbnb2019

   증상

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

   프로브 실패서비스 중단

   촉발

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

   원인

   배포 결함

   구성 요소

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

   기여 요인

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

   감지

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

   후속 조치

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

   교훈

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

   사례 보기

원인별1