사례4건

4건 중 1~4번째

1. IL-0160 고쳐서 다시 돌린 레거시 GPU 모니터링 스크립트의 펌웨어 조회가 GSP 레이스 컨디션을 일으켜 Linode 의 RTX 4000 Ada GPU 가 잠기고 LKE 워커 노드의 GPU 작업이 멈췄다

   Linode2026

   증상

   2026년 3월 4일 21:00 UTC 무렵부터 NVIDIA RTX 4000 Ada GPU 를 쓰는 Linode 인스턴스가 잠기기 시작했다. 처음에는 Linode Kubernetes Engine 의 워커 노드만 겪는 문제로 보였지만, 나중에 이 하드웨어를 쓰는 모든 Linode 가 영향을 받은 것으로 확인됐다. 일반 컴퓨트 인스턴스와 RTX 4000 이 아닌 GPU 인스턴스는 영향이 없었다.

   GPU 인식 불가컨트롤 플레인 무응답

   촉발

   내부 관측 대시보드에서 빠진 지표를 되살리려고 고장 난 레거시 GPU 모니터링 스크립트를 고쳐 배포했다.

   원인

   배포 결함

   구성 요소

   텔레메트리 에이전트GPU 드라이버

   기여 요인

   리뷰 누락미검증 가정

   감지

   고객은 21:00 UTC 무렵부터 잠김을 겪었고, 상태 페이지 첫 공지는 약 5시간 뒤인 3월 5일 02:07 UTC 에 올라왔다. 처음에는 LKE 워커 노드에서만 생기는 문제로 보였다.

   조치

   • 모든 GPU 에서 문제의 모니터링 스크립트를 껐다.
   • 영향을 받은 노드를 재부팅했다.

   후속 조치

   • 재발을 막을 개선 조치와 예방 조치를 마련한다.

   교훈

   모니터링 스크립트가 자기가 지켜보는 하드웨어를 멈출 수 있다. 빠진 지표 하나를 되살리려던 수정이 이전 세대 GPU 용으로 쓴 펌웨어 조회까지 되살렸다. RTX 4000 Ada 아키텍처에서는 동작 중인 GPU 에 이 조회를 보내면 GPU 가 잠긴다. 스크립트가 모든 GPU 에서 돌았기 때문에 여러 리전에서 이 GPU 를 쓰는 모든 Linode 가 영향을 받았다. 엔지니어들은 처음에 호스트 하이퍼바이저나 GPU 펌웨어의 회귀를 의심했다.

   사례 보기
2. IL-0005 새 텔레메트리 서비스가 모든 노드에서 무거운 쿠버네티스 API 요청을 보내 대형 클러스터의 컨트롤 플레인이 무너졌고, DNS 기반 서비스 디스커버리가 깨져 OpenAI 의 모든 서비스가 멈췄다

   OpenAI2024

   증상

   2024년 12월 11일 오후 3시 13분 PST 에 알림이 울려 엔지니어들에게 전달됐다. 3시 16분부터 ChatGPT, API, Sora 를 포함한 OpenAI 의 모든 서비스가 크게 느려지거나 완전히 멈췄다.

   서비스 중단오류율 상승컨트롤 플레인 무응답DNS 조회 실패

   촉발

   오후 3시 12분 PST 에 쿠버네티스 컨트롤 플레인 지표를 자세히 수집하는 새 텔레메트리 서비스를 배포했다. 이 서비스의 설정 때문에 각 클러스터의 모든 노드가 무거운 쿠버네티스 API 요청을 보냈다. 이 요청은 클러스터가 클수록 비용이 커진다. 변경은 오후 2시 51분부터 3시 20분 사이에 모든 클러스터에 적용됐다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버클라이언트 쪽 DNS 리졸버와 캐시텔레메트리 에이전트

   기여 요인

   스테이징 불일치단계적 배포 부재캐시로 가려진 장애모니터링 사각지대디버그 접근 제한

   감지

   변경이 모든 클러스터에 적용되던 오후 3시 13분 PST 에 알림이 울려 엔지니어들에게 전달됐다. 탐지 도구는 고객이 영향을 받기 몇 분 전에 문제를 잡았고, 엔지니어들은 3시 16분에 원인을 찾았다. 다만 노드의 DNS 캐시가 실제 실패를 늦춰, 문제의 전체 범위가 보이기 전에 배포가 계속 진행됐다.

   조치

   • 클러스터 규모를 줄여 쿠버네티스 API 부하의 총량을 낮췄다.
   • 쿠버네티스 관리 API 로 가는 네트워크 접근을 막아 새로 들어오는 무거운 요청을 차단하고 API 서버가 회복할 시간을 벌었다.
   • 쿠버네티스 API 서버를 증설해 밀린 요청을 처리할 자원을 늘리고 수정을 적용할 수 있게 했다.
   • 컨트롤 플레인 제어권을 되찾은 뒤 문제의 텔레메트리 서비스를 지웠다.
   • 오후 3시 27분부터 영향받은 클러스터에서 트래픽을 빼기 시작했고, 가능한 곳에서는 트래픽을 정상 클러스터로 옮겼다.
   • 많은 서비스가 동시에 자원을 내려받아 자원 한도가 찬 클러스터에는 추가로 수동 조치를 했다.

   후속 조치

   • 모든 인프라 설정 변경에 단계적 배포를 적용하고, 서비스 워크로드와 쿠버네티스 컨트롤 플레인을 포함한 클러스터 상태를 계속 감시한다.
   • 데이터 플레인이 컨트롤 플레인 없이 버티는 상황과 잘못된 변경을 일부러 배포하는 상황을 시험하는 장애 주입 테스트를 돌린다.
   • 데이터 플레인이 컨트롤 플레인을 지나치게 압박할 때도 엔지니어가 쿠버네티스 API 서버에 접근할 수 있는 비상 접근 수단을 만든다.
   • 데이터 플레인과 컨트롤 플레인을 분리한다. 서비스 디스커버리가 쿠버네티스 DNS 에 묶여 있는 구조를 풀어, 핵심 서비스가 요청을 처리할 때 컨트롤 플레인에 기대지 않게 한다.
   • 클러스터 기동에 필요한 자원에 캐시와 동적 속도 제한을 더하고, 클러스터 하나를 통째로 빠르게 교체하는 훈련을 정기적으로 한다.

   교훈

   이 장애는 여러 시스템과 절차가 동시에 실패하며 예상하지 못한 방식으로 얽혀 생겼다. 테스트는 이 변경이 쿠버네티스 컨트롤 플레인에 주는 영향을 잡지 못했다. DNS 캐시 때문에 변경과 서비스 실패 사이에 시간 차가 생겼다. 컨트롤 플레인에 접근할 수 없게 되면서 복구가 매우 느렸다. 데이터 플레인이 컨트롤 플레인과 따로 돌도록 설계되어 있어도, DNS 기반 서비스 디스커버리가 컨트롤 플레인에 기대면 컨트롤 플레인 장애가 서비스 장애로 번진다. 배포 전 점검은 클러스터의 CPU 와 메모리 사용량만 봤고 API 서버 부하는 보지 않았다.

   사례 보기
3. IL-0194 kube-apiserver 재시작 뒤 Vector DaemonSet 의 파드 list 요청이 한꺼번에 몰려 etcd 메모리가 세 배 가까이 늘고 마스터 노드가 연쇄적으로 재시작했다.

   Palark2023

   증상

   일상적인 kube-apiserver 재시작 직후 etcd 메모리 사용량이 거의 세 배로 치솟았고, 그 여파로 모든 마스터 노드가 연쇄적으로 재시작했다. 고객사의 운영 클러스터였다.

   컨트롤 플레인 무응답데이터베이스 과부하

   촉발

   일상적인 kube-apiserver 재시작 뒤, Vector 로그 수집기 DaemonSet 의 파드 전부가 캐시를 다시 채우려고 한꺼번에 파드 list 요청을 보냈다.

   원인

   용량 한계

   구성 요소

   etcd쿠버네티스 API 서버텔레메트리 에이전트

   기여 요인

   한계 미인지기본 설정 방치

   감지

   kube-apiserver 재시작 직후 마스터 노드 전체 메모리와 etcd 메모리 그래프가 치솟고 마스터 노드가 연쇄적으로 재시작하면서 알았다. 원인이 된 DaemonSet 은 감사 로그를 보고 찾았다.

   조치

   • limit-list-custom 이라는 PriorityLevelConfiguration 을 만들어 요청 대기열을 설정했다. 값은 문서의 표준 설정을 그대로 썼다.
   • 같은 이름의 FlowSchema 를 만들어, 이 DaemonSet 서비스 어카운트가 보내는 파드 list 와 get 요청을 그 대기열로 보냈다.

   후속 조치

   • 쿠버네티스 Rust 라이브러리에 resourceVersion 설정을 넣는 PR 을 냈다.
   • Vector 로그 수집기 쪽에 이 문제를 고치는 PR 을 열었다.
   • Cilium CNI 에서도 비슷한 문제를 찾아 같은 방법으로 해결했다.

   교훈

   etcd 는 필드 셀렉터와 레이블 셀렉터를 모르기 때문에, kube-apiserver 에는 가벼워 보이는, 필터를 건 list 요청도 etcd 에서는 그 종류의 객체 전체를 읽는 일이 된다. 데이터가 꼭 최신이어야 하는 컨트롤러가 아니라면 resourceVersion=0 으로 kube-apiserver 캐시에서 읽게 할 수 있다. 다만 kube-apiserver 가 여러 대면 인스턴스마다 다른 데이터를 받을 수 있다. 여러 파드가 한꺼번에 보내는 요청은 Priority and Fairness 로 대기열에 넣어 kube-apiserver 와 etcd 를 지킬 수 있다. 위험한 것은 파드 요청만이 아니어서 Cilium CNI 에서도 비슷한 문제가 나왔다.

   사례 보기
4. IL-0075 클러스터가 EC2 인스턴스 약 290대로 커지자 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하면서 API 서버가 CPU 와 메모리를 다 써 쿠버네티스 컨트롤 플레인을 쓸 수 없게 됐다.

   Civis Analytics2019

   증상

   스크립트 실행 기반을 쿠버네티스로 옮긴 Croquet 를 사내에 공개한 뒤, 개발자들은 kubectl 명령이 느리다고 했다. 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다.

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

   촉발

   자체 인프라 Bocce 에서 쿠버네티스로 옮긴 스크립트 실행 기반 Croquet 를 2018년 9월 사내에 공개했다. 대량의 스크립트가 몰리면서 클러스터가 EC2 인스턴스 약 290대로 커졌고, 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하는 부하도 함께 늘었다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버텔레메트리 에이전트etcd

   기여 요인

   한계 미인지미검증 가정모니터링 사각지대용량 계획 부재

   감지

   개발자들이 kubectl 명령이 느리다고 했고, 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다. 마스터 노드의 CPU 사용률이 높았고, 조사해 보니 API 서버 컨테이너 세 개가 CPU 를 꽉 채워 쓰고 있었다. 당시 팀이 볼 수 있던 지표는 마스터 노드 CPU 의 CloudWatch 지표와 Datadog 의 컨테이너별 CPU, 메모리 지표였다. API 요청 처리량과 5xx 오류율과 요청 지연은 볼 수 없었다.

   조치

   • 사내 사용자들을 예전 인프라로 되돌려 클러스터를 안정시켰다.
   • 마스터 노드를 m4.large 세 대에서 m4.4xlarge 세 대로 키웠다.
   • 노드마다 도는 Datadog 에이전트가 서비스 메타데이터를 얻으려고 API 서버를 폴링하지 않도록 Datadog 설정을 바꿨다.
   • 상태를 바꾸지 않는 요청의 max-requests-inflight 한도를 400 에서 1200 으로 올렸다.
   • etcd 의 EBS 볼륨을 20 GB 에서 100 GB 로 늘려 IOPS 를 100 에서 300 으로 올렸다.
   • 스크립트의 DNS 정책을 ClusterFirst 에서 Default 로 바꿔 DNS 타임아웃을 줄였다.

   후속 조치

   • Kops 가 안전한 이전을 지원하면 etcd 를 2.2.1 에서 3.x 로 올린다.
   • 스크립트가 클러스터 안의 다른 워크로드와 통신할 수 있도록 DNS 타임아웃 문제를 근본적으로 해결한다.

   교훈

   가장 큰 실수는 쿠버네티스가 모든 것을 알아서 해 준다고 가정한 것이었다. 쿠버네티스는 노드 5,000대와 파드 100,000개를 지원한다고 하지만, 그 규모에 이르려면 손봐야 할 설정이 많다. 클러스터에 넣는 서드파티 도구, 특히 DaemonSet 을 조심해야 한다. 많은 도구가 보통 규모에 맞춰 만들어졌고 큰 규모에서는 시험되지 않았다. 클러스터 상태를 watch 하는 서비스가 데이터를 지나치게 많이 가져가도록 설계되면 규모 문제가 생긴다. kube2iam 은 모든 파드의 메타데이터를 메모리에 들고 있다가 메모리가 바닥났고, Fluentd Kubernetes Metadata Filter 플러그인도 같은 문제가 있다. 대개 설정 하나로 고칠 수 있지만, 부하 테스트를 해 보기 전에는 잘 드러나지 않는다.

   사례 보기

원인별3