사례3건

3건 중 1~3번째

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-0148 클러스터에 없는 노드를 가리키는 노드 어피니티를 가진 파드 하나 때문에 kube-scheduler 가 패닉에 빠져 AKS 클러스터에서 파드가 하나도 스케줄되지 않았다

   Microsoft Azure2024

   증상

   Kubernetes v1.27.14, v1.28.10, v1.29.5 를 쓰는 AKS 클러스터에서 kube-scheduler 가 패닉에 빠졌다. 그 뒤로 클러스터의 어떤 파드도 스케줄되지 않았다.

   파드 Pending

   촉발

   클러스터에 없는 노드를 가리키는 노드 어피니티를 가진 파드가 생겼다.

   원인

   소프트웨어 결함

   구성 요소

   파드 스케줄링과 배치

   기여 요인

   –

   감지

   AKS 팀이 직접 버그를 찾았고, 2024년 7월 24일 Azure/AKS 깃허브 이슈로 고객에게 알렸다.

   조치

   • Azure Kubernetes Service 엔지니어들이 영향을 받은 클러스터를 모두 고쳤다.
   • 고친 kube-scheduler 를 모든 리전에 배포해 고객 클러스터에 자동으로 적용했다.

   사례 보기
3. IL-0146 Central India 에서 새로 만든 Azure CNI 클러스터의 VM 이 높은 값의 MAC 주소를 받으면서 bridge 모드 Azure CNI 의 오래된 버그가 드러나 터널 연결이 끊기고 kubectl exec 와 파드 간 통신이 타임아웃됐다.

   Microsoft Azure2020

   증상

   2020년 12월 4일 00:00 UTC 무렵부터 Central India 에서 Azure CNI 로 새로 만든 AKS 클러스터에 터널 연결 문제가 생겼다. 진단 페이지에는 터널 exec 문제가 표시됐다.

   간헐적 타임아웃

   촉발

   Central India 의 VM 들이 평소처럼 00 으로 시작하는 MAC 주소가 아니라 06 으로 시작하는, 훨씬 높은 값의 MAC 주소를 받기 시작했다.

   원인

   소프트웨어 결함

   구성 요소

   Azure CNI노드 운영체제 이미지

   기여 요인

   –

   조치

   • VMSS 클러스터 사용자에게 노드 이미지 업그레이드나 패치 버전 업그레이드 같은 쿠버네티스 업그레이드로 bridge 를 쓰지 않는 Azure CNI 를 받으라고 안내했다.
   • VMAS 클러스터 사용자에게 클러스터를 늘린 뒤 MAC 주소 값이 높고 bridge 모드로 동작하는 VM 을 지우라고 안내했다.
   • 영향을 받은 클러스터가 막 만든 것이라면 다시 만들라고 안내했다.

   후속 조치

   • transparent 모드를 모든 리전의 기본값으로 만드는 핫픽스를 배포한다.

   교훈

   VM 에 배정되는 MAC 주소 범위처럼 플랫폼 쪽에서 바뀐 값 하나가 오래 드러나지 않던 CNI 버그를 드러낼 수 있다. 같은 증상이라도 노드의 MAC 주소와 CNI 모드를 함께 봐야 영향 여부를 가를 수 있다.

   사례 보기

원인별1