Ingress is a Kubernetes API object that defines rules for routing external HTTP and HTTPS traffic to Services inside a cluster, based on the requested host name and URL path. In Kubernetes, an Ingress resource is only a declaration; an Ingress controller, a reverse proxy running in the cluster, reads these rules and actually forwards the requests.
Ingress solves a practical problem of cloud-native platforms: exposing dozens of web applications through one entry point and one external IP address instead of one cloud load balancer per Service. It also centralizes TLS termination, so certificates are managed in one place rather than in every application.
How Ingress routes traffic into the cluster
An Ingress works through a division between declaration and enforcement. The Ingress object, stored by the API server, lists rules such as “requests for shop.example.com with path /api go to Service api on port 8080″. The Ingress controller watches the API for changes and regenerates its proxy configuration whenever an Ingress, Service or endpoint changes.
The controller itself is exposed to the outside world, typically through a Service of type LoadBalancer in a public cloud or NodePort on bare-metal clusters. A client request therefore travels from the external load balancer to the controller pod, which matches host and path, terminates TLS if configured, and proxies the request directly to a pod endpoint of the target Service. Many controllers bypass the Service virtual IP and balance across pod endpoints themselves.
Without a controller, an Ingress object has no effect at all. Kubernetes does not ship a default controller, so every cluster operator installs one, and the ingressClassName field tells each Ingress which controller should handle it when several are present.
Components and fields of an Ingress resource
The stable API version is networking.k8s.io/v1, which became generally available in Kubernetes 1.19. The table lists the parts that define its behavior.
| Field or concept | Role | Notes |
|---|---|---|
| ingressClassName | Selects the controller | Refers to an IngressClass object |
| rules.host | Matches the requested host name | Wildcards such as *.example.com allowed |
| paths.path | Matches the URL path | Combined with a path type |
| pathType | Defines how paths match | Exact, Prefix or ImplementationSpecific |
| backend.service | Target Service name and port | Must be in the same namespace |
| tls | Hosts and certificate Secret | Enables HTTPS termination |
| defaultBackend | Handles unmatched requests | Often a custom 404 page |
Path matching follows defined precedence: the longest matching path wins, and an Exact match beats a Prefix match of the same length. A Prefix value of /api matches /api and /api/orders but not `/apiary`, because matching is done element by element on the path segments.
Behavior beyond the standard fields, such as rewrites, rate limits, timeouts or authentication, is configured through controller-specific annotations. These annotations are not portable between controllers, which is one of the main weaknesses of the Ingress API.
Common Ingress controllers
The choice of controller determines performance, features and operational model. The following table compares widely used implementations.
| Controller | Underlying proxy | Typical use |
|---|---|---|
| NGINX-based controllers | NGINX | General-purpose default in many clusters |
| Traefik | Traefik | Dynamic configuration, smaller clusters |
| HAProxy Ingress | HAProxy | High connection rates, fine-grained tuning |
| Contour | Envoy | Envoy-based routing with its own CRDs |
| Cloud load balancer controllers | Provider load balancers | Managed layer 7 load balancing in public clouds |
Controllers differ in how they apply configuration changes. Some reload a proxy process, which can briefly affect long-lived connections, while Envoy-based controllers update routes dynamically without restarts. For clusters with frequent deployments, this difference matters.
Ingress compared with Service types and the Gateway API
Ingress is one of several ways to expose workloads, and it works only at layer 7 for HTTP and HTTPS. A Service provides a stable address for pods; Ingress adds host-based and path-based routing on top of Services.
| Mechanism | Network layer | Routing capability | Typical cost |
|---|---|---|---|
| ClusterIP Service | Layer 4 | Internal only | No external resource |
| NodePort Service | Layer 4 | Fixed port on every node | No external resource |
| LoadBalancer Service | Layer 4 | One external IP per Service | One cloud load balancer each |
| Ingress | Layer 7 | Host and path rules, TLS | One shared entry point |
| Gateway API | Layer 4 and 7 | Role-oriented, header and weight routing | One or more shared gateways |
The Gateway API is the designated successor model. It splits responsibilities between infrastructure providers, cluster operators and application developers through GatewayClass, Gateway and HTTPRoute objects, and standardizes features such as header matching and weighted traffic splitting that Ingress leaves to annotations. The Ingress API is frozen but still supported, so existing configurations remain valid while new platforms increasingly adopt the Gateway API.
Pitfalls and operational advice
Most Ingress incidents come from mismatched classes, certificates and path rules rather than from the controller software.
- Missing ingressClassName: the Ingress is ignored or claimed by the wrong controller.
- TLS Secret in another namespace: the certificate must live in the same namespace as the Ingress.
- Overlapping rules across teams: two Ingress objects claiming the same host cause unpredictable routing.
- Unexpected rewrites: controller annotations can change the path that the back end receives.
- Single controller replica: the controller becomes a single point of failure for all web traffic.
Production setups run at least two controller replicas, automate certificates with a certificate manager, and enforce host ownership through admission policies. Monitoring controller metrics such as request rate, error rate and latency gives early warning, because every external request passes through this layer.
In everyday language
Imagine a large office building with one main entrance and many companies inside. Visitors do not need to know which floor each company is on. A receptionist at the front desk reads the name on each visitor’s appointment and sends them to the right office.
Ingress plays that role for applications running in Kubernetes. Every request arrives at one shared front door, and a set of written rules says which application should receive it, based on the web address. The rules are the Ingress; the receptionist is the controller.
Seen in the real world
A mid-sized retailer runs its storefront, customer account area and product API as separate Services in one Kubernetes cluster. Initially each Service had its own cloud load balancer, which meant three external IP addresses, three certificates and three monthly load balancer charges.
The platform team installs an NGINX-based controller with three replicas behind a single LoadBalancer Service. One Ingress routes www.shop.example to the storefront, another sends /account to the account Service, and a third routes api.shop.example to the API. A certificate manager issues and renews the TLS certificates stored as Secrets.
The outcome is one entry point with centralized HTTPS, fewer cloud resources and a single place to monitor web traffic. When the team later needs to send 10 percent of traffic to a new storefront version, it evaluates the Gateway API, because weighted routing is standardized there.