AKS Networking - API Server
- Nathan
- Aug 2
- 3 min read
The Kubernetes API server is the core of the Kubernetes control plane and is the central way to interact with and manage your clusters. It runs the kube-apiserver, kube-controller-manager, kube-scheduler, and other core components. For AKS clusters, Microsoft will always host this API Server themselves. As of the time of this writing, there is no other option.
With that being said, you do get a choice on what kind of networking to use for the API Server. There are currently 3 options: public, private, and Virtual Network integration. In this post we will be going over the 3 options in detail. DNS settings can vary between the 3 options, so I will make sure to highlight that. I will also highlight the necessary Bicep settings to use if you are the type of person who likes to use infrastructure-as-code (IaC).
API Server - Public Access
This is the simplest option to understand. This will create a public DNS record that points directly at your API Server's public IP address.
This means your API Server is exposed to the internet and can be accessed by any internet-connected machine. However, the API Server does have its own resource-level firewall where you can enable only specific authorized IP ranges to connect.
API Server - Private Access
If you don't like the idea of your API Server being publicly accessible, then one option you have is to deploy a Private AKS cluster. In a Private cluster, your API Server will get a Private Endpoint inside your own private Azure Virtual Network.
This means you can only connect to the API Server from a device that has network connectivity to your private Azure Virtual Network where the private endpoint is located. However, there is one workaround to this. You could use the Azure CLI (from anywhere) to invoke a command against the private API Server. This functionality can be disabled, if you wish.
Private Clusters have multiple different options for DNS configuration:
Option 1 is to NOT use a Private DNS Zone. This will create a public DNS record that points directly at your Private Endpoint's private IP address.
Option 2 is to use a Private DNS Zone and select the option to create a public DNS record as well. This will create a DNS record in your selected Private DNS Zone that points at your Private Endpoint's private IP address. It will also create a DNS record in Public DNS for the same thing.
Option 3 is to use a Private DNS Zone and not select the option to create a public DNS record. This will create a DNS record in your selected Private DNS Zone that points at your Private Endpoint's private IP address. But, it will NOT create a DNS record in Public DNS.
API Server - VNet Integration
This option projects the API Server directly into a delegated Subnet in your Virtual Network. An AKS Cluster will reserve at least 9 IP addresses in this Subnet, so the minimum supported Subnet size is /28. The API server is available behind an internal Load Balancer that is created in this delegated Subnet.
Note: VNet Integration currently has limited availability and is only available in certain Azure regions.
VNet Integration allows you to pick either Public or Private access for your API Server. You can even enable or disable Public access after the cluster has been created. But, no matter what option you choose, your AKS cluster nodes will always communicate directly with the private IP address of the load balancer without using DNS. Outside clients needing to communicate with the API server can do so normally by using the API Server's DNS record, which will be either public or private depending on your chosen settings.
The first screenshot above shows the Public option, while the second screenshot shows the Private option. Public clusters will create a public DNS record that points directly at your API Server's public IP address. Private clusters have multiple different options for DNS configuration. Please see the 3 options in the previous section as they apply here as well.