DevOps Practitioner · Module 2: Kubernetes networking and storage
Ingress and the Request Path
Ingress is the front door with a routing table. The object declares hosts, paths and backends; a controller you install reads it and moves the traffic. No controller, no routing, regardless of what the manifest says.
10 min reading
Objectives
- Trace a request from outside the cluster to the pod through Ingress
- Explain what the Ingress object declares versus what the controller does
- Route two hosts or paths to different Services from one manifest
- Name what Ingress does not do: TLS termination source, WAF, global load balancing
Why this matters
A manifest declares an Ingress with two hosts, applied cleanly, and both hosts time out. The object exists, the routes are spelled right, and nothing moves, because no Ingress controller runs in the cluster. An Ingress object without a controller is a wish list: the API accepts it, nothing reconciles it. The first question for every Ingress incident is not the routes but the controller: is it installed, is it watching this class, does its own Service expose it to the outside.
Concepts
The split is load-bearing. The Ingress object holds rules (host, path, backend Service) and optionally TLS settings referencing a Secret. The controller (ingress-nginx, Traefik, Gateway API implementations and kin) watches those objects and configures its proxy; the controller's own Service, usually NodePort or LoadBalancer, is the actual entry point. Local clusters fake the outside: port-forward or a NodePort stands in for the cloud load balancer, and the lesson says so instead of pretending a laptop is a region.
Path routing fits one host serving many Services (/app to one, /api to another) with attention to rewrite: backends usually expect stripped prefixes, and the rewrite annotation or middleware is part of the route, not decoration. Host routing fits many tenants on one entry point. TLS ends at the controller with a referenced certificate; the backend hop may stay plain HTTP inside the cluster, a deliberate and documented choice rather than an oversight.
Know the ceiling. Ingress routes HTTP and HTTPS; raw TCP and UDP need other machinery. It is not a WAF, not a global balancer, not DDoS protection. Teams that outgrow one controller graduate to the Gateway API, which separates the cluster role (provider) from the route role (developer) more cleanly; the request-path mental model transfers intact.
Worked example
A demo cluster runs an Ingress controller and two Services behind one host with path rules. The learner curls both paths through the controller entry point, then breaks one backend Service selector and watches that path fail while the other serves. The controller logs show the failed backend with no healthy endpoints; the fix is the selector, exactly as lesson 1 taught, one layer further out.
Common wrong move
Applying Ingress manifests before installing any controller, then debugging routes that nothing reads. Declare the controller first, prove its entry point answers, then add routes. Order is the whole trick.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
On a local cluster with an installed Ingress controller, route one host with two paths to two Services, prove both paths, then break one backend selector and quote the controller evidence.
Pass criteria
The record shows both paths serving, the broken-path symptom, the controller log naming the backend with no endpoints, and the selector fix.