AKS 를 자체 VNet 에 올리는 순간 두 가지가 따라온다. 생성 시점에는 관리 ID 요건이 걸리고, 삭제 시점에는 AKS 가 만들지 않은 리소스가 남아 있어 정리가 멈추는 문제가 생긴다. 두 문제 모두 원인은 하나다 — AKS 관리형 리소스 그룹(MC_*)과 사용자 리소스가 같은 네트워크를 공유하고 있다는 것.
노드 풀 생성이 Preflight 에서 다음 메시지로 막힌다.
Preflight validation check for resource(s) for container service <name> in resource group <rg> failed.
Message: For agentpool of type 'VirtualMachines' to use custom VNet, the cluster must utilize a
user-assigned managed identity. Additionally, the user-assigned identity must possess at least
'Network Contributor' permissions on the subnet.
AKS 는 노드를 만들 때 NIC 생성 · IP 할당 · 로드 밸런서 백엔드 등록 · 경로 테이블 조작을 클러스터 자신의 관리 ID 권한으로 수행한다. 시스템 할당 ID 는 MC_* 리소스 그룹 안에서만 권한을 자동으로 받으므로, 사용자가 따로 만든 VNet · 서브넷은 건드리지 못한다.
| 구분 | 시스템 할당 | 사용자 할당(UAMI) |
|---|---|---|
| ID 생성 | AKS 가 자동 | 사용자가 먼저 만들어 둠 |
MC_* 리소스 권한 |
자동 부여 | 자동 부여 |
| 사용자 VNet · 서브넷 권한 | 없음 | 역할 할당으로 부여 가능 |
절차는 세 단계다.
# 1. 사용자 할당 관리 ID 생성
az identity create -g ${RG} -n ${UAMI_NAME}
UAMI_ID=$(az identity show -g ${RG} -n ${UAMI_NAME} --query id -o tsv)
UAMI_PRINCIPAL=$(az identity show -g ${RG} -n ${UAMI_NAME} --query principalId -o tsv)
# 2. 서브넷에 Network Contributor 역할 부여 (VNet 이 아니라 서브넷 범위)
SUBNET_ID=$(az network vnet subnet show -g ${RG} --vnet-name ${VNET} -n ${SUBNET} --query id -o tsv)
az role assignment create \
--assignee-object-id ${UAMI_PRINCIPAL} --assignee-principal-type ServicePrincipal \
--role "Network Contributor" --scope ${SUBNET_ID}
# 3. 클러스터 생성 시 ID 지정
az aks create -g ${RG} -n ${AKS_NAME} \
--enable-managed-identity --assign-identity ${UAMI_ID} \
--vnet-subnet-id ${SUBNET_ID} --network-plugin azure
권한 범위를 VNet 이 아니라 서브넷에 주는 것이 요점이다. 구독에 Contributor 가 있어도 소용없다 — 작업 주체는 사람이 아니라 클러스터의 관리 ID 이기 때문이다. 공식 요건은 AKS 문서의 사용자 지정 VNet 절에 정리돼 있다.[1]
클러스터를 지울 때 나오는 전형적인 메시지다.
Network Interface .../networkInterfaces/nfs-vm is used by existing resource
.../virtualMachines/agent-nfs-jump. In order to delete the network interface,
it must be dissociated from the resource.
Subnet aks-appgateway is in use by .../networkInterfaces/AGENT-NFS-JUMP581/ipConfigurations/IPCONFIG1
and cannot be deleted.
Network security group .../basicNsgnfs-vm cannot be deleted because it is in use by
.../networkInterfaces/NFS-VM.
세 줄이 서로 다른 문제로 보이지만 원인은 하나다. AKS 서브넷 안에 수동으로 만든 VM(NFS · 점프 · 테스트용)이 들어가 있다. AKS 는 클러스터를 지우면서 MC_* 리소스 그룹의 네트워크 자원을 함께 정리하려 하는데, 그 안의 NIC 가 외부 리소스 그룹의 VM 에 붙어 있으면 해제할 방법이 없어 전체 삭제가 실패한다.
의존 관계는 VM → NIC → 서브넷 · NSG 순서다. 따라서 정리도 그 역순으로 한다.
# 1. 어느 리소스가 붙잡고 있는지 확인
az network nic list -g ${MC_RG} --query "[].{nic:name, vm:virtualMachine.id}" -o table
az network vnet subnet show -g ${RG} --vnet-name ${VNET} -n ${SUBNET} \
--query "ipConfigurations[].id" -o tsv
# 2. VM 을 먼저 삭제 (NIC · 디스크 동시 삭제 옵션 포함)
az vm delete -g ${RG} -n ${VM_NAME} --yes
# 3. 남은 NIC · NSG · 공용 IP 를 개별 삭제한 뒤 클러스터 삭제 재시도
az aks delete -g ${RG} -n ${AKS_NAME} --yes
운영 원칙으로 정리하면 이렇다 — AKS 가 쓰는 서브넷에는 AKS 노드만 둔다. NFS 서버나 점프 VM 은 같은 VNet 안의 다른 서브넷에 둔다. 같은 VNet 이면 서브넷이 달라도 기본 라우팅으로 통신되므로 기능상 손해가 없고, 클러스터를 재설치할 때 네트워크가 통째로 발이 묶이지 않는다.
위 절차대로 VM 을 지우면 OS 디스크는 사라진다. NFS 서버처럼 데이터를 들고 있는 VM 은 데이터를 데이터 디스크(별도 관리 디스크)에 두고, VM 삭제 시 데이터 디스크는 함께 지우지 않도록 한다. 새 VM 을 만든 뒤 기존 관리 디스크를 연결하면 그대로 복구된다.
# 새 VM 에 기존 데이터 디스크 연결
az vm disk attach -g ${RG} --vm-name ${NEW_VM} --name ${DATA_DISK}
# VM 안에서 장치 확인 후 마운트
lsblk -f
mount /dev/sdc1 /data
lsblk -f 로 파일 시스템과 UUID 를 먼저 확인한다. 파티션이 있는 디스크인데 /dev/sdc 를 통째로 마운트하면 데이터가 안 보이거나 마운트가 실패한다. 마운트가 끝나면 /etc/fstab 에 UUID 로 등록해 재부팅 후에도 붙게 한다.
AKS — Azure CNI 네트워킹 구성. https://learn.microsoft.com/azure/aks/configure-azure-cni ↩︎