사례6건

6건 중 1~5번째

1. IL-0171 Bottlerocket AMI 에 libdcgm.so 가 없어 GPU 노드의 AcceleratedHardwareReady 가 False 가 됐고, Karpenter 노드 자동 복구가 Ready 뒤 10~11분마다 GPU 노드를 교체하는 일을 끝없이 되풀이했다.

   Inflab2025

   증상

   강의 영상 업스케일링용 GPU 파드를 띄우자 GPU 노드가 정상적으로 만들어져 Ready 가 됐다가, 약 10~11분 뒤 갑자기 비정상으로 판정되어 Karpenter 가 노드를 교체했다. 새로 만든 노드에서도 같은 일이 되풀이됐고, GPU 파드가 계속 재시작되어 작업이 진행되지 않았다.

   노드 재생성 반복GPU 인식 불가

   촉발

   kubelet OOM 으로 생기던 좀비 노드를 정리하려고 Karpenter 설정에서 nodeRepair 기능 게이트를 켰다.

   원인

   소프트웨어 결함

   구성 요소

   Karpenter노드 운영체제 이미지GPU 드라이버

   기여 요인

   자동화 증폭미검증 가정

   감지

   GPU 노드가 Ready 뒤 10~11분 만에 계속 교체되는 것을 보고 노드 이벤트를 분석해 DCGMError 메시지를 찾았다.

   조치

   • Karpenter 설정에서 nodeRepair 기능 게이트를 false 로 바꿔 Node Auto-Repair 를 껐다.

   교훈

   Karpenter Node Auto-Repair 는 AcceleratedHardwareReady=False 도 노드를 교체할 사유로 본다. 그래서 GPU 연산에는 문제가 없어도 GPU 모니터링 라이브러리 하나가 빠지면 노드가 끝없이 교체될 수 있다. Node Auto-Repair 를 켠 뒤 GPU 노드가 자주 교체되면 이 기능을 꺼 볼 만하다. 좀비 노드 문제는 이제 메모리가 4GB 이상인 인스턴스 타입을 써서 완화했다.

   사례 보기
2. IL-0147 AKS 202508 노드 이미지가 캐시되지 않은 쿠버네티스 바이너리를 받을 때 HTTP 프록시 설정을 쓰지 않아, 프록시 뒤에 있는 노드의 프로비저닝이 CSE 종료 코드 31 로 실패했다.

   Microsoft2025

   증상

   모든 아웃바운드 트래픽을 사내 프록시로 보내야 하는 환경에서 AKS 1.31.0 부터 1.31.8 까지의 노드 풀을 만들거나 늘리면 VMSS 인스턴스 프로비저닝이 실패했다. 계획된 유지 보수로 노드 이미지가 202507.* 에서 202508.* 로 자동 업그레이드된 뒤부터였다.

   노드 증설 실패업그레이드 정체

   촉발

   계획된 유지 보수로 노드 이미지가 202507.* 에서 202508.* 로 자동 업그레이드됐다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   캐시로 가려진 장애자동화 증폭

   감지

   고객이 VMSS 활동 로그와 CSE 출력에서 프로비저닝 실패를 보고 원인을 좁힌 뒤 2025년 8월 27일 Azure/AKS GitHub 이슈로 보고했다.

   조치

   • 고객은 AKS 1.31.8 클러스터의 노드 이미지를 202507.* 로 고정해 프로비저닝을 되살렸다.
   • 고객은 202508.* 이미지를 쓰는 클러스터를 AKS 1.31.9 나 1.31.10 으로 올려 문제를 피했다.
   • AKS 팀은 캐시되지 않은 바이너리를 내려받을 때 프록시 설정을 쓰도록 VHD 20250811 에 핫픽스를 넣어 9월 4일 모든 퍼블릭 리전에 배포했다. VHD 20250820 에도 핫픽스를 넣겠다고 알렸다.
   • AKS 팀은 사용자에게 az aks nodepool upgrade -n <nodepool-name> --cluster-name <clustername> -g <resourcegroup-name> --node-image-only 로 노드에 이미지를 다시 설치하라고 안내했다.

   후속 조치

   • 앞으로 나오는 모든 VHD 에 같은 수정을 넣는다.

   교훈

   노드 이미지에 캐시된 쿠버네티스 버전이면 바이너리를 내려받지 않으므로 프록시 처리가 망가져도 드러나지 않는다. 캐시는 마이너 버전마다 최근 패치 두 개뿐이라, 오래된 패치 버전을 쓰는 클러스터만 내려받기 경로를 타서 이 버그를 겪었다. 보고한 사용자는 AKS 이슈 #5200 에서 요청한 노드 풀 자동 롤백 기능이 있었다면 이런 상황에서 도움이 됐을 것이라고 적었다.

   사례 보기
3. IL-0021 GKE 의 COS 노드가 NVIDIA GPU 드라이버를 403 Forbidden 으로 받지 못해 새로 만든 GPU 노드를 쓸 수 없었다

   Google Cloud2024

   증상

   2024-03-12 US/Pacific 08:00 부터 GKE 에서 Container-Optimized OS 를 쓰는 GPU 노드가 일부 NVIDIA GPU 드라이버를 받지 못했다. 새로 만들거나 다시 만든 노드는 GPU 드라이버가 작동하지 않았고, 그 드라이버를 쓰는 워크로드가 돌지 못했다.

   GPU 인식 불가노드 NotReady

   원인

   의존성 장애

   구성 요소

   GPU 드라이버노드 운영체제 이미지노드 풀

   기여 요인

   자동화 증폭

   감지

   보고서는 Google 이 장애를 어떻게 알아챘는지 적지 않았다. GKE 사용자는 GPU 노드에서 드라이버를 설치할 때 "Failed to download GPU driver installer, status: 403 Forbidden" 오류를 보고 이 장애를 알아볼 수 있었다.

   조치

   • GPU 드라이버 다운로드를 시도하는 자동 노드 재생성을 멈췄다.
   • 드라이버를 공급하는 파트너와 함께 스토리지 버킷 접근 문제를 해결했다.

   교훈

   상태 페이지 보고서는 교훈이나 후속 조치를 적지 않았다.

   사례 보기
4. IL-0198 systemd 보안 패치가 Ubuntu 22.04 노드의 systemd-networkd 를 재시작해 Cilium 이 넣은 IP 규칙을 지웠고, 여러 리전과 세 클라우드의 Kubernetes 노드가 한꺼번에 네트워크를 잃었다.

   Datadog2023

   증상

   2023년 3월 8일 06:00 에서 07:00 UTC 사이에 여러 리전과 여러 클라우드의 Kubernetes 노드가 한꺼번에 네트워크 연결을 잃었다. Datadog 의 모든 서비스가 영향을 받았고, CI/CD 와 자동화 도구가 있는 리전도 함께 끊겼다.

   노드 NotReady서비스 중단처리량 저하

   촉발

   2023년 3월 7일 Ubuntu 저장소에 systemd 의 CVE 패치 249.11-0ubuntu3.7 이 올라왔다. 3월 8일 06:00 에서 07:00 UTC 사이에 Ubuntu 기본값 그대로 둔 무인 업그레이드가 이 패치를 설치했고, systemd-networkd 가 재시작되면서 자신이 모르는 IP 규칙을 모두 지웠다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   systemd-networkdCilium노드 운영체제 이미지

   기여 요인

   기본 설정 방치늦게 드러난 변경단계적 배포 부재자동화 증폭

   조치

   • Google Cloud 와 Azure 에서 네트워크만 잃고 실행 중이던 인스턴스 수천 대를 클라우드 API 로 재시작해 로컬 디스크의 데이터와 함께 복구했다.
   • AWS 에서 교체되면서 로컬 디스크를 잃은 데이터 저장소는 데이터를 다시 만들거나, 다시 처리하거나, 백업에서 복원해 되살렸다.

   교훈

   기본값 그대로 둔 OS 무인 보안 업데이트는 단계적 배포 절차를 거치지 않고 모든 리전과 클라우드에 같은 시각에 변경을 적용한다. systemd-networkd 의 새 동작은 22.04 도입 때부터 있었지만 systemd-networkd 가 재시작될 때만 나타나서 몇 달 동안 보이지 않았다. CNI 가 호스트의 IP 규칙에 기대고 있으면, 그 규칙을 지우는 다른 구성 요소 하나가 노드 네트워크 전체를 끊는다. 클라우드마다 네트워크를 잃은 인스턴스를 다루는 방식이 다르고, 로컬 디스크에 데이터를 두는 서비스에서는 자동 교체가 오히려 복구를 늦춘다.

   사례 보기
5. IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다

   DFDS2022

   증상

   2022-10-31 13:45 UTC 에 팀은 계획된 vpc-cni EKS 애드온 업그레이드를 배포 파이프라인으로 시작했다. 14:10 에 파이프라인이 업그레이드 중 타임아웃으로 실패했다. 45개 aws-node 파드 가운데 약 10개만 업그레이드됐다. 5개는 Terminating 에 멈췄고, 나머지 30개는 업그레이드를 시도하지도 못했다.

   노드 NotReady업그레이드 정체간헐적 타임아웃간헐적 연결 실패

   촉발

   매일 도는 노드 롤오버가 2022-10-31 07:30 UTC 에 가장 최신 EKS 노드 AMI 인 v20221027 을 가져와 기존 노드를 이 AMI 로 만든 새 노드로 바꿨다. 이 AMI 는 나중에 커널 문제로 회수됐다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지리눅스 커널kubeletAWS VPC CNI노드 런치 템플릿Terraform

   기여 요인

   단계적 배포 부재자동화 증폭장애 중첩모니터링 사각지대헬스 프로브 부재

   감지

   07:30 롤오버 뒤 14:10 에 vpc-cni 업그레이드 파이프라인이 타임아웃으로 실패했다. 팀은 롤오버 7시간 뒤인 14:30 에 노드가 NodeNotReady 를 오가는 것을 보고 이상을 알았다. 감지까지 7시간이 걸렸다. 알림은 NodeNotReady 이벤트와 소켓 증가를 잡지 못했다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾고 나서 원인을 알았다.

   조치

   • Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 vpc-cni 업그레이드를 끝냈다. 모두 15대를 지웠다.
   • 특정 AMI 를 지정할 수 있도록 인프라 모듈의 terraform 을 고치고 테스트해 master 브랜치에 머지했다.
   • 파이프라인으로 EC2 Auto Scaling 그룹 launch configuration 의 AMI 를 이전의 정상 버전으로 되돌려 노드를 다시 만들었다.

   후속 조치

   • 각 팀에 readiness, liveness 프로브를 쓰자고 제안한다.
   • readiness, liveness 프로브 적용 현황을 보여 주는 대시보드를 만든다.
   • readiness, liveness 프로브와 그 쓸모를 설명하는 위키 글을 쓴다.
   • 인프라 모듈에서 특정 AMI 를 지정할 수 있게 고친다.
   • 최신 AMI 를 바로 받을지, 새 AMI 를 배포 전에 어떻게 시험할지 논의하는 자리를 잡는다.
   • 비정상적인 NodeNotReady 이벤트나 소켓 사용 증가를 잡는 알림을 만든다.
   • 팀 안에 Kubernetes 학습 과정을 만든다.
   • 노드 로그를 중앙에서 모은다.
   • 나와 있는 최신 AMI 를 조회하는 Prometheus exporter 를 만들고, 이를 쓰는 대시보드와 알림도 만든다.

   교훈

   새 AMI 를 배포한 날에는 다른 컴포넌트 업그레이드를 매우 조심해야 한다. 이번에는 새 노드 AMI 를 쓴 날 EKS 컴포넌트도 함께 올리면서 원인을 가리기 어려웠다. 장애나 문제가 생겼을 때 각 팀과 소통하는 경로도 개선해야 한다. 문제를 알린 팀에게서 자세한 내용을 받기 어려웠고, 팀별 당직 호출 경로도 없었다. 팀이 Kubernetes 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다.

   사례 보기

원인별3