AKS with Azure Load Balancer - Step-by-Step Execution

Process Flow - AKS with Azure Load Balancer

Create AKS Cluster

↓

Deploy Application Pods

↓

Create Service of type LoadBalancer

↓

Azure Load Balancer Provisioned

↓

External IP Assigned

↓

Traffic Routed to Pods

This flow shows how creating an AKS cluster and deploying a LoadBalancer service leads to Azure provisioning a load balancer with an external IP that routes traffic to application pods.

Execution Sample

Azure

az aks create --resource-group myRG --name myAKS --node-count 2 --enable-managed-identity
kubectl apply -f app-deployment.yaml
kubectl expose deployment app --type=LoadBalancer --name=app-service

Creates AKS cluster, deploys app pods, and exposes them via Azure Load Balancer.

Process Table

Step	Action	Resource Created/Updated	State Change	Result
1	Create AKS cluster	AKS cluster 'myAKS'	Cluster provisioning started	Cluster nodes initializing
2	Cluster ready	AKS cluster 'myAKS'	Cluster ready	Nodes ready for workloads
3	Deploy app pods	Pods from app-deployment.yaml	Pods created and running	App containers running
4	Expose deployment with LoadBalancer	Service 'app-service'	Service created with type LoadBalancer	Pending external IP
5	Azure provisions Load Balancer	Azure Load Balancer resource	Load Balancer created	External IP assigned
6	External IP assigned to service	Service 'app-service'	External IP available	Traffic can reach pods
7	Traffic routed	Load Balancer -> Pods	Load Balancer routes incoming traffic	App accessible externally
8	End	-	-	AKS with Azure Load Balancer setup complete

💡 External IP assigned and traffic routing established, setup complete

Status Tracker

Resource	Initial State	After Step 2	After Step 4	After Step 6	Final State
AKS Cluster	Not created	Ready	Ready	Ready	Ready
Pods	None	None	Running	Running	Running
Service 'app-service'	None	None	Created (Pending IP)	Created (IP assigned)	Created (IP assigned)
Azure Load Balancer	None	None	Provisioning	Provisioned	Provisioned
External IP	None	None	None	Assigned	Assigned

Key Moments - 3 Insights

Why does the service show 'pending external IP' initially after creation?

Because Azure Load Balancer provisioning takes time after the service is created, as shown in execution_table step 4 and 5.

How does traffic reach the pods from outside the cluster?

The Azure Load Balancer gets an external IP and routes incoming traffic to the pods, as shown in steps 5, 6, and 7.

What happens if the LoadBalancer service is deleted?

The Azure Load Balancer and external IP are released, stopping external traffic routing, reversing steps 5 and 6.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the external IP assigned to the service?

A Step 4

B Step 5

C Step 6

D Step 7

💡 Hint

Check the 'State Change' and 'Result' columns for when 'External IP available' appears.

According to variable_tracker, what is the state of the pods after step 4?

A None

B Running

C Pending

D Terminated

💡 Hint

Look at the 'Pods' row under 'After Step 4' column.

If the AKS cluster was not ready at step 2, what would happen to the pods deployment in step 3?

A Pods would deploy successfully

B Pods deployment would fail

C Pods would deploy but not run

D Pods would run but not be reachable

💡 Hint

Refer to execution_table step 2 and 3 about cluster readiness and pod creation.

Concept Snapshot

AKS with Azure Load Balancer:
- Create AKS cluster to run containers
- Deploy pods with your app
- Expose pods via Service type LoadBalancer
- Azure provisions external Load Balancer
- External IP assigned for public access
- Load Balancer routes traffic to pods

Full Transcript

This visual execution shows how to set up an Azure Kubernetes Service (AKS) cluster with an Azure Load Balancer. First, the AKS cluster is created and nodes become ready. Then application pods are deployed. Next, a Kubernetes Service of type LoadBalancer is created, which triggers Azure to provision a Load Balancer resource. After provisioning, an external IP is assigned to the service. Finally, the Load Balancer routes incoming traffic to the pods, making the application accessible from outside the cluster.

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