Use a public standard load balancer in Azure Kubernetes Service (AKS)

The Azure Load Balancer operates at layer 4 of the Open Systems Interconnection (OSI) model that supports both inbound and outbound scenarios. It distributes inbound flows that arrive at the load balancer's front end to the back end pool instances.

A public load balancer integrated with AKS serves two purposes:

• Provide outbound connections to the cluster nodes inside the AKS virtual network (VNet) by translating the private IP address to a public IP address part of its outbound pool.
• Provide access to applications via Kubernetes services of type LoadBalancer, enabling you to easily scale your applications and create highly available services.

This article covers integration with a public load balancer on AKS. For internal load balancer integration, see Use an internal load balancer in AKS.

Prerequisites

• Azure Load Balancer is available in two SKUs: Basic and Standard. The Standard SKU is used by default when you create an AKS cluster. The Standard SKU gives you access to added functionality, such as a larger backend pool, multiple node pools, Availability Zones, and is secure by default. It's the recommended load balancer SKU for AKS. For more information on the Basic and Standard SKUs, see Azure Load Balancer SKU comparison.
• For a full list of the supported annotations for Kubernetes services with type LoadBalancer, see LoadBalancer annotations.
• This article assumes you have an AKS cluster with the Standard SKU Azure Load Balancer. If you need an AKS cluster, you can create one using Azure CLI, Azure PowerShell, or the Azure portal.

Limitations

The following limitations apply when you create and manage AKS clusters that support a load balancer with the Standard SKU:

• AKS manages the lifecycle and operations of agent nodes. Modifying the IaaS resources associated with the agent nodes isn't supported. An example of an unsupported operation is making manual changes to the load balancer resource group.

• At least one public IP or IP prefix is required for allowing egress traffic from the AKS cluster. The public IP or IP prefix is required to maintain connectivity between the control plane and agent nodes and to maintain compatibility with previous versions of AKS. You have the following options for specifying public IPs or IP prefixes with a Standard SKU load balancer:

  • Provide your own public IPs.
  • Provide your own public IP prefixes.
  • Specify a number up to 100 to allow the AKS cluster to create that many Standard SKU public IPs in the same resource group as the AKS cluster. This resource group is usually named with MC_ at the beginning. AKS assigns the public IP to the Standard SKU load balancer. By default, one public IP is automatically created in the same resource group as the AKS cluster if no public IP, public IP prefix, or number of IPs is specified. You also must allow public addresses and avoid creating any Azure policies that ban IP creation.

• A public IP created by AKS can't be reused as a custom bring your own (BYO) public IP address. You must create and manage all custom IP addresses.

• You can only define the load balancer SKU when you create an AKS cluster. You can't change the load balancer SKU after an AKS cluster has been created.

• You can only use one type of load balancer SKU (Basic or Standard) in a single cluster.

• Standard SKU load balancers only support Standard SKU IP addresses.

• Private Link Service isn't supported when the load balancer backend pool type is set to nodeIP.

Create a load balancer service in AKS

After you create an AKS cluster with outbound type LoadBalancer (default), your cluster is ready to use the load balancer to expose services.

• Create a service manifest named public-svc.yaml, which creates a public service of type LoadBalancer.

  apiVersion: v1
  kind: Service
  metadata:
    name: public-svc
  spec:
    type: LoadBalancer
    ports:
    - port: 80
    selector:
      app: public-app
  

Specify the load balancer IP address

If you want to use a specific IP address with the load balancer, you have two options to specify the IP address:

• Set service annotations (recommended): Use service.beta.kubernetes.io/azure-load-balancer-ipv4 for an IPv4 address and service.beta.kubernetes.io/azure-load-balancer-ipv6 for an IPv6 address.
• Add the LoadBalancerIP property to the load balancer YAML manifest: Add the Service.Spec.LoadBalancerIP property to the load balancer YAML manifest. This field is deprecating following upstream Kubernetes, and it can't support dual-stack. Current usage remains the same and existing services are expected to work without modification.

Deploy the load balancer service manifest

1. Deploy the public service manifest using kubectl apply and specify the name of your YAML manifest.

   kubectl apply -f public-svc.yaml
   

   The Azure Load Balancer is configured with a new public IP that fronts the new service. Since the Azure Load Balancer can have multiple frontend IPs, each new service that you deploy gets a new dedicated frontend IP to be uniquely accessed.

2. Confirm your service is created and the load balancer is configured using the kubectl get service command.

   kubectl get service public-svc
   

   When you view the service details, the public IP address created for this service on the load balancer is shown in the EXTERNAL-IP column of the output. It might take a few minutes for the IP address to change from <pending> to an actual public IP address. The following example output shows successful creation of the service:

   NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
   default       public-svc    LoadBalancer   10.0.39.110    203.0.113.187   80:32068/TCP    52s
   

3. Get more detailed information about your service using the kubectl describe service command.

   kubectl describe service public-svc
   

   The following example output is a condensed version of the output after you run kubectl describe service. LoadBalancer Ingress shows the external IP address exposed by your service. IP shows the internal addresses.

   Name:                        public-svc
   Namespace:                   default
   Labels:                      <none>
   Annotations:                 <none>
   Selector:                    app=public-app
   ...
   IP:                          10.0.39.110
   ...
   LoadBalancer Ingress:        203.0.113.187
   ...
   TargetPort:                  80/TCP
   NodePort:                    32068/TCP
   ...
   Session Affinity:            None
   External Traffic Policy:     Cluster
   ...
   

Next step