사례13건

13건 중 6~10번째

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-0153 DOKS 1.27.6-do.0 과 1.28.2-do.0 워커 노드에서 매일 아침 도는 apt 자동 업그레이드가 15분 타임아웃에 걸려 강제 종료되면서 노드 네트워킹이 망가지고, 노드가 사흘 연속 NotReady 가 됐다.

   DigitalOcean2023

   증상

   2023년 10월 8일 06:00 UTC 무렵부터 일부 Managed Kubernetes 클러스터의 워커 노드가 NotReady 가 됐고, 그 노드에서 돌던 서비스와 애플리케이션이 멈췄다. 07:43부터 노드를 교체하면 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다.

   노드 NotReady서비스 중단

   촉발

   DigitalOcean Debian 이미지의 systemd 타이머가 매일 06:00 UTC에 최대 60분의 무작위 지연을 두고 apt 업그레이드를 시작했다.

   원인

   설정 변경

   구성 요소

   노드 운영체제 이미지리눅스 커널kubelet

   기여 요인

   기본 설정 방치디버그 접근 제한늦게 드러난 변경

   감지

   10월 8일 07:43 UTC부터 노드 교체로 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다. 장애가 시작되고 약 1시간 43분 뒤였다. 내부 장애 대응은 영향이 여러 리전으로 번진 뒤인 10월 9일 07:10에 시작됐다.

   조치

   • 고객에게 영향받은 머신을 교체하거나 재부팅해 장애를 줄이라고 안내했다.
   • 장애가 없는 동안 워커 노드에 SSH 와 콘솔 접근을 마련했고, 10월 10일 영향받은 노드에 붙어 실시간으로 디버깅했다.
   • 각 워커 노드에서 apt 업그레이드 systemd 타이머를 끄는 DaemonSet 을 만들어 10월 11일 03:08 UTC에 영향받은 모든 클러스터에 배포했다.
   • 자동 업그레이드 과정을 없앤 새 노드 이미지를 배포했다.

   후속 조치

   • 노드 프로비저닝 과정에서 같은 수정을 적용해 워커 노드에 타이머가 처음부터 켜지지 않게 한다. 그 뒤 모든 클러스터에서 DaemonSet 을 지운다.
   • 새 클러스터 버전마다 도는 내부 적합성 테스트에 자동 업그레이드와 원하지 않는 다른 타이머가 꺼져 있는지 확인하는 검사를 넣었다.
   • 평소 쓰는 접근 경로가 막혀도 워커 노드 머신에 로그인할 수 있게 한다.

   교훈

   베이스 이미지에 기본으로 켜진 자동 업그레이드 타이머가 운영 중인 노드에 지원하지 않는 패키지 버전을 들일 수 있다. 업그레이드 중 커널 같은 시스템 패키지가 타임아웃으로 강제 종료되면 노드 네트워킹이 망가질 수 있다. 네트워크가 끊긴 노드에 들어갈 방법이 없으면 깊은 조사는 장애가 없는 시간까지 밀린다. 매일 같은 시각에 반복되고 특정 버전에만 나는 장애는 노드에서 주기적으로 도는 작업을 가리켰다.

   사례 보기
3. IL-0174 Fluent Bit 2.0 으로 올린 로그 수집 사이드카 가운데 Kafka output 플러그인을 쓰는 컨테이너가 SIGSEGV 로 계속 재시작됐다.

   Hyperconnect2023

   증상

   하이퍼커넥트는 운영 Kubernetes 클러스터의 로그 수집 에이전트인 Fluent Bit 를 2.0 으로 올렸다. 사용자 영향이 적은 서비스를 골라 Fluent Bit 사이드카부터 업그레이드하고 며칠 지켜보니, Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되고 있었다.

   컨테이너 재시작 반복

   촉발

   운영 클러스터에서 Fluent Bit 사이드카를 2.0 으로 업그레이드했다. 이 버전의 Kafka output 플러그인은 map 이 아닌 레코드가 들어와도 타입을 확인하지 않고 처리했다.

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트

   기여 요인

   디버그 접근 제한

   감지

   업그레이드 뒤 며칠 동안 모니터링하다가 Kafka output 플러그인을 쓰는 컨테이너만 SIGSEGV 로 재시작되는 것을 발견했다.

   조치

   • produce_message 를 부르기 전에 map 이 아닌 데이터를 건너뛰도록 Fluent Bit Kafka output 플러그인을 고쳤다.
   • 고친 플러그인으로 커스텀 빌드를 만들어 사이드카로 적용했고, segmentation fault 가 사라졌다.
   • 수정 사항을 Fluent Bit 업스트림에 PR 6452 로 냈고, 제출 8일 만에 병합됐다.

   교훈

   Linux 는 segmentation fault 가 나면 core 를 덤프하고, 이 파일을 분석하면 버그를 찾을 수 있다. Kubernetes 환경에서는 core 가 저절로 남지 않으므로 볼륨과 core_pattern 을 미리 잡아 두어야 한다. 직접 분석하기 어려워 core 파일을 다른 사람에게 넘길 때는 조심해야 한다. core 에는 실행 중이던 프로세스의 메모리 일부가 들어 있어 민감 정보가 섞일 수 있다.

   사례 보기
4. IL-0125 Jean Zay 에서 진행한 176B 다국어 모델 학습에서 GPU 가 고장 나도 학습 작업이 끝나지 않고 멈춰 버려 SLURM 이 작업을 자동으로 재시작하지 못했다.

   BigScience2022

   증상

   tr11-176B-ml 학습에서는 대략 일주일에 한 번 GPU 하나가 죽는 하드웨어 문제가 생겼다. 대부분은 SLURM 작업이 자동으로 재시작돼 잃는 학습이 최대 3시간에 그쳤다. 하지만 가끔은 프로세스가 죽었는데도 학습이 멈춘 채 끝나지 않았다.

   학습 작업 실패GPU 인식 불가

   촉발

   Jean Zay 노드의 GPU 하나가 하드웨어 고장으로 죽었는데, 프로세스가 죽은 뒤에도 학습 작업이 종료되지 않고 멈췄다.

   원인

   하드웨어 고장

   구성 요소

   NCCLPyTorchSlurm 작업 스케줄러

   기여 요인

   기본 설정 방치디버그 접근 제한

   감지

   자동으로 알려 주는 수단이 없었다. 학습이 멈춰도 SLURM 작업이 끝나지 않았기 때문에, 누군가 학습을 지켜보다가 알아채야 했다.

   조치

   • 체크포인트 저장 간격을 200 이터레이션으로, 이어서 100 이터레이션으로 줄였다. 설정 값은 SAVE_INTERVAL=100 이다.
   • NCCL_ASYNC_ERROR_HANDLING=1 을 설정해 브로드캐스트 멈춤 같은 NCCL 문제가 생기면 학습이 강제로 죽게 했다.
   • 노드 2개에서 새 작업을 띄우고 프로세스 하나를 손으로 죽여 약 5분 뒤 SLURM 이 작업 전체를 끝내는 것을 확인한 뒤, srun 에 --wait=60 과 --kill-on-bad-exit=1 을 더했다.

   교훈

   Jean Zay 의 SLURM 에는 이미 KillOnBadExit=1 같은 설정이 있었으므로, 실제로 더해진 것은 NCCL_ASYNC_ERROR_HANDLING=1 하나였다. 노드 2개 시험은 새 srun 옵션만 확인했고, 재현하기 까다로운 NCCL 멈춤은 시험하지 못했다. 작성자는 다음 하드웨어 고장 때 제대로 동작하는지 지켜보기로 했다. 체크포인트 저장 간격은 GPU 고장 때 잃는 학습 시간과 저장에 드는 시간을 견주어 정해야 한다.

   사례 보기
5. 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` 로 확인할 수 있다.

   사례 보기

원인별8