사례6건

6건 중 1~5번째

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

   Microsoft Azure2025

   증상

   모든 아웃바운드 트래픽을 사내 프록시로 보내야 하는 환경에서 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 에서 요청한 노드 풀 자동 롤백 기능이 있었다면 이런 상황에서 도움이 됐을 것이라고 적었다.

   사례 보기
2. IL-0020 EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 한꺼번에 쫓아내 운영 서비스가 멈췄다

   UK Ministry of Justice2025

   증상

   2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.

   파드 축출파드 Pending서비스 중단업그레이드 정체

   촉발

   EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   여유 용량 부재한계 경보 부재기본 설정 방치

   감지

   팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.

   조치

   • cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
   • 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
   • 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
   • 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.

   후속 조치

   • AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
   • 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
   • 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
   • 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
   • 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
   • Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.

   교훈

   이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.

   사례 보기
3. IL-0164 이전 릴리스의 변경이 빠진 LKE 운영 업데이트 때문에 클러스터 업그레이드와 노드 추가가 오류 없이 실패했다

   Linode2022

   증상

   2022년 6월 15일 18:30 UTC 무렵부터 LKE 고객이 클러스터를 업그레이드하거나 노드를 추가하려 하면 작업이 아무 오류 없이 실패했다. 19:54 UTC 에 상태 페이지에 LKE 문제를 조사 중이라는 공지가 올라왔다. 영향을 받은 곳은 US-East 뉴어크, US-Central 댈러스, US-West 프리몬트, US-Southeast 애틀랜타, CA-Central 토론토, EU-West 런던, EU-Central 프랑크푸르트, AP-South 싱가포르, AP-Northeast 도쿄 2, AP-West 뭄바이, AP-Southeast 시드니 리전의 LKE 였다.

   업그레이드 정체

   촉발

   6월 15일 18:30 UTC 무렵 LKE 운영 환경에 증분 업데이트를 배포했고, 이 업데이트에는 이전 릴리스의 변경이 빠져 있었다.

   원인

   배포 결함

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   상태 페이지 첫 공지는 업데이트 배포 약 1시간 24분 뒤인 19:54 UTC 에 올라왔다.

   조치

   • 빠진 변경을 다음 업데이트에 넣어 21:00 UTC 무렵 배포했다.

   후속 조치

   • 같은 문제를 막으려고 업데이트 절차에 단계와 자동화를 더했다.

   사례 보기
4. IL-0449 EKS 관리형 노드 그룹으로 옮긴 며칠 뒤 파드가 재시작을 되풀이하거나 Terminating 상태에 멈추고 노드를 쓸 수 없게 됐다

   Enigmo2020

   증상

   EKS 클러스터의 파드를 새로 만든 관리형 노드 그룹으로 옮기고 2~3일 지나자, 파드가 갑자기 재시작을 되풀이하거나 제대로 종료되지 못하고 Terminating 상태로 계속 남았다. 노드의 CPU 와 메모리 부하가 높아져 클러스터에서 노드를 쓸 수 없게 됐다.

   파드 Terminating 정체노드 CPU 고부하메모리 압박노드 NotReady업그레이드 정체

   촉발

   EKS 1.16 업그레이드를 앞두고 파드를 버그가 있는 AMI 로 만든 새 관리형 노드 그룹으로 옮기고 옛 노드 그룹을 지웠다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

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

   기여 요인

   롤백 무효늦게 드러난 변경

   조치

   • 수정된 AMI 가 나오자 관리형 노드 그룹의 AMI 버전을 바꿨다.
   • CloudFormation 으로 관리형 노드 그룹 업데이트를 실행했다.
   • 업데이트가 도는 동안 kubectl get pods --all-namespaces 로 파드 상태를 지켜봤다.
   • Terminating 상태로 한동안 변화가 없는 파드를 찾을 때마다 kubectl delete pods <pod name> --grace-period=0 --force 로 강제로 지웠다.

   후속 조치

   • 분기나 달마다 각종 모듈의 최신 릴리스를 확인하고 정기적으로 업그레이드해, 서비스 영향을 가장 작게 하는 운영 방법을 찾는다.

   교훈

   Amazon EKS 나 쿠버네티스를 쓰는 한 클러스터 본체와 Ingress Controller 같은 모듈의 업그레이드를 늘 신경 써야 한다. 안정적으로 돈다고 한동안 손대지 않고 두면, 그사이 호환성을 깨는 변경이 담긴 릴리스가 갑자기 발표되는 일이 드물지 않다. 쿠버네티스 마이너 버전은 3개월쯤마다 나오므로 1년에 적어도 한 번은 업그레이드해야 한다.

   사례 보기
5. IL-0149 2019-09-28 07:20 UTC 이전에 만든 VMSS 기반 AKS 클러스터의 업그레이드가 PlatformImageNotFound 오류로 실패했다.

   Microsoft Azure2019

   증상

   2019-09-28 07:20 UTC 부터 Virtual Machine Scale Sets 위의 AKS 클러스터에서 클러스터 업그레이드를 시도하면 실패 알림이 왔다.

   업그레이드 정체

   촉발

   최근 서비스 업데이트가 백엔드 서비스의 인스턴스를 비정상 상태로 만들어 요청이 끝나지 못했다. 이 상태에서 고객이 클러스터 업그레이드를 시도했다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   –

   감지

   고객은 클러스터를 업그레이드하려 할 때 실패 알림을 받았다.

   조치

   • az vmss update 명령으로 스케일 세트 이미지의 version 을 "2019.09.25" 로, Sku 를 "aks-ubuntu-1604-201909" 로 바꾼 뒤 업그레이드를 다시 실행하는 방법을 공개했다.
   • AKS 팀과 VMSS 팀이 영향받은 클러스터를 손으로 완화했다.
   • 모든 리전에 핫픽스를 배포해 2019-10-15 에 마쳤다.

   사례 보기

원인별4