Kubernetes Ingress

An Ingress is a Kubernetes API object that holds routing rules. A typical rule says something like: send requests for host shop.example.com with path /api to the orders Service on port 8080, and everything else to the web Service. It is plain configuration, not a running program.

Ingress exists because exposing every Service with its own external LoadBalancer is expensive and wasteful. On AWS or GCP, each LoadBalancer Service provisions a separate cloud load balancer that costs money and burns through public IPs. Ingress lets you put one entry point in front of dozens of Services and route between them at layer 7, the HTTP layer.

The Ingress object alone does nothing. You need an Ingress controller, a pod running inside the cluster that watches the Kubernetes API for Ingress objects and translates them into a real reverse proxy configuration. Without a controller, your Ingress rules are just rows in etcd that no traffic ever reads.

The controller runs as a deployment in the cluster, usually exposed by a single LoadBalancer or NodePort Service so it has one public IP. ingress-nginx, the most common controller, runs an NGINX process. When you create or change an Ingress object, the controller's control loop notices the change through a watch on the Kubernetes API and regenerates the NGINX config, then reloads it.

When a request arrives, the controller terminates TLS if a certificate is configured, reads the Host header and the request path, and matches them against the compiled rules. It then forwards the request to the backend Service. In practice most controllers skip the Service's cluster IP and proxy straight to the pod IPs they learn from the Service's Endpoints, which gives them better load balancing and faster failover when a pod dies.

TLS is handled by referencing a Kubernetes Secret that holds the certificate and key. Pairing the controller with cert-manager automates issuing and renewing free Let's Encrypt certificates, so HTTPS for a new hostname becomes a few lines of YAML instead of a manual certificate dance.

IngressClass tells the cluster which controller owns a given Ingress, so you can run more than one controller, for example a public-facing ingress-nginx and a separate internal one, without them fighting over the same rules.

Reach for Ingress when you are serving HTTP or HTTPS and want host and path routing, shared TLS, and one front door for many Services. It is the standard answer for web apps and REST APIs running on Kubernetes.

It is layer 7 only. If you need to expose raw TCP or UDP, such as a Postgres port or a game server, Ingress does not help and you want a LoadBalancer Service or the controller's TCP passthrough feature instead. Ingress also has a thin core spec, so anything beyond basic routing, like rate limiting, rewrites, sticky sessions, or auth, gets bolted on through controller-specific annotations. Those annotations are not portable, so an Ingress tuned for ingress-nginx will not behave the same on Traefik or HAProxy.

Because of those limits, newer clusters increasingly use the Gateway API, a more expressive successor designed to replace Ingress for advanced traffic management. For straightforward routing, Ingress is still simpler and remains very widely deployed.

Say you run a storefront with three Services: web, api, and admin. You create one Ingress that routes shop.example.com to the web Service, shop.example.com/api to the api Service, and admin.example.com to the admin Service, with a TLS Secret covering both hostnames.

You install ingress-nginx, which provisions a single cloud load balancer with one public IP. You point all your DNS records at that IP. Now a request to shop.example.com/api/orders lands on the load balancer, hits NGINX, gets matched to the api Service, and is proxied to a healthy api pod. Three Services, one IP, one certificate, one load balancer bill.

Add a fourth Service later and you just append a rule to the same Ingress. No new load balancer, no new IP, no new DNS work beyond a CNAME if the hostname is new.