VNET迁移至新RG后AKS仍指向旧RG的问题咨询

• Azure跨资源组移动操作的引用同步逻辑存在明确支持边界：资源移动API默认只会更新ARM层面对应可移动资源的直接静态引用，不会主动触发AKS这类托管服务的内部配置调和流程。AKS控制面存储在AgentPoolProfiles中的VNET、子网资源ID属于托管服务内部维护的配置项，不在资源移动API的自动更新范围内。
• 将用户自行管理的VNET移入MC_前缀的AKS节点资源组本身属于不被官方推荐的操作：该资源组生命周期与AKS集群强绑定，AKS对组内资源拥有专属管控权限，外部移入的资源不会被纳入AKS的常规配置巡检范围，后续集群升级、节点重建等操作还可能误修改或删除这部分移入资源。
• Azure门户AKS网络配置页的加载逻辑，是直接读取控制面存储的VNET资源ID做存在性校验，当ID指向的旧资源组下不存在对应VNET时，会直接抛出资源校验失败的报错，不会自动跨资源组匹配同名VNET修正配置。

• 紧急恢复方案：第一时间将VNET移回原资源组"A"，等待5-10分钟让ARM缓存刷新后，确认门户网络配置页面加载恢复正常，即可消除报错。禁止在未更新AKS配置的前提下随意移动被集群引用的网络资源。
• 规范调整方案：如果确实需要将VNET部署到和节点资源组同位置，不要直接移动VNET。先在目标位置创建符合要求的VNET，再通过az aks update命令显式传入新的VNET、子网ID，触发AKS控制面配置更新，确认所有节点池的网络配置全部切换完成后，再删除旧资源组下的废弃VNET即可。
• 异常兜底方案：如果已经出现配置锁死、门户无法操作的情况，不要自行调用ARM接口修改AKS资源的只读属性，直接提交Azure支持工单，由后端运维人员修正控制面存储的VNET资源ID引用即可，自行修改只读属性有概率导致集群网络状态完全异常。

注意：MC_前缀的AKS节点资源组仅用于存放集群自动创建的节点、磁盘、负载均衡器等托管资源，请勿将用户自行管理的VNET、公网IP等资源存入该组，避免出现生命周期冲突、配置不同步等问题。

内容的提问来源于stack exchange，提问作者Lord Fausto