AKS with Azure Load Balancer - Deep Dive

Overview - AKS with Azure Load Balancer

What is it?

AKS stands for Azure Kubernetes Service, a way to run and manage groups of containers easily. Azure Load Balancer is a service that spreads incoming network traffic across multiple resources to keep things fast and reliable. When combined, AKS uses Azure Load Balancer to share user requests evenly among containerized applications. This helps apps stay available and handle many users without slowing down.

Why it matters

Without a load balancer, user requests might all hit one container, causing slowdowns or crashes. AKS with Azure Load Balancer ensures traffic is shared fairly, so apps stay responsive and reliable even during busy times. This means better user experience and less downtime, which is critical for businesses and services online.

Where it fits

Before learning this, you should understand basic cloud concepts and what containers and Kubernetes are. After this, you can explore advanced Kubernetes networking, scaling strategies, and security setups for production environments.

Mental Model

Core Idea

Azure Load Balancer acts like a traffic officer, directing user requests evenly to healthy containers running in AKS to keep applications fast and reliable.

Think of it like...

Imagine a busy restaurant with many waiters (containers). The Azure Load Balancer is like the host who directs arriving guests to the waiter with the fewest tables, so no waiter gets overwhelmed and everyone is served quickly.

┌─────────────────────┐
│   User Requests      │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Azure Load Balancer  │
│  (Traffic Director)  │
└───────┬─────┬───────┘
        │     │
  ┌─────▼─┐ ┌─▼────┐
  │Pod 1  │ │Pod 2 │
  └───────┘ └───────┘

Pods are containers running app instances inside AKS.

Build-Up - 7 Steps

1

Foundation

Understanding AKS Basics

Concept: Learn what AKS is and how it runs containers in the cloud.

AKS is a managed service by Azure that runs Kubernetes clusters. Kubernetes helps organize and run containers, which are small packages of software. AKS handles the setup and maintenance of the cluster, so you can focus on your apps.

Result

You know that AKS runs containers in groups called clusters and manages their health and scaling.

Understanding AKS basics is key because it sets the stage for how your apps run and scale in the cloud.

2

Foundation

What is Azure Load Balancer?

Concept: Learn how Azure Load Balancer distributes network traffic to keep apps responsive.

Azure Load Balancer is a service that takes incoming network requests and spreads them across multiple servers or containers. It checks which ones are healthy and sends traffic only to those. This prevents any single resource from getting overwhelmed.

Result

You understand that Azure Load Balancer helps keep apps fast and available by sharing traffic.

Knowing how load balancing works helps you see why it’s essential for handling many users smoothly.

3

Intermediate

How AKS Uses Azure Load Balancer

🤔Before reading on: do you think Azure Load Balancer sends traffic to all containers equally or only to some? Commit to your answer.

Concept: AKS integrates Azure Load Balancer to route traffic only to healthy containers running your app.

When you create a Kubernetes Service of type LoadBalancer in AKS, Azure automatically provisions an Azure Load Balancer. This load balancer listens for incoming traffic and forwards it to the pods (containers) that are ready and healthy. It uses health probes to check pod status.

Result

Traffic is automatically balanced only among healthy pods, improving reliability.

Understanding this integration clarifies how AKS keeps apps available without manual traffic management.

4

Intermediate

Types of Azure Load Balancers in AKS

🤔Before reading on: do you think AKS uses only one kind of load balancer or multiple? Commit to your answer.

Concept: AKS can use two types of Azure Load Balancers: Basic and Standard, each with different features and limits.

Basic Load Balancer is simpler and free but has limits on scale and features. Standard Load Balancer supports more features like zone redundancy and better security. AKS clusters created today use Standard by default for production readiness.

Result

You can choose the right load balancer type based on your app’s needs and scale.

Knowing the differences helps you plan for cost, performance, and availability in your deployments.

5

Advanced

Configuring Health Probes and Rules

🤔Before reading on: do you think health probes check the whole container or just the app inside? Commit to your answer.

Concept: Health probes are how Azure Load Balancer checks if a pod is ready to receive traffic.

Azure Load Balancer uses health probes that send requests to a specific port and path on your pods. If a pod responds correctly, it is marked healthy and receives traffic. You configure these probes in your Kubernetes Service manifest to match your app’s readiness checks.

Result

Only healthy pods get traffic, preventing errors and downtime.

Understanding health probes prevents common issues where traffic is sent to pods that are not ready.

6

Advanced

Handling External and Internal Traffic

🤔Before reading on: do you think Azure Load Balancer can handle traffic only from outside Azure or also inside? Commit to your answer.

Concept: Azure Load Balancer can be configured to handle traffic from outside the cluster (external) or only inside a virtual network (internal).

By setting the Kubernetes Service type and annotations, you can create an external load balancer that exposes your app to the internet or an internal load balancer that only routes traffic within your Azure network. This is useful for security and architecture design.

Result

You can control who can access your app and how traffic flows.

Knowing this helps you design secure and efficient network architectures for your apps.

7

Expert

Advanced Load Balancer Behavior and Limitations

🤔Before reading on: do you think Azure Load Balancer can detect pod crashes instantly? Commit to your answer.

Concept: Azure Load Balancer relies on health probes and has limits on how quickly it detects pod failures and scales traffic.

Health probes run at intervals (default 5 seconds), so detection of pod failure is not instant. Also, Azure Load Balancer has limits on the number of backend pool members and rules. Understanding these helps in tuning your app’s readiness and liveness probes and planning cluster size.

Result

You can optimize app availability and avoid hitting Azure Load Balancer limits.

Knowing these internals prevents surprises in production and helps design resilient systems.

Under the Hood

Azure Load Balancer works at the network layer, listening on a public or private IP and forwarding TCP/UDP traffic to backend pods. It uses health probes to check pod readiness by sending periodic requests to configured ports and paths. The load balancer maintains a backend pool of pod IPs and distributes traffic using a hash-based algorithm to balance load evenly. Kubernetes Service of type LoadBalancer triggers Azure to create and manage this load balancer automatically, linking it to the cluster nodes and pods.

Why designed this way?

Azure Load Balancer was designed to provide simple, fast, and scalable traffic distribution at the network level. It avoids complex application-level logic to keep latency low and reliability high. Kubernetes integration automates provisioning to reduce manual setup and errors. Alternatives like application gateways add complexity and cost, so Azure Load Balancer fits well for basic, high-performance load balancing needs.

┌─────────────────────────────┐
│      User or Client          │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│    Azure Load Balancer       │
│  (Network Layer Traffic)     │
│  Health Probes Check Pods    │
└───────┬───────────┬─────────┘
        │           │
  ┌─────▼─┐     ┌───▼────┐
  │ Node1 │     │ Node2  │
  │ Pods  │     │ Pods   │
  └───────┘     └────────┘

Pods run containers; nodes are virtual machines in AKS.

Myth Busters - 4 Common Misconceptions

Quick: Does Azure Load Balancer send traffic to unhealthy pods? Commit yes or no.

Common Belief: Azure Load Balancer sends traffic to all pods regardless of health.

Reality: Azure Load Balancer only sends traffic to pods that pass health probes and are marked healthy.

Why it matters: Sending traffic to unhealthy pods causes errors and downtime, so health probes prevent this.

Quick: Is Azure Load Balancer the same as Azure Application Gateway? Commit yes or no.

Common Belief: Azure Load Balancer and Application Gateway are the same service.

Reality: They are different; Load Balancer works at network level, Application Gateway works at application level with features like SSL termination and web firewall.

Why it matters: Choosing the wrong service can lead to missing needed features or paying for unnecessary complexity.

Quick: Does Azure Load Balancer instantly detect pod crashes? Commit yes or no.

Common Belief: Azure Load Balancer detects pod failures instantly and reroutes traffic immediately.

Reality: Detection depends on health probe intervals, so there is a delay before traffic stops going to a failed pod.

Why it matters: Assuming instant detection can cause unexpected downtime or errors during failure.

Quick: Can you use Basic Load Balancer for large production AKS clusters? Commit yes or no.

Common Belief: Basic Load Balancer is fine for all AKS production workloads.

Reality: Basic Load Balancer has scale and feature limits; Standard Load Balancer is recommended for production.

Why it matters: Using Basic in production can cause performance bottlenecks and lack of features like zone redundancy.

Expert Zone

1

Azure Load Balancer’s hash-based distribution can cause uneven load if pod IPs or ports are not well balanced.

2

Health probes must align with Kubernetes readiness probes to avoid sending traffic to pods still starting up.

3

Standard Load Balancer supports zone redundancy, improving availability across Azure regions, which Basic does not.

When NOT to use

Avoid Azure Load Balancer when you need advanced application-level routing, SSL offloading, or web application firewall features; use Azure Application Gateway or Azure Front Door instead.

Production Patterns

In production, teams use Standard Load Balancer with carefully configured health probes and readiness checks. They combine internal load balancers for microservices communication and external load balancers for public access. Autoscaling and monitoring are integrated to handle traffic spikes smoothly.

Connections

Kubernetes Service Types

Builds-on

Understanding AKS with Azure Load Balancer deepens knowledge of Kubernetes Service types like ClusterIP, NodePort, and LoadBalancer, showing how cloud providers implement these.

Network Traffic Routing

Same pattern

Azure Load Balancer’s traffic distribution is a practical example of network routing principles used in many systems, helping grasp broader networking concepts.

Restaurant Host Seating Guests

Opposite domain analogy

Seeing load balancing as a host seating guests helps understand fairness and efficiency in resource allocation, a concept useful in management and logistics.

Common Pitfalls

#1 Traffic sent to pods before they are ready causes errors.

Wrong approach:

apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
selector:
app: myapp
# No readiness probe defined in pod spec

Correct approach:

apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
selector:
app: myapp
---
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp
image: myappimage
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

Root cause:

Not defining readiness probes means Azure Load Balancer cannot know when pods are ready, so it sends traffic too early.

#2 Using Basic Load Balancer for large, critical workloads.

Wrong approach:

az aks create --name myAKS --resource-group myRG --load-balancer-sku Basic

Correct approach:

az aks create --name myAKS --resource-group myRG --load-balancer-sku Standard

Root cause:

Choosing Basic SKU by default ignores scale and feature needs of production environments.

#3 Assuming Azure Load Balancer handles SSL termination.

Wrong approach:

Relying on Azure Load Balancer to decrypt HTTPS traffic before forwarding to pods.

Correct approach:

Use Azure Application Gateway or Ingress Controller for SSL termination; Azure Load Balancer only forwards raw TCP/UDP traffic.

Root cause:

Confusing network-level load balancing with application-level features.

Key Takeaways

AKS uses Azure Load Balancer to distribute incoming traffic evenly across healthy containers, keeping apps responsive.

Health probes are essential to ensure traffic only reaches ready and healthy pods, preventing errors.

Standard Load Balancer is recommended for production due to better features and scalability compared to Basic.

Azure Load Balancer works at the network layer and does not provide application-level features like SSL termination.

Understanding how AKS and Azure Load Balancer work together helps design reliable, scalable cloud applications.