This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 9%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EFG%3C/text%3E%3C/svg%3E)
We plan to provide seprate environments for several larger customers and have therefore decided to go for a hub spoke network topology. We set up the following resource structure to solve this efficiently and securely:
Multiple environments (dev, staging, prod, prod-customer-1, prod-customer-2, etc) which each use a separate vnet and reside in a separate subscription for cost control. The hub vnet currently resides in the prod subscription. There were no issues setting up this system and it currently works flawlessly with shared private dns zones (one private dns zone "private.westeurope.azmk8s.io" residing in prod subscription and linked to all vnets).
However, when I try to upgrade the dev aks cluster to a new version I get the error
(NotFound) Private dns zone resource '...' nod found.
The dev aks cluster resides in the dev vnet on the dev subscription. The according private dns zone is linked to said vnet. DNS resolution happens in hub vnet. Private dns zone is linked to hub vnet as well and dev and hub vnet are linked to each other.
Can anyone point out why the AKS cluster version upgrade might fail with this constellation? I've (re-)read a lot of documentation regarding private endpoints and hub spoke networks and I feel like our resource structure meets all best practices.
@Fabien Graf
The error message "NotFound Private dns zone resource" indicates that the private DNS zone resource linked to the dev AKS cluster cannot be found. This error can occur when the private DNS zone is not linked to the VNet containing the custom DNS resolvers. In this case, the dev AKS cluster resides in the dev VNet on the dev subscription, and the corresponding private DNS zone is linked to that VNet. However, DNS resolution happens in the hub VNet, and the private DNS zone is linked to the hub VNet as well. To resolve this issue, the private DNS zone needs to be linked to the VNet that contains the custom DNS resolvers, which is the hub VNet in this case. This link can be created manually after the private zone is created during cluster provisioning or via automation upon detection of creation of the zone using event-based deployment mechanisms (for example, Azure Event Grid and Azure Functions).
References:
AI Note: This answer is generated using the Microsoft Q&A AI Assist tool.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(76.8, 74%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAN%3C/text%3E%3C/svg%3E)
Hello @Fabien Graf,
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help