Kubernetes Ingress

Kubernetes Ingress is an API object that manages external HTTP and HTTPS access to services running inside a cluster, providing a single entry point that can route incoming requests to different backend services based on the request’s hostname or URL path, rather than exposing every service directly to the outside world.

Why It’s Needed

By default, services inside a Kubernetes cluster are only reachable from within the cluster’s internal network. Exposing a service externally without Ingress typically means using a LoadBalancer-type service, which provisions a separate cloud load balancer per service — workable for a handful of services, but expensive and unwieldy at scale, since a cluster with dozens of services would need dozens of separate external load balancers, each with its own IP address and cost.

How It Works

An Ingress resource defines routing rules — “requests to api.example.com/users go to the users-service, requests to api.example.com/orders go to the orders-service” — and an Ingress controller (a separate component that must be installed in the cluster, such as NGINX Ingress Controller, Traefik, or a cloud provider’s native controller) watches these rules and configures a single load balancer or reverse proxy to implement them. This means one external IP address and one load balancer can front an arbitrary number of internal services, with routing handled at Layer 7 based on the actual HTTP request content.

Ingress vs. Service Mesh

Ingress specifically manages traffic entering the cluster from outside; it doesn’t address how services communicate with each other once traffic is inside the cluster, which is the concern a service mesh handles. The two are complementary and commonly deployed together: Ingress at the cluster’s edge, and a service mesh managing the internal service-to-service traffic behind it.

Ingress Controllers Aren’t Interchangeable

While the Ingress resource specification is standardized across Kubernetes, different Ingress controllers (NGINX Ingress Controller, Traefik, cloud-provider-native controllers, and others) support different sets of advanced features through controller-specific annotations, meaning an Ingress configuration written for one controller doesn’t always work identically if the underlying controller is swapped out. This lack of full feature portability is a common source of friction when migrating between Kubernetes environments or cloud providers, and it’s part of why some organizations have moved toward the newer Gateway API, a successor specification designed specifically to standardize more of this advanced routing behavior across different implementations rather than relying on vendor-specific annotations.