Kubernetes Ingress: The Cluster's Smart Receptionist

WHY IT EXISTS Exposing services directly with type: LoadBalancer is simple but expensive, as each service often provisions its own cloud load balancer and public IP. Ingress was created to consolidate routing for multiple services through a single entry point, saving costs and simplifying management of external traffic.

THE MENTAL MODEL Think of an Ingress as a smart receptionist or reverse proxy sitting at the edge of your cluster. External users connect to one main entry point (the Ingress controller's IP). The Ingress resource is the receptionist's directory, telling it to route requests for api.myapp.com to the API service, and requests for myapp.com/blog to the blog service.

HOW IT WORKS An Ingress setup has two components. First, the Ingress Controller, which is a pod (or set of pods) running a proxy like NGINX or Traefik that listens for traffic. Second, the Ingress resource, a Kubernetes object where you define routing rules. For example, a rule might state "traffic for host foo.com should go to service foo-svc on port 80". The controller watches for these resources and automatically configures the proxy to match the rules. The Ingress resource itself does nothing without a controller to act on it.

WHEN TO USE IT Use Ingress whenever you need to expose one or more HTTP or HTTPS services from your cluster. It's ideal for host-based routing (directing api.example.com and ui.example.com to different services) and path-based routing (directing example.com/api and example.com/web to different services). It is also the standard way to handle TLS termination for your services.

WHEN NOT TO USE IT Ingress is not designed for non-HTTP/S protocols like raw TCP or UDP traffic from a database. For those, use a Service of type NodePort or LoadBalancer. For extremely simple setups with only one service to expose, a LoadBalancer service might be easier. For very complex L7 routing, the newer Gateway API or a service mesh may be a better fit.

ONE CANONICAL EXAMPLE A common use case is hosting multiple websites in one cluster. An Ingress resource can define rules so that traffic to customer-a.com is routed to the customer-a-service, and traffic to customer-b.com is routed to the customer-b-service, all through the same public IP address and load balancer managed by the Ingress controller.