What is the Difference Between an Ingress Controller and a Load Balancer?
Understand how a Kubernetes Ingress controller differs from a load balancer, including Layer 7 routing, TLS, and how they work together.
Expected Interview Answer
A load balancer distributes network traffic across backend targets at the transport layer (or basic HTTP), while a Kubernetes Ingress controller is an application-aware Layer 7 proxy that reads Ingress rules to route HTTP/HTTPS traffic to different Services based on hostname or URL path, and it typically sits behind a cloud load balancer rather than replacing it.
A cloud load balancer (or a Kubernetes Service of type LoadBalancer) provisions an external IP and spreads incoming connections across a set of backend nodes or Pods, but it generally has no awareness of HTTP paths, hostnames, or application-level routing rules — it just forwards packets or connections. An Ingress controller, such as NGINX Ingress or Traefik, runs as Pods inside the cluster, watches Ingress resources via the Kubernetes API, and configures itself to route example.com/api to one Service and example.com/app to another, all from a single external entry point, while also handling TLS termination, redirects, and rewrite rules. In a typical setup, a single cloud LoadBalancer Service exposes the Ingress controller’s Pods to the internet, and the Ingress controller then does the fine-grained Layer 7 routing internally — so the load balancer solves “how do I reach the cluster” while Ingress solves “which Service inside the cluster handles this specific request.” Without Ingress, exposing many HTTP services would require one expensive external LoadBalancer per Service; Ingress consolidates them behind one.
- Consolidates many HTTP services behind a single external entry point
- Enables host- and path-based routing that plain load balancers cannot do
- Centralizes TLS termination and redirect/rewrite rules
- Reduces cost versus provisioning one cloud LoadBalancer per Service
AI Mentor Explanation
A load balancer is like the main stadium gate that simply spreads arriving fans evenly across the available turnstiles so no single entrance gets overwhelmed, with no idea which stand any fan is actually headed to. An Ingress controller is like the usher standing just past the turnstiles who reads each fan’s ticket and directs them to the exact stand, tier, and seat block based on what is printed on it. The gate solves “how do fans get into the stadium at all,” while the usher solves “which specific section does this fan belong in.” Without the usher, every single stand would need its own separate dedicated entrance gate, which would be wildly impractical for a big match.
Step-by-Step Explanation
Step 1
Traffic hits the load balancer
A cloud LoadBalancer Service exposes a single external IP and distributes connections across the Ingress controller’s Pods.
Step 2
Ingress controller inspects the request
It reads the HTTP Host header and path, matching against configured Ingress resources.
Step 3
Route to the correct Service
The controller forwards the request internally to the Service matching the host/path rule, e.g. api.example.com to the api Service.
Step 4
Terminate TLS and apply rules
The Ingress controller handles TLS termination, redirects, and rewrites centrally before the request reaches application Pods.
What Interviewer Expects
- Clear distinction between Layer 4 (basic load balancer) and Layer 7 (Ingress) routing
- Understanding that Ingress typically sits behind a cloud LoadBalancer, not instead of it
- Knowledge that Ingress enables host/path-based routing and centralized TLS termination
- Awareness of why Ingress reduces the need for one external LoadBalancer per Service
Common Mistakes
- Treating Ingress and LoadBalancer as interchangeable or competing concepts
- Assuming an Ingress controller is unnecessary because a LoadBalancer Service already exists
- Not knowing Ingress requires a separate controller (NGINX, Traefik, etc.) to actually function
- Forgetting that Ingress can do path/host-based routing that a plain load balancer cannot
Best Answer (HR Friendly)
“A load balancer just gets traffic into our cluster and spreads it across servers, without understanding what is being requested. An Ingress controller sits behind that and actually reads the web request — the domain and path — to decide which specific internal service should handle it, and it also manages our TLS certificates centrally, so we only need one external entry point instead of one per service.”
Code Example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
tls:
- hosts: ["api.example.com", "app.example.com"]
secretName: myapp-tls-secret
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80Follow-up Questions
- Why does an Ingress controller usually still sit behind a cloud LoadBalancer Service?
- How does an Ingress controller handle TLS termination for multiple hostnames?
- What is the difference between Ingress and the newer Gateway API?
- How would you debug a request that returns a 404 from the Ingress controller but the Service is healthy?
MCQ Practice
1. What layer does a basic Kubernetes LoadBalancer Service primarily operate at?
A LoadBalancer Service distributes connections at the transport layer without inspecting HTTP hostnames or paths.
2. What can an Ingress controller do that a plain cloud load balancer typically cannot?
Ingress controllers are Layer 7 aware, routing by hostname and path, which basic Layer 4 load balancers cannot do.
3. What component is required for Ingress resources to actually take effect?
Ingress resources are inert without a running Ingress controller that watches and implements them.
Flash Cards
What layer does a plain load balancer operate at? — Layer 4 (transport), generally with no HTTP-level awareness.
What does an Ingress controller add? — Layer 7 routing by hostname/path, plus centralized TLS termination.
How does Ingress relate to a cloud LoadBalancer? — It typically sits behind one, which exposes the Ingress controller Pods externally.
Why use Ingress instead of one LoadBalancer per Service? — It consolidates many HTTP services behind a single external entry point, saving cost and complexity.