This feature has been generally available for a quite a while, so most people understand how it works in general. This article digs a little deeper on everything behind the scene.
This official documentation would give you an idea why Azure Private Link was created in the first place. The main idea is to keep the service communication within Microsoft backbone for security reasons. However, it does not give you much about how it works in practice.
After you follow this official documentation to create a “private” AKS, you would notice a few resources being created in the 2 newly created resource groups.
- The resource group I created is called “RG-PrivateAKS”
- Azure created “MC_RG-PrivateAKS_privatejonwaks_westus2” (the naming convention follows “MC_” + “the resource group name you provided” + “the AKS resource name you provided” + “region”)
In “RG-PrivateAKS”, you would mostly just see Azure Kubernetes Service and the associated virtual network.
In “MC_RG-PrivateAKS_privatejonwaks_westus2”, let’s focus on the newly created private domain name services (DNS) zone, private endpoint and a network interface.
In overview, an A record has been created for the kube api server.
On the left panel, if you select “Virtual network links”, the AKS associated virtual network is being linked to this DNS zone.
This is basically what administrators/users would get out of the box after following the documentation of creating “private” AKS. Let’s go further and see how to connect to the AKS cluster.
Based on this section of the documentation, there are at least 3 ways to connect to “private” AKS.
- Create a virtual machine (VM) within the AKS virtual network and use that VM as the contact point
- Crate a VM in other Azure virtual networks and create virtual network peering to the AKS virtual network. At the same time, link the virtual network to the private DNS zone located in “MC_RG-PrivateAKS_privatejonwaks_westus2”
- Create a VM in environments not on Azure, but use site-to-site virtual private network (VPN) or express route to connect to Azure virtual networks
For the first option, it is quite easy to test. Here is the result. (Detailed instructions on how to create, connect to an Azure VM, how to install related tools for an user to connect to AKS cluster would be shared in another article.)
When we try to resolve “private” AKS fully qualified domain name (FQDN), it really resolves into a private IP address within the associated virtual network/subnet.
Right now, we know by linking the virtual network to the private DNS zone and using the resources within the linked virtual network could actually let administrators/users contact “private” AKS without issues. Moving on to the second approach.
Adding a new virtual network “VNet-PrivateAKS2” and creating another VM “PrivateAKS2-U1804” in virtual network “VNet-PrivateAKS2”.
Peering “VNet-PrivateAKS2” with the original AKS virtual network “RG-PrivateAKS-vnet”. Do make sure the peering shows “Connected” the other way around.
Linking “VNet-PrivateAKS2” with the private DNS zone.
Finally, testing the accessibility to “private” AKS cluster.
You could see this VM’s network information down below. The VM is located in a different virtual network but it could still successfully resolve “private” AKS FQDN to IP address.
At this point, we are sure if using a resource in a different virtual network than the one AKS is located on, as long as the virtual network is peered with the AKS virtual network and linked with the private DNS zone. There should be no issues.
What if the external virtual network just peered with the AKS virtual network but NOT linked with private DNS zone?
After removing virtual network “VNet-PrivateAKS2” from private DNS zone, using “kubectl get nodes” would return error messages like below.
If we manually add a DNS record in the VM hosts file, what would happen?
We could again contact “private” AKS without issues, meaning linking any virtual network to private DNS zone is just for DNS resolution.
The same logic applies to any environment. As long as your network could have access to the DNS servers that could successfully resolve “private” AKS FQDN into private IP address, there should be no issues to contact the service.
Additional Information
If you happen to be provisioning Azure Container Registry (ACR) with Private Link just like “private” AKS, you would notice every concept we discuss above would apply. The only difference is the private domain name.
For “private” AKS, it is
For “private” ACR, it is
If we neither link the virtual network to the private DNS zone nor add specific A record in hosts file, each “private” service FQDN would actually resolve in public IP address.
Because Azure Private Link was never making the service private, but making the service to be only resolvable and accessible in specific network environment. Hope this article helps some people along the Azure learning journey!
