사례28건

28건 중 6~10번째

1. IL-0118 쿠버네티스 네임스페이스 라벨을 전역으로 바꾸자 네트워크 계층이 메타데이터를 다시 계산하면서 가장 큰 GPU 클러스터들 가운데 세 곳의 컨트롤 플레인이 과부하에 빠졌고, ChatGPT 와 API 가 타임아웃과 503 오류를 냈다.

   OpenAI2024

   증상

   2024년 11월 25일 태평양 시각 오전 10시 15분부터 API 와 ChatGPT 트래픽의 상당 부분이 타임아웃과 503 오류로 실패했다.

   오류율 상승지연 시간 증가컨트롤 플레인 무응답

   촉발

   쿠버네티스 네임스페이스 라벨을 전역으로 바꿨고, 이 변경 때문에 네트워크 계층이 의도치 않게 메타데이터를 다시 계산했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   과도한 영향 범위디버그 접근 제한

   조치

   • 영향받은 클러스터에서 워크로드를 손으로 빼냈다. 컨트롤 플레인이 응답하지 않아 이 작업이 더 복잡했다.
   • 클라우드 업체와 함께 컨트롤 플레인 노드 수를 늘리고 동시에 데이터 플레인 노드 수를 줄여 컨트롤 플레인을 회복시켰다.

   후속 조치

   • 같은 장애가 다시 나지 않도록 네임스페이스 변경을 잠갔다.
   • 일부 종류의 인프라 배포를 동결했다.
   • 같은 종류의 장애가 반복되지 않도록 신원을 허용 목록으로 관리한다.
   • 가능한 경우에는 트래픽이 자동으로 다른 곳으로 더 잘 옮겨 가도록 GPU 로드 밸런싱 로직을 고친다.
   • 플릿 전체에 걸친 인프라 변경을 관리하는 방식을 개선한다.

   사례 보기
2. IL-0084 베어메탈 업체 vSwitch 의 패킷 드롭으로 Namespace 의 fra3 리전이 빠져 전 세계 용량이 모자랐고, 다음 날에는 컨트롤 플레인 노드의 느린 NVMe 쓰기로 쿠버네티스 API 서버 CPU 가 치솟아 zrh1 이 멈췄다.

   Namespace2024

   증상

   10월 17일부터 fra3 리전에서 패킷이 드문드문 버려지기 시작했다. 처음 이틀은 TCP 와 QUIC 의 재전송이나 컨트롤 플레인의 재시도로 대부분 넘어갔지만, 시스템이 조금씩 불안정했다. 이런 실패는 비결정적이라 겉으로 잘 드러나지 않았다.

   간헐적 연결 실패지연 시간 증가컨트롤 플레인 지연서비스 중단

   촉발

   fra3 에서 베어메탈 업체의 vSwitch 를 지나는 패킷이 무작위로 드문드문 버려지기 시작했다. 두 번째 장애는 컨트롤 플레인 노드 하나의 느린 NVMe 가 쿠버네티스의 변경 속도를 더는 따라가지 못하면서 일어났다.

   원인

   클라우드 제공자 장애

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   용량 계획 부재여유 용량 부재장애 중첩

   감지

   패킷 드롭은 비결정적이라 바로 보이지 않았다. 주요 상호작용에 잡아 둔 백분위 지연 SLO 의 에러 버짓이 줄어드는 것을 보고 영향을 알아챘다.

   조치

   • fra3 의 고객 트래픽을 모두 다른 리전으로 돌렸다.
   • vSwitch 대신 Wireguard 로 업체의 물리 머신 하나하나를 zrh1 클러스터에 연결했다.
   • 각 머신을 새 신원, 새 인증서, 새 저장 데이터 암호화 키로 다시 깔았고, 복구를 앞당기려고 캐시를 버렸다.
   • 팀 일부가 데이터셋을 더 분산된 방식으로 복제해 머신을 다시 까는 작업을 앞당겼다.
   • 준비된 머신을 묶음으로 새 리전에 넣고, 충분히 모이자 리전을 컴퓨트 풀에 다시 넣었다.
   • 두 번째 장애에서 워크로드를 zrh1 밖으로 돌렸다.
   • 실패하던 컨트롤 플레인 노드의 핵심 상태를 더 큰 노드로 복제하고, 새 노드가 같은 IP 주소로 옛 노드의 역할을 넘겨받게 했다.

   후속 조치

   • 장애 동안 실행된 모든 인스턴스의 요금을 고객에게 크레딧으로 환급했다.
   • 비슷한 상황이 다시 와도 고객에게 영향을 주지 않도록 백업 리전과 대안을 만든다.

   교훈

   비결정적인 네트워크 드롭은 재시도에 가려져서 SLO 기반 모니터링으로 긴 시간을 봐야 영향이 드러난다. 핵심 인프라의 문제를 직접 고칠 수단을 갖고 있어야 한다. 큰 장애 직후에는 같은 종류의 원인에 매이기 쉽다. 이번 두 번째 장애는 전혀 다른 종류였다. 미리 해 둔 모의 위기 훈련 덕분에 대응을 바로 체계적으로 시작할 수 있었다.

   사례 보기
3. IL-0154 SFO3 코어 라우터의 라인 카드가 하드웨어 오류로 한꺼번에 재부팅된 뒤 게스트 네트워킹이 돌아오지 않은 DOKS 노드가 비정상으로 남아, 일부 클러스터의 연결과 컨트롤 플레인 접속이 01:40 UTC까지 불안정했다.

   DigitalOcean2024

   증상

   2024년 9월 25일 22:25 UTC부터 SFO3 리전의 DigitalOcean 서비스 전반에서 네트워크 연결 문제가 생겼다. 리전 전체 서비스는 22:50에 회복됐지만 일부 Managed Kubernetes 클러스터는 그 뒤에도 연결이 불안정했다.

   노드 NotReady컨트롤 플레인 무응답간헐적 연결 실패

   촉발

   SFO3 코어 라우터 한 대에서 하드웨어 오류로 라인 카드 대부분이 동시에 재부팅됐다.

   원인

   DNS·네트워크 장애

   구성 요소

   쿠버네티스 API 서버kubelet

   기여 요인

   –

   조치

   • 죽었던 라인 카드가 모두 빠르게 다시 올라와 네트워크 트래픽이 다시 흐르고 코어 라우터가 정상으로 돌아왔다.
   • SFO3 리전 DOKS 전체에서 영향받은 노드를 손으로 모두 재생성했다.

   후속 조치

   • 장비 벤더 지원팀과 함께 라인 카드가 죽은 근본 원인을 찾는다.
   • SFO3 리전 코어 라우터의 소프트웨어를 업그레이드한다.
   • 자동 복구 조치의 임계값을 높여 사람이 손으로 노드를 복구해야 하는 일을 줄인다.

   교훈

   네트워크가 몇 분 만에 돌아와도 게스트 네트워킹이 회복되지 않은 노드는 사람이 재생성할 때까지 비정상으로 남았다. 리전 전체 서비스는 25분 만에 돌아왔지만 DOKS 는 01:40까지 영향을 받았다. 자동 복구 조치가 이 경우를 처리하지 못해 SFO3 DOKS 전체에서 수동 작업이 필요했다.

   사례 보기
4. 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 공간을 차지하는지 찾을 수 있다.

   사례 보기
5. IL-0168 새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다.

   Scaleway2024

   증상

   2024년 2월 13일 01:04 CET 에 FR-PAR 리전의 Kubernetes API 에서 RAM 과 CPU 사용량이 치솟아 OOM 이 났다. 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 상태가 됐다.

   노드 NotReady컨트롤 플레인 지연OOMKilled

   촉발

   2월 12일 새 쿠버네티스 릴리스가 모든 사용자에게 나온 뒤, 12일에서 13일로 넘어가는 밤에 많은 클러스터가 동시에 자동 업그레이드를 시작했다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   재시도 폭주자동화 증폭단계적 배포 부재

   감지

   타임라인의 첫 기록은 01:04 CET 다. 이때 Kubernetes API 의 RAM 과 CPU 사용량이 치솟아 OOM 이 났고, 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 가 됐다. 기록된 첫 조치는 42분 뒤인 01:46 에 API 자원을 늘린 일이었다.

   조치

   • Kubernetes API 에 배정한 자원을 01:46 과 02:20 두 차례 늘렸다.
   • 02:30 에 API 트래픽을 제한해 들어오는 트래픽을 고르게 만들고 혼잡을 줄였다.
   • 03:20 부터 트래픽 제한을 50-100 개 배치로 나눠 차례로 풀어 노드들이 다시 인증하고 "Ready" 가 되게 했다.
   • 03:40 에 API 혼잡 중에 만들어진 고장 노드를 교체하는 스크립트를 돌렸다.
   • 15:45 부터 노드 인증이 한꺼번에 몰리지 않게 일부 클러스터부터 예전 인증 방식으로 차례로 롤백했고, 2월 19일 모든 클러스터에서 롤백을 마쳤다.
   • 노드 인증이 동시에 몰릴 수 있는 클러스터 업그레이드와 설정 갱신 기능을 2월 20일 10:30 까지 껐다.

   후속 조치

   • Kubernetes API 자원 배정을 늘렸다.
   • 예전 인증 방식으로 롤백했다.
   • 노드에 로컬 인증 캐시를 둔다.
   • 부하가 치솟을 때 더 잘 버티도록 자원 배정 전략을 다시 짠다.
   • 쿠버네티스에 새 요청 큐잉 방식을 넣는다.
   • 높은 부하나 장애가 다른 구성 요소로 번지지 않게 구성 요소를 서로 분리한다.
   • 몇몇 지표를 꼼꼼히 지켜봐 이상 패턴을 더 일찍 찾는다.
   • 이 기간에 노드를 배포했지만 제대로 쓰지 못한 고객에게 환불한다.

   교훈

   고객의 클러스터와 노드가 빠르게 늘면서 기존 트래픽 제어로는 혼잡을 막기 어려워졌다. 많은 클러스터의 자동 업그레이드가 한 번에 시작되면 Kubernetes API 에 부하가 몰리고, 계속 실패하고 재시도하는 노드 인증 방식이 혼잡을 더 키운다. 1월 24일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.

   사례 보기

원인별9