This is Level 5 of our Kubernetes networking series.
So far, we've built up a solid foundation: But we still have a glaring gap: how does a real user on the internet actually reach your Kubernetes application?
That's exactly what this article covers — Ingress, Ingress Controllers, and the newer Gateway API.
Table of Contents The Problem: The Internet Can't Reach a ClusterIP The Basic Solution: Ingress and Gateway API What Is Ingress?
A Routing Example Ingress Is Not the Actual Proxy A Simple Analogy: Traffic Police A Basic Ingress YAML Example Breaking Down the Key Fields Host-Based Routing Path-Based Routing Why Not Just Use a LoadBalancer Service for Everything?
The Complete Traffic Flow Where Does DNS Fit In?
The Ingress Controller A Typical Architecture Ingress vs Service Ingress vs LoadBalancer Service HTTPS and TLS Termination Why Terminate TLS at the Edge?
Referencing a TLS Certificate Routing Multiple Domains The Gateway API GatewayClass, Gateway, and HTTPRoute Ingress vs Gateway API Important Distinctions: Ingress Is Not CNI or Service Troubleshooting Ingress Layer by Layer Common Ingress Mistakes The Complete Kubernetes Networking Picture (Levels 1–5) The Mental Model to Memorize Level 5 Checkpoint What's Next: NetworkPolicy The Problem: The Internet Can't Reach a ClusterIP Suppose you want users to reach your application at .
Inside your cluster, you have: A user on the internet can't simply visit — that's a private Kubernetes Service IP, invisible outside the cluster.
We need something sitting at the edge of the cluster to bridge that gap.
The Basic Solution: Ingress and Gateway API Historically, Kubernetes solved this with Ingress.
More recently, Kubernetes introduced a more expressive alternative: the Gateway API.
At a high level, both follow the same shape: That's the core mental model for this entire article.
What Is Ingress?
Ingress is a Kubernetes API object that describes how incoming HTTP/HTTPS traffic should be routed to Services.
For example: Or path-based: In short, Ingress lets you declaratively describe HTTP routing rules for your cluster.
A Routing Example Suppose you have a Service and a Service, and you want: You can express this entirely through an Ingress object: Ingress Is Not the Actual Proxy This is a critical point that trips up a lot of beginners: an Ingress object doesn't magically start receiving internet traffic on its own.
It's just a set of rules.
You need an Ingress Controller to actually enforce them — implementations include NGINX, HAProxy, Traefik, and various cloud-provider load balancer integrations.
A Simple Analogy: Traffic Police Imagine a large building with a single main entrance from the street: At the entrance, someone asks "where are you going?" If you say , you're directed to the frontend.
If you say , you're directed to the backend.
The Ingress rules are the instructions written down.
The Ingress Controller is the person actually standing there enforcing them.
A Basic Ingress YAML Example Read this as: "If the HTTP request is for , send it to the Service on port 80." Breaking Down the Key Fields — which domain this rule matches: — which URL path this rule matches.
For example, with could match , , , , and so on, depending on the exact path-matching configuration. — where the matched traffic gets sent: So together: .
Host-Based Routing One of the most useful Ingress features is routing based on hostname.
Suppose you have three domains: You can route each one to a different backend: A single entry point can serve many completely different applications this way.
Path-Based Routing You can also route based on the URL path rather than the hostname: This pattern is extremely common in real-world Kubernetes setups.
Why Not Just Use a LoadBalancer Service for Everything?
A fair question: "Why not just create a Service for every application?" You technically can — but imagine you have 50 applications: That's a lot of external load balancers to manage (and often, a lot of cost).
Instead, a single edge layer can route traffic to many applications at once: One entry point, many destinations — far simpler to operate.
The Complete Traffic Flow This is the most important diagram in this article.
Suppose a user opens : Notice how many layers we've now connected across this entire series: Where Does DNS Fit In?
This is a different DNS context than the one we covered in Level 4 — it's worth being precise about the distinction.
External DNS (public internet): Cluster DNS (internal, from Level 4): Don't mix these two up — they're separate DNS systems solving separate problems, even though both are technically "DNS." The Ingress Controller If you create an Ingress object but nothing is actually watching and implementing it, the rules just sit there inert.
You need a running Ingress Controller: The controller continuously watches Kubernetes API objects (Ingress resources) and configures its own proxy/load-balancing dataplane to match.
A Typical Architecture The exact shape of this architecture varies depending on your cloud provider and cluster setup, but this general pattern is extremely common.
Ingress vs Service An important distinction to internalize: Service answers: "How do I reach this group of Pods?" Ingress answers: "How do external HTTP/HTTPS requests get routed to Services?" In short: Service is an internal/application endpoint abstraction; Ingress is HTTP/HTTPS edge routing.
Ingress vs LoadBalancer Service These two aren't competitors — they typically work together: The cloud load balancer's job is simply to get traffic into the cluster.
Once it arrives, the Ingress Controller decides where within the cluster that HTTP request should actually go.
HTTPS and TLS Termination Ingress is commonly used to terminate TLS.
When a user visits , the encrypted connection reaches the Ingress layer first: This process — decrypting HTTPS at the edge — is called TLS termination.
Why Terminate TLS at the Edge?
Terminating TLS at the Ingress layer centralizes several responsibilities in one place: certificate management, HTTPS handling, HTTP routing, redirects, and both host- and path-based routing.
Your application can then simply receive plain HTTP internally, if that fits your security model.
That said, don't assume Ingress always means "HTTP behind the scenes" — you can also configure TLS to be re-encrypted or passed through all the way to the backend Pod, depending on your architecture and requirements.
Referencing a TLS Certificate An Ingress can reference a Kubernetes TLS Secret directly: The referenced Secret holds the certificate and private key material the Ingress implementation uses: Routing Multiple Domains Suppose you're running several distinct applications under different subdomains: A single Ingress layer can route all of them: This is host-based routing at work again, just applied across an entire portfolio of applications.
The Gateway API Now let's look at the newer Kubernetes networking API: the Gateway API.
Think of it as an evolution of Ingress, not something unrelated: Gateway API introduces a small family of dedicated resources: , , and .
GatewayClass, Gateway, and HTTPRoute answers: "What kind of Gateway implementation are we using?" — essentially, which controller manages Gateways of this class. represents the actual traffic entry point: It defines listeners, such as HTTP on port 80 or HTTPS on port
- describes the routing rules themselves — for example: Chained together: Ingress vs Gateway API You don't need to memorize every field of either API right now — just understand the high-level difference: Ingress Gateway API Maturity Older, widely adopted Newer, more expressive API family Scope Mainly HTTP/HTTPS routing Broader traffic-routing model Structure Simpler, single object More structured (GatewayClass + Gateway + Routes) A useful mental model: The Gateway API's basic resource relationship looks like this: You don't need to implement any of this from scratch right now — the goal here is u