In our last blog, we explored different ways to expose applications running inside a Kubernetes cluster to the outside world. If you're just joining this series or are new to Kubernetes, I highly recommend going through the previous blogs. They will give you a solid understanding of the networking concepts we'll be building upon in this article.
That being said, if you already have a basic understanding of Kubernetes and networking, grab a cup of coffee ☕ and let's explore how Ingress works in Kubernetes.
Ingress Basics:
This is probably the most common and heavily used method in production environments to expose applications to the outside world.
At this point, we already know that Kubernetes provides multiple ways to expose our applications.
NodePort
With NodePort, applications are exposed through a port on every cluster node.
While it is great for learning and testing, managing NodePorts at scale can quickly become painful. This is one of the reasons why NodePort is rarely used directly in production environments.
LoadBalancer
A LoadBalancer Service solves many of the limitations of NodePort. The cloud provider automatically provisions a Load Balancer and routes traffic to your application.
Sounds great, right? But there is one problem.
Every application exposed using a LoadBalancer Service typically gets its own cloud Load Balancer. As the number of applications grows, so does the cost 💸.
Imagine running 20 applications and provisioning 20 separate Load Balancers. Your cloud bill might not be very happy.
Ingress
Instead of creating a dedicated Load Balancer for every application, we can place a single Ingress Controller in front of multiple applications.
Typically, a single cloud Load Balancer forwards all incoming traffic to the Ingress Controller. The Ingress Controller then examines the incoming request and decides where it should go based on the routing rules we define.
For example:
Requests for shop.example.com can be routed to the shopping application.
Requests for api.example.com can be routed to the API service.
Requests for /admin can be routed to a completely different backend.
In simple terms, the Ingress Controller acts as the gatekeeper between the outside world and your Kubernetes cluster.
One important things to keep in mind that,
Ingress routes traffic to Services, not directly to Pods.
Components of Ingress
When people talk about Ingress, they are usually referring to two different components:
Ingress
Ingress Controller
Let's understand the difference because this is where many beginners get confused.
Ingress
Ingress is a Kubernetes resource, just like a Deployment or a Service.
It contains the routing rules that describe:
Which hostname should map to which Service
Which URL path should route to which application
How incoming traffic should be handled
Think of an Ingress resource as a traffic routing configuration file.
By itself, the Ingress resource does absolutely nothing. It simply stores the desired routing rules.
Ingress Controller
The Ingress Controller is the actual application that reads the Ingress configuration and performs the routing.
Without an Ingress Controller, creating an Ingress resource is like writing traffic rules on a piece of paper and expecting cars to follow them automatically.
Some popular Ingress Controllers include:
Note: The NGINX Ingress Controller project announced its retirement and reached end-of-life in March 2026. New Kubernetes environments are increasingly adopting alternatives such as Gateway API implementations.
The Ingress Controller does much more than simple traffic routing. Depending on the implementation, it can also provide:
TLS Termination: Users access applications securely using HTTPS, while Ingress handles SSL/TLS for us.
Authentication Integrations: Can integrate with OAuth, SSO, Identity Providers, and more.
Rate Limiting: Prevent abuse by limiting requests. i.e Stop someone from sending 10 million requests in 5 minutes 😅
Traffic Filtering: Block unwanted traffic based on headers, IPs, rules, etc.
Traffic redirection: Redirect traffic to different endpoints based on the configuration
Observability and metrics: Provides network related Metrics and logs for observability such as API response time, etc
In short, an Ingress Controller is much more than a router—it's often the first line of traffic management and security for applications running inside a Kubernetes cluster.
How Does Traffic Enter the Cluster?
Now that we understand what an Ingress Controller is, let's see how traffic actually flows through the cluster.
Internet → External Load Balancer → Ingress Controller → Application Service → Pod
In simple terms:
A user sends a request from the internet.
The request reaches the external Load Balancer.
The Load Balancer forwards the request to the Ingress Controller.
The Ingress Controller examines the request and determines where it should go.
The request is forwarded to the appropriate Kubernetes Service.
Finally, the Service routes the request to one of the application's Pods.
So the real question becomes:
How does the Ingress Controller know where to send the request? Great question 😄
How Does Ingress Know Where to Route Traffic?
We define routing behavior using an Ingress resource.
Just like Deployments define how Pods should run and Services define how applications should be exposed internally, an Ingress resource defines how external traffic should be routed.
Typically, an Ingress manifest is deployed alongside the application's Deployment and Service resources.
The Ingress resource tells Kubernetes:
Which hostname should be matched
Which URL path should be matched
Which Service should receive the traffic
Which Ingress Controller should process the request
The Ingress Controller continuously watches these Ingress resources and updates its routing configuration accordingly.
Traffic Routing Strategies
Ingress commonly routes traffic using two strategies:
Path-Based Routing
Host-Based Routing
Let's look at both with real-world examples.
Path-Based Routing
In Path Based Routing, multiple applications share the same hostname, but different URL paths are routed to different services.
Imagine we have an ecommerce platform with three applications:
Frontend Service
Product Service
Admin Service
We want all traffic to come through the same domain: example.com
But route requests based on the URL path.
example.com/products → Product Service
example.com/admin → Admin Service
example.com/ → Frontend Service
Visually:
example.com
│
▼
Ingress Controller
│ │ │
│ │ │
▼ ▼ ▼
/ /products /admin
│ │ │
▼ ▼ ▼
Frontend Product Svc Admin Svc
This approach is useful when multiple applications belong to the same domain but serve different functions.
Host-Based Routing
In Host Based Routing, traffic is routed based on the hostname requested by the user.
For example:
shop.example.com → Shopping Service
api.example.com → API Service
admin.example.com → Admin Service
The Ingress Controller examines the Host header in the incoming request and forwards traffic to the appropriate Service.
Visually:
Ingress Controller
│
┌───────────────┼────
│ │ │
▼ ▼ ▼
shop.example.com api.example.com admin.example.com
│ │ │
▼ ▼ ▼
Shopping Svc API Svc Admin Svc
This is one of the most common routing patterns used in production environments because different applications can have their own dedicated subdomains while still sharing the same Ingress Controller and Load Balancer.
In practice, most production environments use a combination of both Host-Based and Path-Based Routing. For example:
api.example.com/v1 → API v1 Service
api.example.com/v2 → API v2 Service
shop.example.com → Shopping Service
admin.example.com → Admin Service
This provides a flexible and cost-effective way to expose multiple applications without provisioning a separate Load Balancer for each one.
Enough Theory, Let's Build It!
So far, we've covered a lot of concepts around Ingress, Ingress Controllers, and traffic routing. But as engineers, we all know one thing:
The real learning starts when we get our hands dirty. 😄
Let's move beyond the theory and see Ingress in action.
For this demo, we'll use Traefik, one of the most popular Kubernetes Ingress Controllers. We'll deploy Traefik, expose a couple of sample applications, and then configure Ingress rules to route traffic based on hostnames and URL paths.
Rather than walking through a simple demo here, I've put together a dedicated hands-on lab repository where you can practice everything we've learned in this blog.
The repository includes step-by-step exercises covering:
Installing and configuring Traefik
Creating Ingress resources
Path-Based Routing
Host-Based Routing
TLS configuration
Traffic validation and troubleshooting
Real-world Ingress scenarios
👉 Follow along using the hands-on labs
My recommendation is simple: don't just read the manifests deploy them, modify them, break them, and fix them. That's the fastest way to understand how Ingress works under the hood.
Conclusion
In this blog, we explored one of the most important concepts in Kubernetes networking: Ingress.
We started by understanding why Ingress was introduced and the challenges it solves compared to NodePort and LoadBalancer Services. We then learned the two key components involved:
Ingress Resource
Ingress Controller
We also looked at how traffic flows from the internet into a Kubernetes cluster and explored two common routing strategies:
Path-Based Routing
Host-Based Routing
By now, you should have a solid understanding of how a single Ingress Controller can intelligently route traffic to multiple applications while reducing infrastructure costs and simplifying traffic management.
Of course, what we've covered here is just the beginning. Modern Ingress Controllers such as Traefik provide many advanced capabilities that are commonly used in production environments.
Some great next steps to explore are:
TLS/SSL – Secure your applications with HTTPS and TLS certificates.
Authentication – Protect applications using Basic Authentication, OAuth, or external identity providers.
Rate Limiting – Prevent abuse and protect services from excessive traffic.
Canary Deployments – Gradually roll out new versions using weighted traffic routing.
Monitoring & Observability – Integrate Prometheus and Grafana to monitor traffic patterns and controller health.
Most importantly, don't stop with the theory. Take the examples from the hands on repository, experiment with them, break them intentionally, and troubleshoot the issues. That's where Kubernetes networking truly starts to make sense.
Until then, happy learning and happy Kubernetes-ing! 🚀
