Let's think about it this way for a second
On a cluster running 10 apps, if you create 10 LoadBalancer-type Services, you'd end up provisioning 10 separate cloud load balancers (and 10x the cost) — not exactly ideal. Ingress creates just one load balancer, and routes traffic to the correct Service based on domain (`api.example.com`, `app.example.com`) or path (`/api`, `/app`) — think of it like a 'hotel front desk,' pointing each guest to the right room. For Ingress to actually work, you need an Ingress Controller (like nginx-ingress or Traefik) installed on the cluster.
Let's connect this to a real scenario
You can set up Ingress rules like `api.example.com` → `api-service`, `app.example.com` → `frontend-service` — and you can even centralize your TLS/HTTPS certificate at the Ingress level too (no need to manage a cert per Service). On local minikube, you enable the Ingress Controller with `minikube addons enable ingress`.
Let's look at it together
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-service
port:
number: 8080$ kubectl get ingress app-ingress
NAME CLASS HOSTS ADDRESS PORTS
app-ingress nginx app.example.com,api.example.com 192.168.1.5 805-Minute Try-It
Run `minikube addons enable ingress`, then apply the Ingress rule above (swapping the host for a local testing domain).
A Quick Word of Caution
Annotation syntax differs across Ingress classes (nginx, traefik, etc.) — be sure to read the documentation for whichever Ingress Controller you're using.