사례16건

16건 중 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-0120 클라우드 GPU 서버의 정기 OS 업데이트가 systemd-networkd 를 재시작해 자체 네트워크 에이전트와 충돌했고, 많은 GPU 노드의 라우트가 모두 지워져 ChatGPT 와 API 의 오류율이 크게 올랐다.

   OpenAI2025

   증상

   6월 9일 오후 11시 36분 PDT 에 여러 서비스에서 동시에 알림이 울렸다. 인프라가 네트워크 연결을 잃기 시작했고, 상황은 바로 엔지니어링 팀에 에스컬레이션됐다.

   오류율 상승GPU 인식 불가

   촉발

   매일 예약된 호스트 OS 업데이트가 영향받은 노드에서 네트워크 관리 서비스인 systemd-networkd 를 의도치 않게 재시작했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

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

   기여 요인

   단계적 배포 부재디버그 접근 제한

   감지

   장애가 시작된 6월 9일 오후 11시 36분 PDT 에 인프라가 네트워크를 잃기 시작하면서 여러 서비스의 알림이 바로 울렸고, 상황은 즉시 엔지니어링 팀에 에스컬레이션됐다.

   조치

   • 6월 10일 오전 2시부터 영향받은 GPU VM 을 대규모로 다시 이미징했다.
   • 6월 10일 오전 6시 49분에 복구 자동화를 배포해 아직 영향받은 상태인 나머지 노드를 재시작했다.
   • 백그라운드에서 도는 업데이트를 멈췄다.

   후속 조치

   • GPU VM 의 매일 자동 업데이트를 끄고, 업데이트는 직접 정한 일정에 맞춰서만 하도록 바꿨다.
   • systemd-networkd 와 자체 네트워크 서비스가 충돌하지 않도록 시스템 설정을 고쳤다.
   • 전체 VM 설정을 감사해 비슷한 위험을 찾아 줄인다.
   • GPU VM 과 클러스터 같은 핵심 인프라의 복구 속도를 높이는 작업에 우선순위를 둔다.
   • 대응 능력을 높이려고 재해 복구 훈련을 정기적으로 계획한다.

   교훈

   호스트 OS 의 자동 업데이트가 네트워크 관리 서비스를 재시작하면, 같은 노드에서 라우트를 관리하는 다른 에이전트와 충돌해 노드 전체가 네트워크를 잃을 수 있다. 매일 도는 업데이트는 모든 노드에 거의 같은 시각에 적용된다. 네트워크가 끊긴 노드를 빠르게 되살릴 비상 도구가 없으면 노드를 다시 이미징할 수밖에 없고 복구가 길어진다.

   사례 보기
4. IL-0079 GKE 노드가 새 ubuntu_containerd 이미지로 자동 업그레이드된 뒤 커널에서 kube-proxy 가 쓰는 iptables 확장이 빠져, 여러 GKE 클러스터의 인그레스 트래픽이 완전히 끊겼다.

   Altinity2025

   증상

   토요일인 5월 17일 이른 시각에 OpsGenie 알림이 울렸다. Altinity.Cloud 의 ClickHouse 클러스터 하나가 갑자기 조용해졌다. 쿼리도, 지표도, 접속하려는 고객의 로그도 들어오지 않았다. 파드는 모두 Running 이었고 노드도 정상으로 보였지만 데이터베이스까지 오는 트래픽이 없었다.

   서비스 중단

   촉발

   GKE 가 노드를 ubuntu_containerd 1.32.3-gke.1785003 이미지와 커널 6.8.0-1022-gke 로 자동 업그레이드했다. 이 커널은 nf_tables 모듈의 패키징이나 로딩 방식에 회귀가 있어 kube-proxy 가 쓰는 iptables 확장을 지원하지 않았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   kube-proxy노드 운영체제 이미지리눅스 커널클라우드 로드 밸런서

   기여 요인

   미패치 알려진 버그단계적 배포 부재

   감지

   OpsGenie 알림으로 알았다. ClickHouse 클러스터 하나에서 쿼리, 지표, 고객 접속 로그가 모두 끊겼고, 곧 다른 클러스터들도 같은 상태가 됐다.

   조치

   • 아직 영향받지 않은 클러스터에 유지보수 제외를 걸어 업그레이드를 모두 멈췄다. 이 조치로 문제가 GKE 에서 운영하는 모든 클러스터로 번지는 것을 막았다.
   • 로드밸런서 헬스 체크 정책을 바꿔 kube-proxy 헬스 체크 실패를 무시하게 했다. kube-proxy 에 필요한 확장이 없는 노드로도 트래픽이 흐르면서 서비스가 회복됐다.
   • 영향받은 클러스터 전부를 ubuntu_containerd 에서 nf_tables 문제가 없는 다른 커널을 쓰는 cos_containerd 이미지로 옮기기 시작했다. 노드를 새 이미지로 다시 만들어야 해서 짧은 다운타임이 생겼다.

   후속 조치

   • 회귀를 더 일찍 잡도록 이미지 사전 테스트 파이프라인을 넓힌다.
   • GKE 자동 업그레이드 예정 알림을 켜서 미리 대비한다.
   • 모든 클러스터에 GKE 유지보수 기간을 반드시 설정해 업그레이드가 배포되는 시점을 직접 정한다.
   • Google 이슈 트래커에 올린 커뮤니티 이슈를 추적하며 고쳐진 Ubuntu 이미지를 기다린다.

   교훈

   관리형 Kubernetes 의 노드 자동 업그레이드는 사용자가 검증하지 않은 커널을 운영 노드에 올린다. 클라우드 업체의 이미지 검증만 믿으면 이런 회귀를 막지 못한다. IPv6 를 쓰지 않아도 kube-proxy 는 IPv6 iptables 규칙을 적용하므로, 그 적용이 실패하면 로드밸런서 헬스 체크도 실패해 모든 인그레스가 끊길 수 있다. 영향받은 버전이 확인되면 아직 업그레이드되지 않은 클러스터의 업그레이드부터 멈춰야 피해가 번지지 않는다. Altinity 는 영향받은 사용자에게 externalTrafficPolicy: Cluster 로 바꿔 kube-proxy 헬스 체크를 끄고, 운영 노드 이미지를 cos_containerd 로 바꾸고, 고쳐진 이미지가 확인될 때까지 자동 업그레이드를 멈추라고 권한다.

   사례 보기
5. 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초 안에 응답을 받지 못할 수 있다.

   사례 보기

원인별6