사례20건

20건 중 16~20번째

1. 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 생성을 막았다.

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

   Airbnb2019

   증상

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

   프로브 실패서비스 중단

   촉발

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

   원인

   배포 결함

   구성 요소

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

   기여 요인

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

   감지

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

   후속 조치

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

   교훈

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

   사례 보기
3. IL-0149 2019-09-28 07:20 UTC 이전에 만든 VMSS 기반 AKS 클러스터의 업그레이드가 PlatformImageNotFound 오류로 실패했다.

   Microsoft Azure2019

   증상

   2019-09-28 07:20 UTC 부터 Virtual Machine Scale Sets 위의 AKS 클러스터에서 클러스터 업그레이드를 시도하면 실패 알림이 왔다.

   업그레이드 정체

   촉발

   최근 서비스 업데이트가 백엔드 서비스의 인스턴스를 비정상 상태로 만들어 요청이 끝나지 못했다. 이 상태에서 고객이 클러스터 업그레이드를 시도했다.

   원인

   배포 결함

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   –

   감지

   고객은 클러스터를 업그레이드하려 할 때 실패 알림을 받았다.

   조치

   • az vmss update 명령으로 스케일 세트 이미지의 version 을 "2019.09.25" 로, Sku 를 "aks-ubuntu-1604-201909" 로 바꾼 뒤 업그레이드를 다시 실행하는 방법을 공개했다.
   • AKS 팀과 VMSS 팀이 영향받은 클러스터를 손으로 완화했다.
   • 모든 리전에 핫픽스를 배포해 2019-10-15 에 마쳤다.

   사례 보기
4. IL-0467 Prow 빌드 클러스터의 노드 업그레이드 중 Boskos 파드가 크래시 루프에 빠져 GCP 프로젝트가 필요한 테스트 작업이 9시간 넘게 모두 실패했다

   Kubernetes project2019

   증상

   Boskos 에서 GCP 프로젝트를 받아야 하는 Prow 테스트 작업이 밤사이 전부 실패했다. kubernetes/kubernetes 의 모든 PR 에 필수인 pull-kubernetes-e2e-gce 가 계속 실패해서 PR 을 하나도 병합할 수 없었다.

   컨테이너 재시작 반복서비스 중단

   촉발

   Prow 클러스터를 쿠버네티스 1.11 에서 1.13 으로 올리는 노드 업그레이드 중 23:04 에 Boskos 파드 하나가 돌던 노드가 drain 됐다. 새 노드에서 다시 만들어진 Boskos 파드는 StatefulSet 스펙에 적힌 새 이미지로 시작했는데, 이 이미지에 버그가 있었다.

   원인

   배포 결함

   구성 요소

   CI 시스템노드 풀

   기여 요인

   늦게 드러난 변경미검증 가정단일 장애점한계 경보 부재업무 종료 직전에 시작한 변경

   감지

   알림은 울리지 않았다. Boskos 대시보드에는 실패가 뚜렷하게 보였지만 이를 잡는 알림이 없었다. 사용자들이 02:50 에 GitHub 로, 05:16 과 06:27 에 Slack 으로 장애를 알렸고, 담당자는 07:16 에 일어나 Slack 의 보고를 보고서야 알았다.

   조치

   • 버그를 찾은 뒤 고친 Boskos 이미지를 새로 빌드해 배포했고, Boskos 는 곧바로 살아났다.
   • 장애 동안 반납되지 않고 열린 채로 남은 GCP 프로젝트들을 그 뒤 몇 분에 걸쳐 정리했다.

   후속 조치

   • Boskos 설정을 고쳐 배포하면 실제로 파드가 교체되게 한다.
   • Boskos 배포를 자동화한다.
   • Boskos 상태를 지켜보는 알림을 개선한다.

   교훈

   팀은 당직자가 오후 6시까지만 있는 날 오후 5시가 넘어 10시간짜리 배포를 시작하지 말았어야 했다고 보았다. 배포는 실제로 무언가가 바뀌었는지 확인할 수 있게 지켜봐야 하고, 그럴 수 없으면 아예 하지 않아야 한다고 정리했다. Boskos 의 StatefulSet 은 업데이트하도록 설정되어 있지 않아서 배포해도 아무것도 바뀌지 않았다. 12월의 변경은 한 번도 시험되지 않은 것으로 보였다. Prow 의 다른 부분과 달리 Boskos 는 손으로 배포해서 실수할 여지가 컸다. 담당자가 대응을 시작한 뒤로는 문제를 비교적 빨리 풀었다.

   사례 보기
5. IL-0466 Prow 가 테스트 작업을 서비스 클러스터에 스케줄해 작업이 뜨지 못하고 Prow 전체가 느려졌다

   Kubernetes project2019

   증상

   16:04 PST 에 Prow 의 응답이 매우 느려졌다. hook 의 응답이 5분쯤 늦었고 봇 명령이 응답하지 않았으며, /lgtm 과 담당자 지정이 오류를 냈다. 작업은 네트워크 문제로 실패하고 GCS 에 로그를 올리지 못했다.

   파드 Pending노드 CPU 고부하지연 시간 증가

   촉발

   13:20 PST 에 Prow 가 자동으로 만든 버전 올림 PR 이 머지돼 배포가 시작됐다. 새로 들어간 클라이언트 코드 리팩터링이 빌드 클러스터 시크릿에 적힌 "default" 클러스터 별칭을 무시해, Prow 가 작업을 기본 별칭인 서비스 클러스터에 스케줄하기 시작했다.

   원인

   배포 결함

   구성 요소

   CI 시스템

   기여 요인

   스테이징 불일치리소스 요청과 한도 미설정디버그 접근 제한

   감지

   16:04 PST 에 담당자가 PR 을 보다가 cat 명령이 동작하지 않는 것을 알아챘다. githubstatus.com 은 정상이었다. Slack 에서 Prow 노드가 CPU 와 메모리를 100% 넘게 쓰는 것을 찾았고, 이어서 test-pods 네임스페이스에서 시크릿을 찾지 못해 멈춘 Pending 파드 600개를 확인했다.

   조치

   • 16:40 에 Prow 를 버전 올림 이전인 v20190206-b01b288 로 롤백했고, 그사이 서비스 클러스터의 파드와 prowjob 을 모두 지웠다.
   • 직접 배포할 권한이 없어 이슈를 연 뒤, 16:50 에 되돌린 버전을 kubectl apply 로 직접 배포했다. 문제는 계속됐다.
   • 17:25 에 주어진 "default" 클라이언트를 덮어쓰지 않게 하는 수정 PR https://github.com/kubernetes/test-infra/pull/11209 을 올렸다.
   • 17:25 에 결함이 들어가기 전인 v20190125-2aca69d 로 Prow 를 다시 롤백했다.
   • 17:59 에 잘못 스케줄된 파드와 prowjob 을 모두 다시 지우고 Prow 가 정상임을 확인했다.

   후속 조치

   • 이 동작이 왜 비결정적으로 나타나는지 더 알아본다.
   • Prow 를 크게 바꾸는 변경을 배포할 때 더 조심한다. e2e 테스트를 늘리거나 실제 스테이징 Prow 를 둔다.

   교훈

   사람들이 자리에 있어 문제를 적극적으로 찾고 완화했다. 이번에도 금요일 오후에 일어났고, 동작이 비결정적이었다. 실제 스테이징 Prow 가 필요하다. 지금은 OpenShift 의 Prow 가 잘 돌면 쿠버네티스 Prow 를 올려도 안전하다고 보며 서로에게 기댄다. 그러나 빌드 클러스터를 정의하는 방식처럼 Prow 마다 구성이 다르므로, 쿠버네티스 Prow 와 매우 비슷한 스테이징 환경이 있어야 한다. 크게 바꾸는 Prow 변경은 e2e 테스트를 늘리거나 실제 스테이징 Prow 를 두어 더 조심해서 배포해야 한다.

   사례 보기

원인별1