AKS with Azure Load Balancer - Commands & Configuration

Introduction

When you run applications on Azure Kubernetes Service, you need a way to let users reach your app from the internet. Azure Load Balancer helps by spreading incoming traffic evenly to your app's containers, so it stays fast and reliable.

When you want to expose a web app running in AKS to the internet with a stable IP address.

When you need to balance traffic across multiple pods to avoid overloading one container.

When you want automatic health checks to send traffic only to healthy pods.

When you want a simple, built-in way to expose your AKS service without extra setup.

When you want to use Azure's native load balancing features for your Kubernetes workloads.

Config File - service-loadbalancer.yaml

service-loadbalancer.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
  labels:
    app: my-app
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

This file defines a Kubernetes Service of type LoadBalancer.

type: LoadBalancer tells AKS to create an Azure Load Balancer to route traffic.

selector matches pods with label app: my-app to send traffic to.

ports maps port 80 on the load balancer to port 8080 on the pods.

Commands

This command creates the LoadBalancer service in AKS, which triggers Azure to provision a load balancer and assign a public IP.

Terminal

kubectl apply -f service-loadbalancer.yaml

Expected Output

service/my-app-service created

This command checks the status of the service and shows the external IP assigned by Azure Load Balancer.

Terminal

kubectl get services my-app-service

Expected Output

NAME             TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)        AGE

my-app-service   LoadBalancer   10.0.123.45   52.170.12.34    80:31234/TCP   1m

This command shows detailed information about the service, including the load balancer's IP and backend pods.

Terminal

kubectl describe service my-app-service

Expected Output

Name:                     my-app-service

Namespace:                default

Labels:                   app=my-app

Annotations:              <none>

Selector:                 app=my-app

Type:                     LoadBalancer

IP:                       10.0.123.45

LoadBalancer Ingress:     52.170.12.34

Port:                     80/TCP

TargetPort:               8080/TCP

Endpoints:                10.244.1.5:8080,10.244.1.6:8080

Session Affinity:         None

Events:

  Type    Reason                Age   From                Message

  ----    ------                ----  ----                -------

  Normal  EnsuringLoadBalancer  2m    service-controller  Ensuring load balancer

  Normal  EnsuredLoadBalancer   1m    service-controller  Ensured load balancer

Key Concept

If you remember nothing else from this pattern, remember: setting the service type to LoadBalancer in AKS automatically creates an Azure Load Balancer with a public IP to route traffic to your pods.

Common Mistakes

Not labeling pods with the selector label used in the service.

The load balancer cannot find any pods to send traffic to, so your app won't receive requests.

Make sure your pods have the label 'app: my-app' to match the service selector.

Using the wrong port numbers in the service spec.

Traffic won't reach the correct port on your containers, causing connection failures.

Set 'port' to the external port (e.g., 80) and 'targetPort' to the container's listening port (e.g., 8080).

Expecting the external IP to appear immediately after creating the service.

Azure Load Balancer provisioning takes time, so the external IP may show as <pending> initially.

Wait a few minutes and re-run 'kubectl get services' to see the assigned external IP.

Summary

Create a Kubernetes Service of type LoadBalancer to expose your app in AKS.

Apply the service YAML with kubectl to trigger Azure Load Balancer creation.

Check the service status to find the external IP address for accessing your app.

Practice

1. What is the primary purpose of using an Azure Load Balancer with AKS (Azure Kubernetes Service)?

easy

A. To store data persistently for containers

B. To distribute incoming network traffic evenly across multiple pods

C. To build container images automatically

D. To monitor container resource usage

Solution

1. Step 1: Understand AKS and Load Balancer roles

   AKS runs containerized apps, and Azure Load Balancer distributes traffic to these apps.

2. Step 2: Identify the main function of Load Balancer

   It balances incoming requests across pods to improve availability and scalability.

3. Final Answer:

   To distribute incoming network traffic evenly across multiple pods -> Option B

4. Quick Check:

   Load Balancer = traffic distribution [OK]

Hint: Load Balancer = spreading traffic evenly [OK]

Common Mistakes:

• Confusing Load Balancer with storage or monitoring
• Thinking Load Balancer builds container images
• Assuming Load Balancer manages pod resources

2. Which Kubernetes service type should you specify in your AKS deployment YAML to create an Azure Load Balancer automatically?

easy

A. LoadBalancer

B. NodePort

C. ClusterIP

D. ExternalName

Solution

1. Step 1: Review Kubernetes service types

   ClusterIP exposes service internally, NodePort exposes on node port, LoadBalancer creates cloud LB, ExternalName maps to external DNS.

2. Step 2: Identify service type for Azure Load Balancer

   Using type: LoadBalancer triggers Azure to provision a Load Balancer automatically.

3. Final Answer:

   LoadBalancer -> Option A

4. Quick Check:

   Service type LoadBalancer = Azure LB creation [OK]

Hint: Use type LoadBalancer to get Azure LB automatically [OK]

Common Mistakes:

• Choosing ClusterIP which is internal only
• Confusing NodePort with automatic LB creation
• Using ExternalName which is DNS mapping only

3. Given this Kubernetes service YAML snippet in AKS:

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

What happens when this service is applied?

medium

A. An Azure Load Balancer is created and routes port 80 traffic to pods on port 8080

B. Pods are exposed only inside the cluster on port 8080

C. Traffic on port 8080 is blocked by default

D. A NodePort service is created exposing port 80 on all nodes

Solution

1. Step 1: Analyze service type and ports

   Service type is LoadBalancer, so Azure LB is created. It listens on port 80 externally and forwards to targetPort 8080 on pods.

2. Step 2: Understand traffic flow

   External traffic on port 80 hits Azure LB, which routes it to pods' port 8080 matching selector app: myapp.

3. Final Answer:

   An Azure Load Balancer is created and routes port 80 traffic to pods on port 8080 -> Option A

4. Quick Check:

   LoadBalancer + port mapping = external traffic routing [OK]

Hint: LoadBalancer routes external port to pod targetPort [OK]

Common Mistakes:

• Thinking pods are exposed only internally
• Confusing NodePort with LoadBalancer
• Assuming traffic is blocked without explicit rules

4. You deployed an AKS service with type: LoadBalancer, but the external IP remains <pending> for a long time. What is the most likely cause?

medium

A. The service selector labels do not match any pods

B. The Kubernetes cluster is not running

C. The pods are not listening on the targetPort

D. The Azure Load Balancer quota is exceeded in the subscription

Solution

1. Step 1: Understand LoadBalancer IP allocation

   Azure assigns an external IP when provisioning the Load Balancer. If quota is exceeded, IP remains pending.

2. Step 2: Differentiate causes

   Selector mismatch or pod ports cause traffic issues but do not block IP assignment. Cluster down would prevent service creation.

3. Final Answer:

   The Azure Load Balancer quota is exceeded in the subscription -> Option D

4. Quick Check:

   Pending IP often means quota limit reached [OK]

Hint: Pending IP usually means Azure LB quota exceeded [OK]

Common Mistakes:

• Blaming selector mismatch for IP assignment delay
• Assuming pods not listening blocks IP allocation
• Thinking cluster down still allows service creation

5. You want to design a highly available AKS application exposed via Azure Load Balancer that can handle sudden traffic spikes. Which combination of strategies is best?

hard

A. Use type: NodePort service and rely on Azure VM scale sets only

B. Use type: ClusterIP service with manual pod scaling and no health probes

C. Use type: LoadBalancer service, enable Horizontal Pod Autoscaler, and configure Azure Load Balancer health probes

D. Use type: ExternalName service pointing to an external DNS

Solution

1. Step 1: Choose correct service type for external exposure

   type: LoadBalancer creates Azure LB to distribute traffic externally.

2. Step 2: Enable autoscaling and health checks

   Horizontal Pod Autoscaler adjusts pod count for traffic spikes; health probes ensure LB routes only to healthy pods.

3. Step 3: Evaluate other options

   ClusterIP is internal only; NodePort exposes ports but lacks automatic LB; ExternalName is DNS mapping, not load balancing.

4. Final Answer:

   Use type: LoadBalancer service, enable Horizontal Pod Autoscaler, and configure Azure Load Balancer health probes -> Option C

5. Quick Check:

   LoadBalancer + autoscale + health probes = high availability [OK]

Hint: Combine LoadBalancer, autoscaling, and health probes for HA [OK]

Common Mistakes:

• Using ClusterIP or ExternalName for external traffic
• Ignoring autoscaling for traffic spikes
• Not configuring health probes causing downtime