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:

1. Ingress

2. 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:

• NGINX Ingress Controller (one of the most widely used options, but officially retiring in March 2026)

• Traefik

• HAProxy

• Istio Ingress Gateway

• Kong Ingress Controller

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:

1. A user sends a request from the internet.

2. The request reaches the external Load Balancer.

3. The Load Balancer forwards the request to the Ingress Controller.

4. The Ingress Controller examines the request and determines where it should go.

5. The request is forwarded to the appropriate Kubernetes Service.

6. 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:

1. Path-Based Routing

2. 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! 🚀