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(288, 57.99999999999999%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAP%3C/text%3E%3C/svg%3E)
When I try running aks get-credentials against a specific private cluster, it seems to be adding the wrong hostname to my kube config.
The get-credentials command adds a hostname the privatelink.eastus.azmk8s.io domain, but the cluster's hostname is actually in the hcp.eastus.azmk8s.io domain. If I correct the hostname in the kube config to the correct hostname, I can connect to the cluster fine.
What is going on with the get-credentials command to trigger this behavior?
The Azure Portal shows a hostname in the hcp.eastus.azmk8s.io which works, but az aks show has the privateFqdn for the cluster in the privatelink.eastus.azmk8s.io domain.
Hello @Aaron Peschel ,
Thank you for reaching Microsoft Q&A Platform. Please find the answer below for your query.
When you provision a private AKS cluster, AKS by default creates a private FQDN with a private DNS zone and an additional public FQDN with a corresponding A record in Azure public DNS. The agent nodes still use the A record in the private DNS zone to resolve the private IP address of the private endpoint for communication to the API server. Reference
Thus the primary FQDN for the Private AKS cluster is the private FQDN ( *.privatelink.<region>.azmk8s.io ). The public FQDN ( *.hcp.eastus.azmk8s.io ) is optional and you may choose to disable it. Reference
The Azure Portal Azure Kubernetes Service Blade is reflects the public FQDN if it is enabled, else it reflects the private FQDN. However, if you run the az aks show command from the Azure CLI you would find both:
...
"fqdn": "akstest-test-xxxxxx-xxxxxxxx.hcp.eastus.azmk8s.io",
...
"privateFqdn": "akstest-test-xxxxxx-xxxxxxxx.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.privatelink.eastus.azmk8s.io",
...
However, az aks get-credentials merges only the primary FQDN (in case of the private AKS cluster, that would be the private FQDN) to the ~/.kube/config file in your local environment.
Since the private FQDN is not resolvable over public internet hence using that would not help you connect to the private AKS cluster's API server over the internet. However, if you did not disable the public FQDN, then it can be used in the ~/.kube/config file to connect to the private AKS cluster's API server.
You can also follow the documentation here to access the private AKS cluster remotely.
Hello @Prrudram-MSFT
I've been going over what you said, and it all mostly makes sense. However, I think I'm hitting something weird. The private FQDN has an IP address that makes no sense, and doesn't resolve on any network, and the "public" FQDN has the correct IP for the private network. If the IP associated with private FQDN was correct, then what you're saying would make complete sense. I'm trying to disable the public FQDN as well, and that doesn't seem to be working - the public FQDN keeps showing up for the cluster.
Looks like disabling the public FQDN did work, so it's just that the private FQDN is not resolving to the correct IP.
Sometimes it resolves to a completely non-sense IP, other times it doesn't resolve at all.
![](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(313.6, 85%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERB%3C/text%3E%3C/svg%3E)
This answer was super helpful! Thank you for the articulate detail that helps us understand why the private FQDN is still used for kubectl config.
Hi @Aaron Peschel ,
I am glad the information provided has helped you comprehend this scenario. Further to your follow up queries, the private FQDN would not resolve to a public IP address. It resolves to an IP address from the private IP address space of the AKS cluster's VNET/subnet. So unless you are connected to the AKS cluster VNET (through VPN, Expressroute etc.) the connection cannot be made to the API Server using the IP address resolved from the private FQDN.
Please do not forget to 
and 
wherever the information provided helps you, this can be beneficial to other community members.