What is Kubernetes Ingress and How Does It Route Traffic?
Learn how Kubernetes Ingress routes HTTP traffic by host and path, how Ingress Controllers work, and TLS termination — for DevOps interviews.
Expected Interview Answer
Kubernetes Ingress is an API object that defines HTTP and HTTPS routing rules — host names, paths, and TLS certificates — mapping external requests to internal Services, while an Ingress Controller (like NGINX or Traefik) actually implements those rules as a running reverse proxy.
Without Ingress, exposing many HTTP services publicly would require a separate LoadBalancer Service per app, each with its own cloud load balancer and cost. Ingress instead lets a single external entry point fan out to many backend Services based on the request’s hostname (e.g. api.example.com vs app.example.com) or URL path (e.g. /api vs /web), consolidating routing, TLS termination, and sometimes authentication into one layer. The Ingress resource itself is purely declarative — it contains no logic — and does nothing unless an Ingress Controller is deployed in the cluster to watch Ingress objects and program its underlying proxy (NGINX config, Envoy routes, etc.) accordingly. TLS is handled by referencing a Secret containing the certificate and key, and tools like cert-manager can automate certificate issuance and renewal by watching Ingress annotations. Because Ingress operates at Layer 7 (HTTP), it can do things a Layer 4 LoadBalancer Service cannot, like path-based routing, header-based rules, and request rewriting.
- Consolidates many HTTP routes behind one external entry point
- Enables host- and path-based routing to different backend Services
- Centralizes TLS termination and certificate management
- Reduces cost versus provisioning one cloud LoadBalancer per Service
AI Mentor Explanation
Ingress is like a stadium’s single main gate with a signage system that directs different ticket holders — general admission, members, media — down different corridors to their correct seating blocks, all through one entrance. The gate signage itself (the Ingress rules) is just a plan; it takes actual staff at the gate (the Ingress Controller) physically directing the crowd for the plan to work. Without staff on duty, the signage means nothing and nobody gets routed anywhere. This single, well-staffed entry point is far more efficient than building a separate gate for every seating block.
Step-by-Step Explanation
Step 1
Deploy an Ingress Controller
Install NGINX, Traefik, or another controller into the cluster — Ingress rules do nothing without one running.
Step 2
Define Ingress rules
Create an Ingress resource mapping hosts/paths to backend Service names and ports.
Step 3
Attach TLS
Reference a TLS Secret in the Ingress spec, optionally automated via cert-manager, to terminate HTTPS at the edge.
Step 4
Controller programs the proxy
The controller watches the Ingress API and reconfigures its underlying reverse proxy to match the declared rules.
What Interviewer Expects
- Clear distinction between the Ingress resource (declarative rules) and Ingress Controller (the running proxy)
- Understanding of host-based and path-based routing
- Knowledge of TLS termination at the Ingress layer
- Awareness that Ingress operates at Layer 7 (HTTP), unlike a Layer 4 Service
Common Mistakes
- Assuming Ingress works with no controller installed
- Confusing Ingress with a LoadBalancer Service
- Forgetting Ingress is HTTP/HTTPS-only, not for arbitrary TCP/UDP traffic
- Not mentioning TLS termination as a core Ingress responsibility
Best Answer (HR Friendly)
“Ingress lets us expose many web apps to the internet through a single entry point instead of paying for a separate load balancer per app. We write routing rules based on the domain or URL path, and an Ingress Controller running in the cluster actually enforces those rules, including handling HTTPS certificates, so traffic reaches the right service cleanly and securely.”
Code Example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
tls:
- hosts: ["app.example.com"]
secretName: myapp-tls
rules:
- host: app.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80Follow-up Questions
- What is the difference between Ingress and a Service of type LoadBalancer?
- How does cert-manager automate TLS certificate renewal for Ingress?
- What happens if two Ingress resources define conflicting rules for the same host?
- When would you reach for the Gateway API instead of Ingress?
MCQ Practice
1. What actually implements the routing rules declared in an Ingress resource?
The Ingress resource is purely declarative; an Ingress Controller watches it and programs the actual proxy behavior.
2. At which network layer does Ingress operate?
Ingress understands HTTP semantics like host and path, making it a Layer 7 routing mechanism, unlike a Layer 4 Service.
3. How does Ingress typically handle TLS termination?
Ingress specs reference a TLS Secret, letting the controller terminate HTTPS at the edge before forwarding plain HTTP internally.
Flash Cards
What does the Ingress resource contain? — Declarative HTTP routing rules — hosts, paths, and TLS references — with no logic of its own.
What makes Ingress rules actually work? — An Ingress Controller (e.g. NGINX, Traefik) running in the cluster.
What layer does Ingress operate at? — Layer 7 (HTTP/HTTPS), enabling host- and path-based routing.
How does Ingress reduce cost vs many LoadBalancer Services? — It consolidates many routes behind one external entry point and load balancer.