Ingress is a Kubernetes API object and controller that manages external HTTP and HTTPS access to services inside a cluster, providing host-based and path-based routing.
An Ingress resource defines routing rules for hostnames, paths, TLS certificates, and backend services. An Ingress controller implements those rules by configuring a reverse proxy or load balancer inside or outside the cluster.
That abstraction lets teams expose many services through one public entry point with L7 rules instead of creating a separate LoadBalancer service for each one. It reduces cloud cost and simplifies DNS management. The catch is that Ingress itself is just a specification; the controller implementation varies widely and is often the actual source of routing behavior.
Think of it like this. Think of a mailroom that sorts letters by department and floor. Instead of giving every department its own street address, the whole building has one address and the mailroom routes internally.
Users create Ingress resources with host and path rules pointing to Service backends. The Ingress controller watches those resources and programs a proxy such as NGINX, Envoy, or a cloud load balancer. TLS termination, redirects, authentication, and rate limiting can be applied at the controller layer.
"Kubernetes includes a default controller." Kubernetes defines the API but does not include a controller by default. "Ingress replaces service mesh." Ingress handles L7 routing; mesh handles East-West traffic, security, and observability. "All controllers behave the same." Controller annotations, feature support, and troubleshooting differ significantly.
Consolidates external access and reduces cloud load balancer count, but controller choice and behavior vary. Best for L7 routing; not a complete replacement for API gateways or service mesh when those capabilities are needed.