IL-0147 Microsoft · 2025-08-26kubernetesazurenetworking
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 이 모든 퍼블릭 리전에 배포됐고, 이슈는 해결로 표시됐다.
모든 아웃바운드 트래픽을 사내 프록시로 보내야 하는 환경에서 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 불일치였다.
원인 소프트웨어 결함
고객이 VMSS 활동 로그와 CSE 출력에서 프로비저닝 실패를 보고 원인을 좁힌 뒤 2025년 8월 27일 Azure/AKS GitHub 이슈로 보고했다.
노드 이미지에 캐시된 쿠버네티스 버전이면 바이너리를 내려받지 않으므로 프록시 처리가 망가져도 드러나지 않는다. 캐시는 마이너 버전마다 최근 패치 두 개뿐이라, 오래된 패치 버전을 쓰는 클러스터만 내려받기 경로를 타서 이 버그를 겪었다. 보고한 사용자는 AKS 이슈 #5200 에서 요청한 노드 풀 자동 롤백 기능이 있었다면 이런 상황에서 도움이 됐을 것이라고 적었다.
IL-0171 Bottlerocket AMI 에 libdcgm.so 가 없어 GPU 노드의 AcceleratedHardwareReady 가 False 가 됐고, Karpenter 노드 자동 복구가 Ready 뒤 10~11분마다 GPU 노드를 교체하는 일을 끝없이 되풀이했다.Inflab · 2025같은 원인 · 공통 노드 운영체제 이미지
IL-0078 EKS 업그레이드 중 Terraform 으로 KMS 시크릿 암호화를 켜자 워커 노드의 IAM 권한이 빠져 운영 ZenML Pro 워크스페이스에 모두 접속할 수 없게 됐다ZenML · 2025같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 풀
IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다DFDS · 2022같은 원인 · 공통 노드 운영체제 이미지
IL-0146 Central India 에서 새로 만든 Azure CNI 클러스터의 VM 이 높은 값의 MAC 주소를 받으면서 bridge 모드 Azure CNI 의 오래된 버그가 드러나 터널 연결이 끊기고 kubectl exec 와 파드 간 통신이 타임아웃됐다.Microsoft Azure · 2020같은 원인 · 공통 노드 운영체제 이미지
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
같은 원인 · 공통 노드 운영체제 이미지
IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.Grafana Labs · 2020같은 원인 · 공통 노드 풀
같은 원인 · 공통 노드 운영체제 이미지