It appears that when you try to create a private AKS cluster it creates a private dns zone file in the AKS managed resource group and attaches it to the VNet. Deployment should recognize that there is already a privatelink.eastus.azmk8s.io private zone attached. Deployment needs to be able to update zone file in current subscription or a separate subscription as well since you could only have one central DNS forwarder in a hub and spoke model with ER. This functionality would make it consistent with existing private endpoint deployments.
Will attempt to manually create and test "workspaceName-dns-randomNumber.privateDNSZoneGuid" DNS entry in the privatelink.eastus.azmk8s.io central zone file while also deleting the VNet link from the "privateDNSZoneGuid.privatelink.eastus.azmk8s.io" zone file and see if still functional.
It appears that when you try to create a private AKS cluster it creates a private dns zone file in the AKS managed resource group and attaches it to the VNet. Deployment should recognize that there is already a privatelink.eastus.azmk8s.io private zone attached. Deployment needs to be able to update zone file in current subscription or a separate subscription as well since you could only have one central DNS forwarder in a hub and spoke model with ER. This functionality would make it consistent with existing private endpoint deployments.
Will attempt to manually create and test "workspaceName-dns-randomNumber.privateDNSZoneGuid" DNS entry in the privatelink.eastus.azmk8s.io central zone file while also deleting the VNet link from the "privateDNSZoneGuid.privatelink.eastus.azmk8s.io" zone file and see if still functional.