사례14건

14건 중 2~6번째

1. IL-0166 컴퓨트 호스트 업데이트로 StackScript 해독에 쓰는 credential parser 가 빠져 새로 만든 LKE 노드가 부팅하지 못했다

   Linode2026

   증상

   2026-05-15 18:18 UTC 에 StackScript 를 쓰는 Linode 가상 머신 배포가 실패하는 문제가 확인됐다. 새로 만든 LKE 와 LKE-E 노드가 모두 여기에 해당했다.

   노드 증설 실패

   촉발

   최근 컴퓨트 호스트 업데이트에서 credential parser 가 제거됐다. 이 파서는 StackScript 를 해독하는 과정에 쓰였다.

   원인

   배포 결함

   구성 요소

   클러스터 오토스케일러노드 풀

   기여 요인

   –

   감지

   Akamai 는 2026-05-15 18:18 UTC 에 Linode 배포 실패 문제를 확인했다. 상태 페이지의 첫 공지는 05-16 00:42 UTC 에 올라왔다.

   조치

   • 05-16 01:10 UTC 에 롤백을 시험하기 시작해 01:20 에 실패가 줄었고, 01:30 에 고객 영향 대부분을 해소했다.

   교훈

   컴퓨트 호스트에서 credential parser 를 없애자 StackScript 로 배포한 Linode 가 모두 부팅하지 못했다. 새 LKE 와 LKE-E 노드도 모두 StackScript 로 배포되므로, 모든 리전에서 노드 생성과 오토스케일링, 노드 재생성이 멈췄다. 롤백 시험을 시작하고 10분 만에 실패가 줄었다.

   사례 보기
2. IL-0167 Osaka 데이터센터에 LKE 소프트웨어 릴리스를 단계적으로 배포한 뒤 LKE-E 클러스터 생성과 관리 작업이 멈췄다.

   Linode2026

   증상

   2026년 3월 12일 19:15 UTC 무렵부터 Osaka 데이터센터인 JP-OSA 에서 고객이 LKE-E 클러스터를 만들 수 없었다. LKE-E 는 Linode Kubernetes Engine for Enterprise 다. 클러스터 생성 과정은 끝없이 멈춰 있었다.

   클러스터·노드 생성 정체업그레이드 정체

   촉발

   Osaka 데이터센터에 LKE 소프트웨어 릴리스를 단계적으로 배포했다.

   원인

   배포 결함

   구성 요소

   관리형 쿠버네티스 컨트롤 플레인과 제공자 API

   기여 요인

   –

   감지

   장애는 19:15 UTC 무렵 시작됐고, 상태 페이지는 약 5시간 30분 뒤인 3월 13일 00:45 UTC 에 Osaka 의 새 LKE Enterprise 클러스터 배포 문제를 조사 중이라고 처음 알렸다.

   조치

   • Akamai 가 소프트웨어 수정을 배포했다.

   후속 조치

   • 담당 전문가들이 근본 원인을 계속 조사하고 알맞은 예방 조치를 한다.

   교훈

   릴리스를 단계적으로 배포한 Osaka 데이터센터에서 LKE-E 클러스터 생성과 관리 작업이 멈췄고, 소프트웨어 수정을 배포하자 풀렸다. 장애 중에 들어온 생성 요청은 수정 뒤 이어서 처리됐다.

   사례 보기
3. 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 펌웨어의 회귀를 의심했다.

   사례 보기
4. IL-0188 EKS 롤링 업데이트 때 Kubernetes 는 새 파드가 Ready 가 되자마자 옛 파드를 지웠지만 ALB 는 새 파드를 아직 healthy 로 보지 않아, 배포마다 약 30초 동안 502 가 났다.

   Yonghyun Kim2025

   증상

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지가 왔다. 모든 파드는 Ready 였고 Datadog 도 초록불이었지만, 사용자는 계속 오류 화면을 보고 있었다.

   오류율 상승서비스 중단

   촉발

   롤링 업데이트에서 새 파드가 readinessProbe 를 통과해 Ready 가 되자 Kubernetes 가 곧바로 옛 파드를 지웠다. 그때 ALB 는 새 파드 IP 를 대상 그룹에 막 등록해 initial 상태로 헬스 체크를 하고 있었다.

   원인

   배포 결함

   구성 요소

   클라우드 로드 밸런서인그레스 컨트롤러파드 종료 처리

   기여 요인

   미검증 가정기본 설정 방치모니터링 사각지대

   감지

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지로 알았다. 파드 상태와 Datadog 대시보드는 모두 정상이었고, 장애는 사용자가 보는 화면에만 나타났다.

   조치

   • 네임스페이스에 elbv2.k8s.aws/pod-readiness-gate-inject=enabled 레이블을 붙였다. AWS Load Balancer Controller 의 웹훅이 파드에 ReadinessGate 를 넣었다. 새 파드는 ALB 대상이 healthy 가 된 뒤에야 Ready 가 됐고, 그제야 옛 파드가 지워졌다.

   교훈

   Kubernetes 의 Ready 와 ALB 의 healthy 는 서로 다른 시점에 정해지므로, 둘을 잇는 장치가 없으면 롤링 업데이트 때 502 가 날 수 있다. 파드 상태와 대시보드가 모두 정상이어도 사용자는 오류를 볼 수 있다. terminationGracePeriodSeconds 를 늘려 시간을 버는 방식은 배포만 느리게 하고 새 파드가 뜰 때의 공백은 막지 못한다. ReadinessGate 는 ALB 대상 유형이 ip 일 때만 의미가 있고, instance 모드에서는 노드가 대상이라 쓸 수 없다. ReadinessGate 를 쓰면 파드가 Ready 가 되기까지 30초에서 40초가 더 걸리므로 급한 스케일 아웃에 대비해 레플리카나 HPA 를 넉넉히 잡는다. 웹훅의 failurePolicy 를 Ignore 로 두면 컨트롤러가 죽어도 배포가 막히지 않는다.

   사례 보기
5. IL-0121 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 잘못된 코드가 배포되어, 그 클러스터가 함께 관리하던 운영 추론 워크로드가 망가졌다

   OpenAI2025

   증상

   2025-07-09 오후 2:10 PDT 부터 gpt-4.1-mini 모델의 API 성공률이 떨어지고 ChatGPT 검색의 오류율이 크게 올랐다.

   오류율 상승

   촉발

   잘못된 코드 변경이 주로 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 배포되었다.

   원인

   배포 결함

   구성 요소

   –

   기여 요인

   과도한 영향 범위파괴적 변경 보호 장치 부재

   조치

   • 잘못된 코드 변경을 롤백했다.

   후속 조치

   • 운영 추론 워크로드가 이 컨트롤 플레인 클러스터에서 관리되지 않도록 막는 안전장치를 더했다.
   • 영향이 큰 컨트롤 플레인 변경을 배포할 때 쓰는 테스트를 강화했다.
   • 기존 운영 추론 워크로드를 모두 운영용 컨트롤 플레인 클러스터가 관리하도록 옮긴다.
   • 의도하지 않은 대규모 변경이 서비스에 일어나지 않게 막는 서킷 브레이커를 만든다.

   사례 보기

원인별1