What Is a Kubernetes Ingress (and Why Is My App Unreachable)?

Quick answer
An Ingress is a routing rule that maps a hostname and path to a Service inside the cluster.
An Ingress does nothing on its own — you need an ingress controller running in the cluster to enforce it.
It is the standard place to terminate TLS, so HTTPS is configured here rather than in your app.
A Service, not an Ingress, is what selects the pods; the Ingress only decides which Service gets the request.
Most unreachable-app problems are a missing controller, a hostname mismatch, or a Service with no endpoints.

What is an Ingress?

An Ingress is a Kubernetes object that declares HTTP routing: which hostname and path should be forwarded to which Service on which port. It is configuration for an ingress controller, not a proxy itself — the controller watches Ingress objects and programs the actual routing. This split explains a common confusion: an Ingress applied to a cluster with no controller is stored but never acts.

How does a request reach my app?

External traffic hits the ingress controller’s address, the controller matches the request’s host and path against Ingress rules, and forwards it to the named Service. The Service then load-balances across the pods whose labels match its selector. Four things must line up: DNS must resolve to the controller, the Ingress host must match the request, the Service must have ready endpoints, and the pod must listen on the expected port. Break any link and the request never arrives.

Why is my app unreachable after adding an Ingress?

Check in this order. First, is an ingress controller actually running? Second, does the Ingress host match the name you are requesting, including www or subdomains? Third, does the Service have endpoints — run kubectl get endpoints <service>; if it is empty, the selector does not match any pod. Fourth, is the container listening on the targetPort? Fifth, is the Ingress class set correctly if the cluster has more than one controller? Each failure produces a different symptom, which is why checking in order beats re-editing YAML at random.

Ingress vs a Service of type LoadBalancer?

A Service of type LoadBalancer asks the platform for one external address per Service, which on a cloud provider is usually a separate billable load balancer. An Ingress shares a single entry point across many Services, routing by hostname and path, which is both cheaper and easier to manage once you have more than one service. For a single service, a LoadBalancer Service is simpler; for several, an Ingress is the right shape. On k3s, ServiceLB makes LoadBalancer Services work without a cloud provider, but an Ingress is still the better pattern for multiple services.

Where this bites vibecoders
Generated Ingress YAML is usually valid and frequently nonfunctional, because the failures live outside the file: no controller installed, DNS not pointed at the controller, or a Service whose selector silently matches nothing. An AI assistant will not know your cluster’s ingress class or your DNS setup, so it writes a plausible rule and calls the deploy done. The debugging skill that matters is checking the chain — DNS, controller, Ingress, Service endpoints, port — rather than editing the manifest repeatedly.

Where AI coding assistants get this wrong

Writing an Ingress with no ingress controller installed in the cluster.
Hardcoding an ingress class that the cluster does not have.
Omitting the TLS section, or requesting a certificate for a domain that does not resolve here.
Setting the backend port to the Service port instead of the named or numeric target.
Assuming the Ingress selects pods directly, and editing it when the real problem is the Service selector.

Checklist

Confirm an ingress controller is running before writing an Ingress.
Set the correct ingress class explicitly.
Verify DNS resolves to the controller’s address.
Check the Service has endpoints before blaming the Ingress.
Configure TLS with a certificate manager so renewal is automatic.
Test with curl -H ‘Host: yourdomain’ against the controller address.

FAQ

Do I need an Ingress if I only have one service?

Not necessarily. A single Service of type LoadBalancer can expose one app directly. An Ingress becomes worth it when you have several services to route, want path-based routing, or need one certificate and entry point for everything.

What is an ingress controller?

An ingress controller is the component that reads Ingress objects and implements the routing, usually as a reverse proxy such as nginx, Traefik, or Envoy. Kubernetes defines the Ingress API but does not ship a controller, so you install one. k3s bundles Traefik.

Why does my Ingress return a 404?

A 404 from the controller usually means no rule matched the request’s host and path. Check that the host in the Ingress exactly matches the Host header you are sending, including subdomains, and that the path prefix is correct.