사례2건

2건 중 1~2번째

1. IL-0077 Kyverno 1.12 가 만든 ephemeralreports 객체가 쌓여 EKS 의 etcd 데이터베이스가 한도를 넘었고 운영 클러스터가 읽기 전용이 되어 모든 쓰기가 거부됐다

   Marcin Cuber2024sev1

   증상

   운영 EKS 클러스터가 읽기 전용 상태가 됐다. etcd 데이터베이스 공간이 한도를 넘자 API 서버가 새 파드 생성이나 디플로이먼트 스케일 조정처럼 객체를 바꾸는 요청을 모두 거부했다. 글쓴이는 이를 P1 장애로 다뤘다.

   컨트롤 플레인 무응답컨트롤 플레인 지연

   촉발

   Kyverno 1.12 가 ephemeralreports 객체를 너무 많이 만들어 etcd 에 쌓았다.

   원인

   소프트웨어 결함

   구성 요소

   etcd쿠버네티스 API 서버정책 엔진

   기여 요인

   한계 경보 부재디버그 접근 제한

   감지

   클러스터가 읽기 전용이 되어 쓰기 요청이 거부되면서 드러났다. 글쓴이는 kube-apiserver 감사 로그에서 mvcc: database space exceeded 를 찾는 CloudWatch Logs Insights 쿼리로 오류가 처음 나온 시각을 확인하는 방법을 소개했다.

   조치

   • AWS 의 EKS 팀과 etcd 팀이 8GB 와 10GB 이던 etcd 저장 공간을 12GB 로 늘려 잠금을 풀었다.
   • AWS 엔지니어가 여러 승인을 거친 뒤, 정리되지 않고 쌓인 ephemeralreports 객체를 etcd 에서 직접 지웠다.

   후속 조치

   • apiserver_storage_size_bytes 지표로 etcd 데이터베이스 크기를 모니터링해 8GB 한도에 닿지 않게 한다.
   • Kyverno 1.12 를 쓰고 있다면 ephemeralreports 가 쌓이는 문제를 고친 v1.12.4 로 업그레이드한다. ephemeralreports 가 계속 생기면 admission 이벤트 보고를 끄거나 --aggregationWorkers 를 늘린다.

   교훈

   EKS 의 etcd 데이터베이스 한도는 8GB 다. 한도를 넘으면 클러스터가 읽기 전용이 되고, 컴팩션도 막혀 객체를 지워 공간을 되찾을 수 없다. 글쓴이가 관찰한 바로는 객체를 지우는 스크립트도 etcd 가 잠기기 전에만 통한다. 그러므로 etcd 크기를 모니터링하고 8GB 에 절대 닿지 않게 해야 한다. EKS 에서는 etcd 에 직접 접근할 수 없어 잠긴 etcd 를 스스로 풀 수 없다. AWS 지원팀에 의존해야 하고, 해결 방법을 알아도 실행되기까지 오래 걸릴 수 있다. apiserver_storage_objects 지표로 리소스 종류별 객체 수를 보면 무엇이 etcd 공간을 차지하는지 찾을 수 있다.

   사례 보기
2. IL-0113 한 번도 교체되지 않은 GKE API 서버 인증서 때문에 메인 클러스터의 컨트롤 플레인이 망가져 EU 리전의 백엔드 API, 프런트엔드, 터널이 모두 멈췄다

   Webhook Relay2022

   증상

   2022년 5월 10일 낮 12시 EST 에 헬스체크 시스템이 경보를 울렸다. EU 리전의 백엔드 API, 프런트엔드, 터널이 모두 내려가 있었다. 처음에는 클라이언트 쪽에서 요청이 끊겼거나, 메모리나 CPU 사용량 때문에 축출된 서버에 요청이 닿은 일시적 오류라고 생각했다. 메인 대시보드가 내려간 것을 보고 바로 대응을 시작했다.

   서비스 중단컨트롤 플레인 지연컨트롤 플레인 무응답API 조회 결과 불일치자격 증명 획득 실패

   원인

   인증서·자격 증명 만료

   구성 요소

   GKE 컨트롤 플레인쿠버네티스 API 서버노드 풀RBAC 와 서비스 어카운트

   기여 요인

   디버그 접근 제한단일 장애점

   감지

   헬스체크 시스템이 서비스가 내려갔다는 첫 알림을 보냈다. 팀은 처음에 일시적 오류로 보고 자동 복구를 기대했지만, 메인 대시보드가 내려간 것을 확인하고 바로 대응을 시작했다.

   조치

   • 인증서 교체가 노드를 다시 만들지 않아 13시 20분 노드 풀을 손으로 다시 만들었다.
   • 14시 30분에는 이미 메인 클러스터의 서비스를 새로 만든 GKE 클러스터에 복제하고 있었다.
   • 16시 50분 기존 클러스터에서 쿠버네티스 Service 레코드를 지워 로드 밸런서를 새 클러스터에 붙일 수 있게 했다.
   • 17시 30분 StatefulSet 을 기존 클러스터에서 떼어 내고 모든 쓰기를 메인 디스크로 돌렸다.
   • 18시 30분 임시 ClickHouse 인스턴스의 데이터를 내보내 메인 인스턴스에 다시 넣었다.

   후속 조치

   • 디스크 데이터를 복잡하게 옮기지 않고도 클러스터 사이를 빠르게 바꿀 수 있도록 배포 매니페스트를 고쳤다.

   교훈

   기존 인프라를 살리는 작업에는 시간 상한을 정해야 한다. 장애 내내 서비스가 곧 살아날 것처럼 보였지만, 기존 클러스터를 훨씬 일찍 포기하고 새 클러스터에서 다시 시작했어야 했다. 이미 들인 노력이 아까워 살리기를 멈추지 못한 것이 판단을 늦췄다. 오래된 GKE 클러스터라면 클러스터 CA 인증서의 유효기간을 `gcloud container clusters describe <cluster name> --zone europe-north1-a --format "value(masterAuth.clusterCaCertificate)" | base64 --decode | openssl x509 -text | grep Validity -A 2` 로 확인할 수 있다.

   사례 보기

원인별2