Ingress: routing HTTP traffic into the cluster

Docker & Containers' Services lesson covered type: LoadBalancer as the way to expose a Service publicly — each one provisions a real cloud load balancer. That's fine for one application, but a cluster running ten applications, each with its own LoadBalancer Service, means ten separate cloud load balancers, each billed separately, each needing its own DNS entry, with no shared place to configure HTTPS or routing rules across all of them.

An Ingress object describes routing rules — which hostname or URL path should go to which Service — letting a single load balancer (backed by an Ingress controller, covered next) handle traffic for many applications at once:

One Ingress object, one load balancer, routing to as many internal Services as needed based on hostname or path — each backend Service itself typically stays ClusterIP (internal-only), since the Ingress is now the only thing that needs a public-facing address.

An Ingress resource by itself does nothing; it's a declaration of desired routing rules, and (echoing lesson 1's theme) something has to actually watch for Ingress objects and act on them. An Ingress controller (NGINX Ingress Controller, or a cloud provider's own implementation) is a separate piece of software that reads Ingress objects and configures the actual load balancer or reverse proxy accordingly. This is a genuinely common point of confusion for newcomers: creating an Ingress object with no Ingress controller installed in the cluster does nothing at all, since nothing exists to interpret and act on the rules.

Ingress also centralizes HTTPS certificate handling, terminating TLS at the Ingress rather than requiring every individual Service to handle its own certificates:

The referenced Secret (lesson 3) holds the actual TLS certificate and private key — another concrete example of Secrets being used for genuinely sensitive data, consumed by the Ingress controller rather than by an application Pod directly.

Host-based routing (different subdomains to different Services, as in the example above) and path-based routing (/api/* to one Service, /* to another, on the same hostname) solve related but distinct problems — host-based routing fits genuinely separate applications, while path-based routing fits splitting one logical application's traffic across multiple backend services (an API gateway-like pattern, connecting to the API Design domain's coverage of that same idea at the HTTP-API level).