2026년 9월, Azure AKS에 파괴적 변경이 한꺼번에 몰렸다. 9월 8일 기존 Flatcar Container Linux 노드 이미지가 제거돼 스케일아웃·노드 복구가 실패할 수 있고, 9월 30일부터는 폐기된 Availability Sets(VMAS) 기반 클러스터가 VM 노드풀로 자동 마이그레이션된다.
여기에 Managed Gateway API가 Kubernetes 1.37에서 Gateway API v1.6.1 표준을 채택하며 TCPRoute·UDPRoute가 정식 승격됐고, 계층형 용량 보장을 내세운 AKS Hyperscale Control Plane 프리뷰가 공개됐다. 플랫폼팀 입장에서 이번 릴리스는 ‘읽고 넘길 체인지로그’가 아니라 ‘당장 클러스터를 점검해야 하는 알림’에 가깝다.
Azure의 AKS 2026-09-04 릴리스 노트를 열어보고 솔직히 좀 긴장했다. 대부분의 AKS 체인지로그는 새 기능 소개와 버전 범프가 반복되는데, 이번 건은 ‘제거’와 ‘자동 마이그레이션’이라는, 운영 클러스터를 실제로 흔드는 항목이 둘이나 들어있었다. 개인적으로 이런 릴리스는 기능 추가보다 훨씬 무섭다. 새 기능은 안 쓰면 그만이지만, 이미지 제거나 강제 마이그레이션은 내가 아무것도 안 해도 클러스터에 일이 벌어지기 때문이다. 이 글은 무엇이 바뀌었는지, 그리고 플랫폼팀이 지금 무엇을 확인하고 무엇을 막아야 하는지 순서대로 정리한다.
| 날짜 | 변경 | 영향 | 플랫폼팀 조치 |
|---|---|---|---|
| 9월 8일 | 기존 Flatcar Container Linux 노드 이미지 제거 | 해당 이미지 참조 노드의 스케일/복구 실패 | 노드 이미지 버전 점검 · 재이미지/업그레이드 |
| 9월 30일~ | 폐기된 VMAS 클러스터 → VM 노드풀 자동 마이그레이션 | 노드 재생성 · 순간 용량 변동 | 선제 수동 마이그레이션 · PDB/서지 점검 |
| K8s 1.37 | Managed Gateway API가 Gateway API v1.6.1 채택 | TCPRoute·UDPRoute 정식(GA) 사용 가능 | CRD 버전·라우트 매니페스트 확인 |
| 프리뷰 | AKS Hyperscale Control Plane | 계층형 용량 보장(대규모 클러스터) | 대상 클러스터면 프리뷰 평가 |
가장 급한 불 — 9월 8일 Flatcar 노드 이미지 제거
결론부터. 기존 Flatcar Container Linux 노드 이미지를 참조하는 노드풀은 스케일아웃이나 노드 복구 시점에 실패할 수 있다. 이미지 자체가 9월 8일자로 사용 가능 목록에서 빠졌기 때문이다. 이미 떠 있는 노드는 당장 죽지 않지만, 오토스케일러가 새 노드를 띄우거나, 헬스 문제로 노드를 재생성(reimage)하려 할 때 참조할 이미지가 없어 그 동작이 실패한다. 즉 평상시엔 멀쩡하다가 하필 부하가 몰려 스케일아웃이 필요한 순간에 터지는, 가장 나쁜 종류의 고장이다.
Flatcar는 컨테이너 전용 불변(immutable) OS로 AKS에서 대체 노드 OS로 선택할 수 있는 옵션이었다. 문제는 노드 이미지가 주기적으로 갱신·폐기된다는 점인데, 이번엔 ‘구버전 이미지 제거’가 스케일/복구 실패로 직결됐다. 특정 이미지 버전에 고정(pin)해 두었거나, 오래 재이미지 없이 굴러온 노드풀일수록 위험하다. 먼저 내 클러스터의 노드 이미지 버전부터 확인하자.
# 1) 노드풀별 현재 노드 이미지 버전과 OS SKU 확인
az aks nodepool list \
--resource-group myRG --cluster-name myAKS \
--query "[].{name:name, osSku:osSku, nodeImage:nodeImageVersion, count:count}" \
-o table
# 2) 실제 노드에 박힌 이미지 라벨도 교차 확인 (osSku=Flatcar 여부)
kubectl get nodes -o custom-columns=\
NODE:.metadata.name,\
OS:.status.nodeInfo.osImage,\
IMG:.metadata.labels.'kubernetes\.azure\.com/node-image-version'
# 3) Flatcar 노드풀이 확인되면 노드 이미지만 최신으로 업그레이드 (K8s 버전은 유지)
az aks nodepool upgrade \
--resource-group myRG --cluster-name myAKS \
--name flatcarpool \
--node-image-only \
--max-surge 33% # 서지 노드로 무중단에 가깝게 롤링현장 교훈 이런 ‘이미지 제거’류 사고는 배포 당일이 아니라 다음 트래픽 피크에 드러난다. 노드가 안 죽으니 알림도 안 뜨고, 오토스케일러가 조용히 실패 이벤트만 쌓다가 정작 스케일아웃이 필요한 순간 용량이 안 붙는다. kubectl get events -A | grep -i scale와 클러스터 오토스케일러 로그를 지금 한번 훑어보길 권한다.
9월 30일 — 폐기된 VMAS 클러스터가 VM 노드풀로 자동 이관된다
두 번째 핵심은 강제성이 있다는 점이다. 9월 30일부터 Azure는 이미 폐기(deprecated) 상태였던 Availability Sets(VMAS) 기반 AKS 클러스터를 VM 노드풀 방식으로 자동 마이그레이션한다. VMAS는 AKS 초창기의 노드 배치 방식으로, 이후 Virtual Machine Scale Sets(VMSS)와 새로운 ‘VM 노드풀’ 모델로 대체되며 오래전부터 신규 생성이 막혀 있었다. 이번 조치는 그 잔여 클러스터를 정리하는 마지막 단계다.
자동 마이그레이션이라고 해서 마음 놓을 일은 아니다. 노드 배치 인프라가 바뀐다는 건 결국 노드가 재생성된다는 뜻이고, 그 과정에서 파드가 옮겨 다니며 순간적인 용량 변동과 재스케줄이 일어난다. 마이그레이션 타이밍을 Azure가 잡으면 내가 통제할 수 없으니, 9월 30일 전에 유지보수 창을 잡아 스스로 마이그레이션하는 편이 훨씬 안전하다. 내 클러스터가 VMAS인지부터 확인하자.
# 클러스터의 노드풀 타입 확인 — type이 AvailabilitySet 이면 대상
az aks nodepool show \
--resource-group myRG --cluster-name myAKS --name nodepool1 \
--query "{name:name, type:type, count:count}" -o table
# type: AvailabilitySet → 마이그레이션 대상
# type: VirtualMachineScaleSets / VirtualMachines → 이미 신 모델대상이 맞다면, Azure가 제공하는 마이그레이션 경로를 유지보수 창에서 직접 실행한다. 마이그레이션 전에 반드시 확인할 건 PodDisruptionBudget(PDB)과 여유 용량이다. PDB가 너무 빡빡하면 노드 드레인이 막혀 마이그레이션이 지연되거나 멈춘다. 반대로 PDB가 아예 없으면 재스케줄 순간 가용성이 뚝 떨어진다.
# 1) 마이그레이션을 방해할 수 있는 PDB 사전 점검
kubectl get pdb -A -o custom-columns=\
NS:.metadata.namespace,NAME:.metadata.name,\
MIN:.spec.minAvailable,MAX:.spec.maxUnavailable,ALLOWED:.status.disruptionsAllowed
# 2) 스테이트풀/싱글 레플리카 워크로드 파악 (재스케줄에 취약)
kubectl get deploy,sts -A -o custom-columns=\
NS:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas \
| awk '$3==1'
# 3) 준비되면 유지보수 창에서 노드풀 마이그레이션 실행
# (Azure 문서의 VMAS→VM 마이그레이션 절차를 그대로 따른다)Managed Gateway API — v1.6.1 채택과 TCPRoute·UDPRoute 정식 승격
세 번째는 ‘깨는’ 변경이 아니라 기다리던 승격이다. Kubernetes 1.37에서 AKS의 Managed Gateway API가 Gateway API v1.6.1 표준을 채택하면서, 그동안 실험적으로만 쓸 수 있던 TCPRoute와 UDPRoute가 정식(GA)으로 승격됐다. 그동안 L7(HTTP) 트래픽은 HTTPRoute로 잘 다뤘지만, 순수 TCP/UDP 트래픽(데이터베이스 프록시, 게임 서버, DNS, 커스텀 바이너리 프로토콜)은 Gateway API 표준 안에서 다루기가 애매했다. 이제 그게 정식 스펙으로 들어왔다.
Gateway API가 뭔지 짧게 짚자. 기존 Ingress가 벤더별 어노테이션 지옥으로 갈라졌던 걸 정리하려고 나온 후속 표준이다. 역할이 GatewayClass(인프라 제공자) / Gateway(리스너·포트) / *Route(라우팅 규칙)로 분리돼, 플랫폼팀과 앱팀의 책임 경계가 명확하다. TCPRoute·UDPRoute의 GA는 이 역할 분리를 L4까지 확장했다는 의미다.
| 리소스 | 다루는 트래픽 | 이번 상태 | 대표 용도 |
|---|---|---|---|
| HTTPRoute | L7 HTTP/HTTPS | 기존 GA | 경로/헤더 기반 라우팅, 카나리 |
| TCPRoute | L4 TCP | 정식 승격(GA) | DB 프록시, 커스텀 TCP 서비스 |
| UDPRoute | L4 UDP | 정식 승격(GA) | DNS, 게임 서버, 로그 수집 |
| GRPCRoute | L7 gRPC | 표준 포함 | 서비스 간 gRPC 라우팅 |
TCPRoute는 이렇게 쓴다. HTTPRoute와 달리 경로·헤더 매칭이 없고, 리스너 포트로 들어온 TCP 스트림을 백엔드 서비스로 그대로 전달한다.
# Gateway 리스너에 TCP 포트를 열고
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: l4-gateway
spec:
gatewayClassName: azure-managed-gateway # AKS Managed Gateway
listeners:
- name: postgres
protocol: TCP
port: 5432
allowedRoutes:
kinds:
- kind: TCPRoute
---
# TCPRoute로 그 포트를 백엔드 서비스에 연결
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: pg-proxy
spec:
parentRefs:
- name: l4-gateway
sectionName: postgres
rules:
- backendRefs:
- name: postgres-svc
port: 5432apiVersion은 리소스마다 다를 수 있다(Gateway는 v1, TCPRoute는 아직 v1alpha2 그룹에 있는 식). 클러스터에 설치된 CRD 버전을 kubectl get crd tcproutes.gateway.networking.k8s.io -o jsonpath='{.spec.versions[*].name}'로 먼저 확인하고 매니페스트를 맞추자. 문서만 보고 v1으로 썼다가 CRD에 그 버전이 없어 apply가 튕기는 경우가 흔하다.AKS Hyperscale Control Plane 프리뷰 — 계층형 용량 보장
네 번째는 대규모 클러스터를 굴리는 팀에게만 해당하는 프리뷰다. AKS Hyperscale Control Plane은 컨트롤플레인(API 서버·etcd 등)에 계층형 용량 보장(tiered capacity)을 제공하는 기능으로 프리뷰 공개됐다. 쉽게 말해, 노드·파드 수가 아주 많은 클러스터에서 컨트롤플레인이 병목이 되지 않도록 더 높은 용량 계층을 보장받는 것이다.
AKS의 관리형 컨트롤플레인은 기본적으로 Azure가 알아서 규모를 조절하지만, 수천 노드·수만 파드 규모로 가면 API 서버 처리량, 리스트/워치 부하, etcd 용량이 실제 한계로 다가온다. Hyperscale 계층은 이런 초대형 클러스터에 예측 가능한 컨트롤플레인 성능을 계약처럼 보장하려는 시도로 읽힌다. 아직 프리뷰이니 프로덕션 도입은 이르지만, 단일 거대 클러스터를 운영하거나 멀티테넌시로 클러스터당 밀도를 극단적으로 높이는 팀이라면 지금부터 평가 대상에 올려둘 만하다.
플랫폼팀 대비 체크리스트 — 지금 순서대로
이번 릴리스에서 실제로 ‘터질 수 있는’ 건 앞의 두 항목(Flatcar 이미지 제거, VMAS 자동 마이그레이션)이다. 나머지 둘은 기회에 가깝다. 그래서 우선순위는 명확하다. 아래 순서대로 훑으면 된다.
- [긴급] Flatcar 노드풀 색출 —
osSku가 Flatcar인 노드풀이 있는지, 노드 이미지 버전이 오래됐는지 확인. 있으면--node-image-only업그레이드로 최신 이미지로 롤링. - [긴급] 오토스케일러/복구 실패 이벤트 확인 — 이미 스케일아웃·재이미지가 조용히 실패하고 있지 않은지 이벤트와 오토스케일러 로그 점검.
- [중요] VMAS 클러스터 색출과 선제 마이그레이션 — 노드풀
type이 AvailabilitySet인 클러스터를 찾아, 9월 30일 이전에 유지보수 창을 잡아 직접 VM 노드풀로 이관. PDB·싱글 레플리카 워크로드 사전 점검 필수. - [계획] Gateway API v1.6.1 활용 — L4(TCP/UDP)를 Ingress 우회 방식으로 다루던 부분을 TCPRoute·UDPRoute GA로 표준화 검토. CRD 버전부터 확인.
- [평가] Hyperscale Control Plane — 초대형 클러스터를 굴린다면 별도 평가 클러스터에서 프리뷰 검증.
한 가지 더. 이번처럼 강제 변경이 예고되는 시점엔 클러스터 인벤토리가 곧 방어력이다. 구독·리소스그룹을 가로질러 ‘노드풀 타입·OS SKU·노드 이미지 버전·K8s 버전’을 한 표로 뽑아두면, 이런 릴리스가 나올 때마다 ‘내 클러스터 중 몇 개가 대상인가’를 몇 분 만에 답할 수 있다. 나는 이걸 스크립트로 돌려 주기적으로 갱신한다.
# 구독 전체 AKS 인벤토리 한 번에 뽑기 (대상 클러스터 색출용)
for c in $(az aks list --query "[].{n:name,g:resourceGroup}" -o tsv); do
name=$(echo "$c" | cut -f1); rg=$(echo "$c" | cut -f2)
az aks nodepool list -g "$rg" --cluster-name "$name" \
--query "[].{cluster:'$name', pool:name, type:type, osSku:osSku, img:nodeImageVersion}" \
-o tsv
done자주 묻는 질문
Flatcar 노드 이미지가 제거됐는데 지금 떠 있는 노드도 곧 죽나요?
이미 실행 중인 노드가 그 자리에서 즉시 죽는 건 아닙니다. 문제는 새 노드를 만들거나 노드를 재이미지할 때 발생합니다. 오토스케일러의 스케일아웃, 헬스 이슈로 인한 노드 복구, 노드풀 확장 같은 동작이 제거된 이미지를 참조하면 실패합니다. 그래서 트래픽 피크에 스케일아웃이 안 되는 형태로 드러나기 쉽습니다. 최신 노드 이미지로 업그레이드해 두는 게 유일한 해법입니다.
내 클러스터가 VMAS인지 어떻게 빨리 확인하나요?
az aks nodepool show ... --query "type" 결과가 AvailabilitySet이면 대상입니다. VirtualMachineScaleSets나 VirtualMachines면 이미 신 모델이라 이번 자동 마이그레이션과 무관합니다. VMAS는 오래전 신규 생성이 막혔기 때문에, 대상이 되는 건 대체로 수년째 유지해온 오래된 클러스터입니다.
9월 30일 자동 마이그레이션을 그냥 Azure에 맡기면 안 되나요?
맡길 수는 있지만 권하지 않습니다. 자동 마이그레이션도 결국 노드를 재생성하므로 파드 재스케줄과 순간 용량 변동이 발생하는데, 타이밍을 Azure가 정하면 하필 트래픽이 많은 시간에 걸릴 수 있습니다. 유지보수 창을 직접 잡아 선제적으로 마이그레이션하고, 그 전에 PDB와 싱글 레플리카 워크로드를 점검하는 편이 훨씬 통제 가능합니다.
TCPRoute·UDPRoute가 GA면 이제 L4 로드밸런서 서비스를 걷어내도 되나요?
상황에 따라 다릅니다. Gateway API의 TCPRoute·UDPRoute는 type: LoadBalancer 서비스나 벤더별 Ingress 어노테이션으로 흩어져 있던 L4 노출을 표준 리소스로 통합할 수 있게 해줍니다. 다만 기존 서비스가 잘 돌고 있다면 서두를 이유는 없고, 새로 L4 트래픽을 노출하거나 라우팅 정책을 표준화하고 싶을 때 도입하는 게 현실적입니다.
Gateway API v1.6.1을 쓰려면 무조건 K8s 1.37로 올려야 하나요?
AKS의 Managed Gateway API가 v1.6.1 표준을 채택한 기준선이 Kubernetes 1.37입니다. 따라서 TCPRoute·UDPRoute의 정식 지원을 온전히 받으려면 해당 버전대로 컨트롤플레인을 올리는 것이 전제입니다. 업그레이드 전에는 반드시 스테이징에서 CRD 버전과 기존 라우트 매니페스트의 호환성을 확인하세요.
Hyperscale Control Plane 프리뷰, 일반 규모 클러스터도 켜는 게 이득인가요?
아닙니다. 이 기능은 노드·파드 수가 매우 많아 컨트롤플레인이 병목이 되는 초대형 클러스터를 위한 것입니다. 일반 규모 클러스터는 기본 관리형 컨트롤플레인으로 충분하며, 프리뷰는 SLA도 없습니다. 단일 거대 클러스터나 고밀도 멀티테넌시를 운영하는 경우에만 별도 평가 클러스터에서 검토하는 걸 권합니다.
이번 변경들이 한 번에 몰린 이유가 뭔가요?
성격이 다른 항목들이 우연히 같은 릴리스 창에 겹쳤다고 보는 게 맞습니다. Flatcar 이미지 제거와 VMAS 마이그레이션은 레거시 정리 흐름이고, Gateway API v1.6.1과 Hyperscale은 신규 표준·기능 확장 흐름입니다. 플랫폼팀 입장에서 중요한 건 배경이 아니라 ‘내 클러스터가 앞의 두 레거시 정리 대상에 걸리는가’를 먼저 확인하는 것입니다.
댓글 0