IL-0147 Microsoft · 2025-08-26kubernetesazurenetworking

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

AKS 노드 이미지 VHD 에는 쿠버네티스 바이너리가 미리 캐시되어 있다. 캐시되는 것은 마이너 버전마다 가장 최근 패치 두 개뿐이다. 클러스터 버전이 캐시에 없으면 노드는 부트스트랩 중에 acs-mirror.azureedge.net 에서 바이너리를 내려받는다.

202508 이미지에 들어간 최근 리팩터링 때문에, 캐시되지 않은 바이너리를 내려받을 때 HTTP 프록시 설정이 쓰이지 않았다. 직접 나가는 트래픽을 막고 프록시만 허용하는 환경에서는 curl 이 계속 시간 초과됐고, CSE 가 780초 한도를 넘겨 종료 코드 31 로 끝났다. 그래서 노드 풀 생성, 확장, 노드 이미지 업그레이드가 실패했다. 1.31.9 와 1.31.10 은 이미지에 캐시되어 있어 내려받을 필요가 없었으므로 문제가 없었다.

영향받은 VHD 버전은 20250806, 20250811, 20250820 이었다. 이슈는 2025년 8월 27일에 열렸고, AKS 팀은 9월 2일 바이너리가 VHD 에 캐시되지 않은 경우의 문제일 수 있다고 답했다. 9월 3일 원인을 확인하고 VHD 20250811 과 20250820 에 핫픽스를 넣겠다고 알렸다. 9월 4일 핫픽스를 넣은 VHD 20250811 이 모든 퍼블릭 리전에 배포됐고, 이슈는 해결로 표시됐다.

심각도: –
영향 범위: Node pool creation, scaling and node image upgrades failed for AKS clusters whose nodes must egress through an HTTP proxy and whose Kubernetes version was not cached in the 202508 node images
영향 사용자: AKS customers in proxy-restricted environments
지역: –
감지까지: –
복구까지: –

증상

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

VMSS 활동 로그에는 "VM has reported a failure when processing extension 'vmssCSE'" 와 "Enable failed: failed to execute command: command terminated with exit status=31" 이 남았다. CSE 는 VM 이 뜰 때 노드를 부트스트랩하는 CustomScriptExtension 스크립트다. CSE 출력을 보면 acs-mirror.azureedge.net 에서 kubernetes-node-linux-amd64.tar.gz 를 받는 curl 이 프록시를 거치지 않고 "Trying 23.73.0.182:443..." 에서 계속 시간 초과됐다. 결국 "Error: CSE has been running for 806 seconds, exceeding the limit of 780 seconds." 를 남기고 exit 31 로 끝났다.

Ubuntu 와 AzureLinux 이미지 모두에서 재현됐다. 같은 AKS 버전에 202507.* 이미지를 쓰거나, 202508.* 이미지라도 AKS 1.31.9 나 1.31.10 을 쓰면 문제가 없었다. 202507.* 스냅숏으로 되돌리면 프로비저닝이 다시 성공했다. 다른 사용자는 AKS v1.32.4 에서 202507.21.0 이미지는 잘 됐지만, Reconcile 뒤 AKS 가 202508.06.0 을 쓰려다 실패해 클러스터가 Failed 상태가 됐다고 보고했다.

처음 보고한 사용자는 202508.* 이미지에서 부트스트랩 초기에 프록시 환경 변수가 읽히지 않는다고 의심했다. 의심한 곳은 /etc/environment 를 읽는 부분, CSE 의 systemd 유닛 환경, curl 빌드나 설정, NO_PROXY 불일치였다.

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

원인

원인 ? 소프트웨어 결함

구성 요소 ?노드 운영체제 이미지 노드 풀

기여 요인 ?캐시로 가려진 장애 자동화 증폭

촉발: 계획된 유지 보수로 노드 이미지가 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 에서 요청한 노드 풀 자동 롤백 기능이 있었다면 이런 상황에서 도움이 됐을 것이라고 적었다.

출처

https://github.com/Azure/AKS/issues/5238 · github

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

증상

원인

감지

조치

후속 조치

교훈

출처

참고 문서

관련 사례