사례13건

13건 중 3~7번째

1. IL-0134 AUS01 데이터센터에 전력 문제가 생겨 GPU 노드 246대와 스파인 스위치, VAST 스토리지가 한꺼번에 재부팅됐고, 워크로드가 실패하고 NFS 마운트가 끊겼다.

   Lambda2026sev1

   증상

   2026년 2월 14일 21:06 UTC 에 AUS01 데이터센터의 GPU 노드가 모두 동시에 재부팅됐다. 노드는 곧 다시 올라왔지만, 계획에 없던 재부팅이었고 여러 고객이 영향을 받았다.

   GPU 인식 불가스토리지 연결 끊김

   촉발

   AUS01 데이터센터에 전력 문제가 생겨 전원이 끊겼다.

   원인

   의존성 장애

   구성 요소

   데이터센터 전력·냉각InfiniBand 패브릭공유 네트워크 파일 시스템

   기여 요인

   –

   조치

   • 컴퓨트 패브릭과 InfiniBand 연결을 복구해 스파인 스위치 4대 전부와 대부분의 리프 스위치를 다시 온라인으로 올렸다.
   • UPS 이중화를 일부 복구하고, 스토리지와 보호 전원을 완전히 되살리는 작업을 이어 갔다.
   • AUS01 의 모든 노드 전원을 올리고 물리 점검을 마친 뒤 스토리지를 다시 올렸다.
   • us-west-3 의 Starbase 와 스토리지에 의존하는 다른 서비스를 복구했다.
   • NFS 마운트가 stale 상태이거나 비어 있는 고객에게 VM 을 재부팅하라고 안내했고, VM 재부팅으로 풀리지 않으면 하이퍼바이저 재부팅이 필요하다고 알렸다.

   교훈

   전원이 끊겨 GPU 노드와 함께 네트워크 스파인과 공유 스토리지까지 재부팅되면, 노드 자체가 다시 뜨는 것보다 전체 복구가 훨씬 오래 걸린다. GPU 노드는 곧 다시 올라왔지만, 팀은 패브릭을 먼저 되살렸고 스토리지는 물리 점검을 마친 뒤에야 다시 올렸다. 일부 VM 에는 stale 상태의 NFS 마운트가 남아, Lambda 는 고객에게 VM 을 재부팅하고 그래도 안 되면 하이퍼바이저를 재부팅하라고 안내했다.

   사례 보기
2. IL-0187 Spring Cloud Config Server 가 잠깐 내려가자 이를 헬스 체크에 포함한 모든 앱의 Liveness Probe 가 실패해 쿠버네티스가 파드를 계속 죽이고 다시 띄우면서 한 계열사 서비스가 마비됐다.

   Yonghyun Kim2025

   증상

   Config Server 업그레이드로 서버가 잠깐 응답하지 않는 동안, 클라이언트 앱 전부가 Liveness Probe 요청에 Config Server 와 연결되지 않는다며 실패로 응답했다.

   프로브 실패컨테이너 재시작 반복서비스 중단

   촉발

   Config Server 를 다운타임이 있는 방식으로 업그레이드하면서 서버가 잠깐 응답하지 않았다.

   원인

   의존성 장애

   구성 요소

   라이브니스·레디니스 프로브

   기여 요인

   기본 설정 방치자동화 증폭과도한 영향 범위

   교훈

   Liveness Probe 가 앱 자신이 아니라 외부 의존성의 상태까지 판단하면, 잠깐의 외부 장애나 네트워크 문제에도 쿠버네티스가 멀쩡한 앱을 죽인다. 일시적인 부하나 외부 서버 다운은 앱을 죽일 이유가 아니며, Readiness Probe 로 잠시 트래픽만 막으면 된다. 글쓴이는 특별한 이유가 없으면 Liveness Probe 를 끄라고 권한다. 꼭 써야 한다면 헬스 체크 경로에서 DataSourceHealthIndicator, ConfigServerHealthIndicator 같은 외부 Health Indicator 를 빼거나 /healthz 같은 별도 경로를 만들어야 한다. initialDelaySeconds 는 앱이 뜨는 데 걸리는 최대 시간보다 길게, failureThreshold 와 periodSeconds 는 넉넉하게 잡는다. 예를 들어 failureThreshold: 10, periodSeconds: 6 이면 60초 동안 연속으로 실패해야 재시작된다. 글쓴이가 운영한 레브잇 환경은 Liveness Probe 없이 2년 동안 안정적으로 서비스했다.

   사례 보기
3. IL-0162 데이터베이스 업데이트 뒤 LKE 내부 DNS 서비스가 멈춰 사용자가 LKE 클러스터 컨트롤 플레인과 LKE 대시보드에 접속하지 못했다

   Linode2025

   증상

   2025년 4월 1일 Linode Kubernetes Engine, 줄여서 LKE 의 사용자들이 자기 클러스터에 연결하지 못하기 시작했다. 외부에서 클러스터 컨트롤 플레인과 LKE 대시보드에 접근할 수 없었다.

   DNS 조회 실패컨트롤 플레인 무응답

   촉발

   앞서 진행한 데이터베이스 업데이트 때문에 LKE DNS 서비스가 멈췄다.

   원인

   의존성 장애

   구성 요소

   DNS 서버와 레코드애플리케이션 데이터베이스

   기여 요인

   –

   감지

   Linode 는 20시 28분 UTC 상태 페이지에 사용자가 클러스터 컨트롤 플레인에 연결하기 어려울 수 있다고 알리고 조사를 시작했다. 21시 33분 문제를 LKE 의 DNS 기능으로 좁혔고, 22시 29분 근본 원인을 찾았다.

   조치

   • 영향받은 LKE DNS 서비스를 재시작해 클러스터와 LKE 대시보드 접근을 되살렸다.

   후속 조치

   • DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 스스로 회복하도록 개선한다.
   • 비슷한 문제를 더 빨리 찾도록 모니터링을 강화한다.
   • 서로 의존하는 시스템 사이의 변경을 더 잘 조율하도록 배포 절차를 고친다.

   교훈

   DNS 서비스가 의존하는 데이터베이스를 바꾸면 DNS 서비스가 멈출 수 있고, 그러면 클러스터 안은 멀쩡해도 사용자는 컨트롤 플레인에 닿지 못한다. Linode 는 DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 회복할 수 있어야 하고, 서로 의존하는 시스템의 변경은 함께 조율해야 한다고 정리했다.

   사례 보기
4. IL-0103 EKS 노드 AMI 업데이트로 파드가 한꺼번에 다시 뜨자 인증서 요청이 몰린 외부 CA 가 과부하에 걸려 Istio 사이드카가 CrashLoopBackOff 에 빠졌다.

   Tetrate (unnamed U.S. federal customer)2025sev1

   증상

   미국 연방 기관 고객이 Istio 를 쓰는 EKS 클러스터 30여 개의 노드 AMI 를 업데이트하던 중, 그중 한 클러스터에서 사이드카가 주입된 워크로드가 시작하지 못하고 CrashLoopBackOff 에 빠졌다.

   컨테이너 재시작 반복프로브 실패

   촉발

   EKS 노드 AMI 업데이트로 수백 개의 새 파드가 동시에 떠서 외부 CA 로 인증서 요청이 한꺼번에 몰렸다.

   원인

   의존성 장애

   구성 요소

   Istio어드미션 웹훅노드 운영체제 이미지

   기여 요인

   기본 설정 방치한계 미인지

   감지

   노드 AMI 업데이트 중 한 클러스터에서 사이드카가 주입된 워크로드가 CrashLoopBackOff 로 시작하지 못했다. 처음 보인 신호는 istiod 초기화가 유난히 오래 걸리며 나온 Readiness probe 실패 이벤트였다.

   조치

   • istiod 레플리카를 40개에서 1개로 잠시 줄여 Istio 내부 처리를 늦추고 CA 부하를 덜었다.
   • Approved, Failed 상태로 멈춰 있던 CSR 들을 찾아 지웠다.
   • 파드를 한꺼번에 재시작하지 않고 단계적으로 재시작해 CA 요청이 다시 몰리지 않게 했다.

   교훈

   복잡한 인프라 장애를 진단할 때는 Istio 만이 아니라 서비스 메시를 둘러싼 구성 요소 전체를 봐야 한다. CSR 이벤트가 모두 성공으로 보여도 사이드카 로그에 CA 요청 실패가 있으면 외부 CA 의 처리 능력을 의심해야 한다. 노드 이미지 업데이트처럼 파드가 한꺼번에 다시 뜨는 작업을 하면 외부 CA 에 요청이 몰려, istiod 의 기본 CA 타임아웃 10초 안에 응답을 받지 못할 수 있다.

   사례 보기
5. IL-0159 Docker Hub 의 남용 방지 장치가 Linode 의 IPv6 주소 대역에 레이트 리밋을 걸어 LKE 와 LKE-E 의 이미지 풀이 429 Too Many Requests 로 실패했다.

   Linode2025

   증상

   2025년 2월 5일 21:38 UTC 무렵부터 여러 리전에서 LKE, LKE-E, 그 밖에 Docker Hub 이미지 풀에 기대는 서비스들이 이미지를 받지 못했다.

   이미지 풀 실패

   촉발

   Docker Hub 가 남용 방지 조치로 Linode 의 IPv6 주소 대역에서 오는 이미지 풀에 레이트 리밋을 걸었다.

   원인

   의존성 장애

   구성 요소

   컨테이너 레지스트리와 자격 증명VPC DNS 리졸버

   기여 요인

   한계 미인지

   감지

   레이트 리밋은 21:38 UTC 무렵 시작됐고, 22:48 UTC 에 상태 페이지가 Docker Hub IPv6 문제를 조사 중이라고 처음 알렸다. 2월 6일 01:06 UTC 에는 Docker Hub 로 가는 IPv6 이미지 풀 요청에 레이트 리밋이 걸린 것을 원인으로 확인했다고 올렸다.

   조치

   • DNS 리졸버가 'AAAA' 레코드 대신 'A' 레코드로 응답하게 바꿔 Docker Hub 이미지 풀이 IPv4 로 나가게 했다.

   후속 조치

   • Docker Hub 의 남용 방지 조치에 서비스가 영향받지 않도록 장기 해법을 찾는다.

   교훈

   공용 레지스트리 하나에 기대는 이미지 풀은 그 레지스트리의 레이트 리밋 정책 하나로 한꺼번에 막힐 수 있다. 이번에는 Docker Hub 가 IPv6 주소를 앞 64비트로 판정하는 방식 때문에 Linode IPv6 대역의 이미지 풀이 막혔고, DNS 로 IPv4 를 쓰게 해 피해 갔다.

   사례 보기

원인별1