Kubernetes Networking
20 min
Day 58: Ingress and ingress controllers
Ingress: one entry point, many services
A LoadBalancer Service per app gets expensive and unwieldy fast (one cloud load balancer each). Ingress defines HTTP(S) routing rules — path- and host-based — that route external traffic to the right internal Service, all through a single entry point. This is exactly the L7 reverse-proxy pattern from Phase 2, Day 23, applied inside the cluster.
Path-based routing
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service: { name: api, port: { number: 80 } }
- path: /
pathType: Prefix
backend:
service: { name: frontend, port: { number: 80 } }The Ingress *object* is just a routing rule declaration — it does nothing by itself. An Ingress controller (NGINX Ingress, Traefik, etc.) is the actual running proxy that watches Ingress objects and configures itself accordingly. Without a controller installed, Ingress objects are inert.
Key terms
- Ingress
- Declarative HTTP(S) routing rules for external traffic into cluster Services.
- Ingress controller
- The actual running proxy (NGINX, Traefik...) that implements Ingress rules.
You create an Ingress object but traffic still isn't being routed. What's the most likely missing piece?
