Kubernetes Ingress: The Cluster's Front Door

WHY IT EXISTS: Before Ingress, exposing a service meant creating a Service of type LoadBalancer. This provisions a separate, often expensive, cloud load balancer for every service you want to make public. This becomes costly and complex. Ingress was created to provide a single, consolidated, and intelligent entry point for multiple services.

THE MENTAL MODEL: Ingress is like an apartment building's front desk. Instead of every apartment having its own external door, visitors arrive at one main entrance. They tell the receptionist which apartment they want (e.g., api.myapp.com/users), and the receptionist directs them to the right internal elevator (the corresponding Kubernetes Service). The Ingress resource is the list of instructions for the receptionist; the Ingress controller is the receptionist actually doing the work.

HOW IT WORKS: You define an Ingress resource in YAML, specifying rules for routing traffic based on the requested host (e.g., billing.example.com) or URL path (e.g., /api/v2). A separate application, the Ingress controller, runs in your cluster watching for these resources. When a request hits the controller's external IP, the controller inspects it, finds a matching Ingress rule, and forwards the traffic to the correct backend Service. The Ingress object is just configuration; the controller is the engine.

WHEN TO USE IT: Use Ingress whenever you need to expose one or more HTTP or HTTPS services. It's ideal for host-based virtual hosting (routing service-a.com and service-b.com from the same IP), path-based routing (routing /api and /ui to different services), and centralizing TLS/SSL termination for your applications.

WHEN NOT TO USE IT: Ingress is specifically for HTTP/S traffic (Layer 7). It is not the right tool for exposing non-HTTP protocols like a raw database connection or a game server's UDP stream. For those, you would still use a Service of type LoadBalancer or NodePort. For a very simple cluster with only one service to expose, a LoadBalancer Service can be simpler.

ONE CANONICAL EXAMPLE: A common setup is routing traffic for a single domain to different microservices. An Ingress resource could have a rule that sends all requests for myapp.com/api to the api-backend service, while sending requests for myapp.com/ to the frontend-webapp service. Both services are exposed through the single IP address of the Ingress controller, which also handles the TLS certificate for myapp.com.