The Problem with One LoadBalancer Per Service
A Kubernetes Service of type LoadBalancer provisions a cloud load balancer (an AWS ALB, a GCP Network Load Balancer, etc.) with a dedicated public IP address. This works, but it is expensive and operationally messy. If you have 30 microservices that need external access, you get 30 load balancers, 30 public IPs, and 30 separate TLS certificates to manage.
Ingress solves this by acting as a single, smart entry point for all external HTTP/HTTPS traffic. One load balancer. One public IP. One place to manage TLS. Routing decisions happen at Layer 7 (the application layer) based on the hostname or URL path of each request.
The Two-Part System
Ingress is a two-part system that is often confused:
1. The Ingress Resource is a Kubernetes configuration object where you declare routing rules. It is just data — it does nothing by itself. A set of rules typically maps a hostname and path prefix to a backing Service and port — one rule per hostname/path combination, so a single Ingress resource can route api.myapp.com to one service and myapp.com/blog to a completely different one.
2. The Ingress Controller is a running Pod (typically Nginx, Traefik, or a cloud-native controller like the AWS Load Balancer Controller) that watches for Ingress resources and actually implements the routing rules. Without an Ingress Controller installed in your cluster, Ingress resources do nothing.
TLS Termination
Ingress controllers handle TLS termination — they decrypt HTTPS traffic at the edge and forward plain HTTP to backend Services. A tls section on the Ingress resource references a Kubernetes Secret containing the certificate for a given set of hosts. Tools like cert-manager can automatically provision and renew Let's Encrypt certificates and store them as Secrets, making TLS nearly zero-maintenance.