AKS with Azure Load Balancer - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Understanding AKS Load Balancer Integration

In an AKS cluster, which component is responsible for provisioning the Azure Load Balancer to expose services externally?

A The Azure Resource Manager (ARM) template manually deployed by the user

B The Kubernetes kube-proxy running on each node

C The Azure Load Balancer operator running as a pod inside the cluster

D The Azure cloud controller manager integrated with AKS

💡 Hint

Think about which component communicates between Kubernetes and Azure infrastructure.

The Azure cloud controller manager in AKS manages cloud resources like the Azure Load Balancer by interacting with Azure APIs to provision and configure them automatically.

❓ scaling

intermediate

Scaling AKS Services with Azure Load Balancer

You have an AKS service exposed via an Azure Load Balancer. When you scale the number of pods for this service, what happens to the Load Balancer's backend pool?

A The backend pool automatically updates to include the new pod IPs

B The backend pool updates to include the node IPs where pods run, not pod IPs

C The Load Balancer creates a new backend pool for each pod

D The backend pool remains unchanged until manually updated

💡 Hint

Consider how Azure Load Balancer routes traffic to pods in AKS.

Azure Load Balancer routes traffic to node IPs in the backend pool. kube-proxy on nodes forwards traffic to pods. So, backend pool updates include node IPs, not pod IPs.

❓ tradeoff

advanced

Choosing Between Basic and Standard Azure Load Balancer for AKS

Which of the following is a key advantage of using the Standard Azure Load Balancer over the Basic one in an AKS cluster?

A Standard Load Balancer supports zone redundancy and higher scale

B Standard Load Balancer is free of charge while Basic is paid

C Basic Load Balancer supports more backend pool instances

D Basic Load Balancer supports inbound NAT rules, Standard does not

💡 Hint

Think about availability and scale features in Azure Load Balancer SKUs.

The Standard Load Balancer supports zone redundancy, higher scale, and better security features compared to the Basic SKU, making it suitable for production AKS workloads.

🧠 Conceptual

advanced

Request Flow in AKS with Azure Load Balancer

In an AKS cluster exposed via an Azure Load Balancer, what is the correct sequence of components a client request passes through before reaching a pod?

A 1,2,3,4

B 1,3,2,4

C 1,2,4,3

D 2,1,3,4

💡 Hint

Follow the path from client to pod step-by-step.

The client sends the request to the Load Balancer IP, which forwards it to a node. kube-proxy on the node routes it to the pod, which processes and responds.

❓ estimation

expert

Estimating Azure Load Balancer Capacity for AKS Cluster

You have an AKS cluster with 50 nodes and a service exposed via a Standard Azure Load Balancer. Each node runs 10 pods for this service. If the Load Balancer supports up to 1000 backend pool instances, what is the maximum number of pods that can be effectively load balanced by this service?

A 50 pods, limited by the number of nodes in the cluster

B 500 pods, since each node counts as 2 backend pool instances

C 10000 pods, because Load Balancer backend pool limits the number of nodes, not pods

D 5000 pods, since pods are directly registered in the backend pool

💡 Hint

Consider what the Load Balancer backend pool tracks: nodes or pods?

The Azure Load Balancer backend pool tracks nodes, not individual pods. The 1000 instance limit allows up to 1000 nodes. With 10 pods per node, that's up to 10,000 pods. The current 50 nodes is well below the limit.

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