Kubernetes Ingress vs LoadBalancer: Which to Choose?
Kubernetes Ingress vs LoadBalancer: Which to Choose?
Detailed comparison of Kubernetes Ingress and LoadBalancer services — when to use each, cost implications, and configuration examples.
Table of Contents
- The Quick Answer
- How Each Works
- Side-by-Side Comparison
- Configuration Examples
- Cost Analysis
- Decision Guide
The Quick Answer
- LoadBalancer: One cloud LB per service — simple but expensive at scale
- Ingress: One LB, many routes — cheaper, smarter routing, TLS in one place
For anything beyond a few services, use Ingress.
How Each Works
LoadBalancer Service
Each type: LoadBalancer service provisions a real cloud load balancer:
Internet → LB1 → service-a
Internet → LB2 → service-b
Internet → LB3 → service-c
On Azure, each LoadBalancer service gets its own public IP + Azure LB rule. On AWS, an NLB/ALB per service (depending on annotations).
Ingress
One ingress controller (nginx, Traefik, Azure AGIC) sits behind one LoadBalancer and routes by hostname/path:
Internet → ONE LB → Ingress Controller → service-a (host: api.example.com)
→ service-b (host: app.example.com)
→ service-c (host: example.com/blog)
Side-by-Side Comparison
| Feature | LoadBalancer | Ingress |
|---|---|---|
| OSI Layer | L4 (TCP/UDP) | L7 (HTTP/HTTPS) |
| Routing | IP:port only | Host + path based |
| TLS termination | Per-service | Centralized |
| Cloud resources | 1 LB per service | 1 LB total |
| URL rewriting | No | Yes |
| Rate limiting/WAF | No (cloud LB dependent) | Yes (controller features) |
| Non-HTTP traffic | Yes | No (mostly) |
| Complexity | Low | Medium |
Configuration Examples
LoadBalancer Service
apiVersion: v1
kind: Service
metadata:
name: my-app-lb
spec:
type: LoadBalancer
selector:
app: my-app
ports:
- port: 80
targetPort: 8080
kubectl get svc my-app-lb
# EXTERNAL-IP shows once Azure provisions the LB
Ingress Setup
Step 1: Install the ingress controller (nginx):
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
On AKS, alternatively enable Application Gateway Ingress Controller (AGIC) or use the managed nginx addon:
az aks enable-addons --addons ingress-appgw \
--resource-group my-rg --name my-cluster \
--appgw-name my-appgw --appgw-subnet-id <subnet-id>
Step 2: Create the Ingress resource:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
ingressClassName: nginx
rules:
- host: example.com
http:
paths:
- path: /api(/|$)(.*)
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /(/|$)(.*)
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80
- host: admin.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: admin-service
port:
number: 8080
Step 3: Add TLS with cert-manager:
spec:
tls:
- hosts:
- example.com
- admin.example.com
secretName: app-tls
Cost Analysis
Approximate costs (varies by region/provider):
| Setup | Monthly Cost |
|---|---|
| 10 LoadBalancer services (Azure) | ~£150+ (10 public IPs + LB rules) |
| 1 Ingress + 10 routes | ~£18–25 (1 public IP + controller pods) |
At 50+ services, LoadBalancer-per-service becomes genuinely expensive and hits cloud provider limits (e.g., LB rules per LB).
When to Use LoadBalancer
- Single service that needs direct exposure (e.g., a game server, MQTT broker)
- Non-HTTP protocols — TCP/UDP that ingress can't route
- Simplest possible setup for a demo or MVP
When to Use Ingress
- Multiple HTTP(S) services — the common case
- Path-based routing (
/api→ api-svc,/→ frontend) - Hostname routing (api.example.com, admin.example.com)
- Centralized TLS via cert-manager + Let's Encrypt
- Rate limiting, auth, rewrites at the edge
Common Pitfalls
Ingress returns 404 for everything
# Check the ingress got an address
kubectl get ingress
# Check controller logs
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx
# Common cause: missing ingressClassName
spec:
ingressClassName: nginx # required in modern Kubernetes
Health probes failing through ingress
The ingress controller health-checks your service's pods. If readiness probes fail, traffic won't route — check Pod Not Ready guide.
SSL redirect loops
# If terminating TLS at a cloud LB in front of ingress:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false" # avoid double-redirect loop
Decision Guide
Need non-HTTP (TCP/UDP)? ──yes──→ LoadBalancer
│
no
▼
More than 2-3 services? ──yes──→ Ingress
│
no
▼
Quick demo/MVP? ──yes──→ LoadBalancer
│
no
▼
→ Ingress (better long-term)
Related Articles
Last Updated: October 2026
Author: CloudOpsGuide Team
Difficulty: Intermediate
Estimated Reading Time: 11 minutes