Phase 4: Traffic from the Outside World

Time: week 4. Goal: replace your -p 8080:80 thinking.

Why not LoadBalancer-per-service

Every type: LoadBalancer Service provisions its own cloud load balancer - its own IP, its own cost. Ten services means ten load balancers. That doesn't scale.

Ingress

One entry point for all HTTP traffic, with routing rules:

• Host-based: api.example.com to one service, app.example.com to another.
• Path-based: /api to backend, / to frontend.

An Ingress resource is just rules. An ingress controller (a pod actually running a reverse proxy) reads those rules and does the routing. Nothing happens without a controller installed.

Install ingress-nginx on your local cluster:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

(For kind, create the cluster with port mappings - see the kind ingress docs.)

TLS

• TLS terminates at the Ingress: a Secret holds the cert, the Ingress references it.
• cert-manager automates Let's Encrypt: you annotate the Ingress, it provisions and renews certs. Do one guided setup so you've seen it work.

Gateway API (awareness)

The newer, more expressive replacement gradually superseding Ingress. Recognize the resource names (Gateway, HTTPRoute) so you're not lost when you see them, but learn Ingress first - it's everywhere.

Exercise

Full playbook with the controller install and Ingress solution: Lab 4.

Two services behind one ingress:

1. Deploy a backend and a frontend (any two images, even two differently-configured nginxes).
2. Write one Ingress: app.localtest.me/api routes to the backend, / to the frontend. (*.localtest.me resolves to 127.0.0.1, no /etc/hosts editing needed.)
3. Verify both routes from your browser.

Checkpoint

• You can explain the difference between an Ingress resource and an ingress controller.
• You can write a host- and path-based routing rule from memory.
• You know where TLS terminates and what cert-manager automates.

Next: Phase 5: Operating It