Skip to main content

Ingress

Kubernetes Ingress is an HTTP/HTTPS routing layer that directs external traffic to different backend Services inside a cluster based on rules like host-based, path-based etc.

For example:

api.example.com/users  ──┐
api.example.com/orders ──┼── Ingress ──> user-service
www.example.com/       ──┘               order-service
  • Traffic routing is controlled by rules defined on the Ingress resource.
  • Ingress can give Services externally-reachable URLs, load balance traffic, and terminate SSL/TLS.
note

You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.

An Ingress resource only defines the desired routing rules. An Ingress Controller actually implements them.

Why Ingress Was Introduced​

Before Kubernetes when applications were running on virtual machines, teams used load balancers like Nginx, HAProxy, F5 etc. They provided:

  • Load balancing
  • SSL termination
  • Routing rules - host and path based
  • Sticky session etc

Initially Kubernetes did not natively support all these features. Later they acknowledged that these features are something important and needed for enterprise or production applications. So, they introduced Ingress.

But then Kubernetes cannot implement separate APIs for all the available load balancers like Nginx, Traefik, Kong etc. So, they came up with the common Ingress API and others can kind of extend it to include their own implementations which are Ingress Controllers.

Now, most of the populor load balancer applications like Nginx, Apache have their own Kubernetes Ingress Controllers which we can install and use.

Why Ingress When We have LoadBalancer​

The LoadBalancer Service type exposes one Service externally by creating or configuring an external cloud load balancer.

Suppose we have multiple services and each one uses LoadBalancer service type, then we get one external cloud load balancer for each Service. This works, but creates problems.

Too many external load balancers​

Every externally exposed Service may require its own cloud load balancer resulting in:

  • Increased costs
  • Increased maintenance

Ingress allows many internal Services to share a single external entry point (LoadBalancer).

One external Load Balancer
          │
          ▼
   Ingress Controller
      ├──> user-service
      ├──> order-service
      └──> payment-service

The cloud load balancer exposes the Ingress Controller, while the controller routes traffic internally.

LoadBalancer is Service-level​

A LoadBalancer typically sends traffic to one Service. It does not normally provide application-aware routing rules such as:

example.com/api     ──> api-service
example.com/web     ──> web-service
admin.example.com   ──> admin-service

Ingress provides this Layer 7 HTTP/HTTPS routing.

A LoadBalancer Service manily answers:

How do I get traffic to my Service?

Ingress answers:

Which Service should receive this particular HTTP request?

No centralised hostname and path routing​

Without Ingress, we might need separate external endpoints, or even different ports and IP addresses:

api.example.com
web.example.com
admin.example.com

With Ingress, clients can use a unified domain. The Ingress controller selects the appropriate backend based on the request.

TLS configuration is duplicated​

If several Services are independently exposed, TLS may need to be configured separately on each one.

Service A ── TLS configuration
Service B ── TLS configuration
Service C ── TLS configuration

With Ingress, TLS can commonly be terminated at one central point.

Client ── HTTPS ──> Ingress ── HTTP or HTTPS ──> Services

This centralizes certificate configuration and often works with tools such as cert-manager for automatic certificate issuance and renewal.

HTTP features are scattered​

An Ingress controller can provide common HTTP-related capabilities in one place, such as:

  • TLS termination
  • HTTP-to-HTTPS redirects
  • URL rewrites
  • Authentication
  • Rate limiting
  • CORS handling
  • Access logging
  • WAF integration

Without Ingress, these features may need to be implemented repeatedly in each application or exposed Service.

Route changes are cumbersome​

Without Ingress, adding a new externally reachable application may mean:

  • Creating a new LoadBalancer Service
  • Configuring DNS for a new hostname
  • Updating firewall rules
  • Configuring TLS

With Ingress, adding a new route can be as simple as updating the Ingress resource with a new rule.

How LoadBalancer and Ingress Work Together​

Ingress does not necessarily replace a LoadBalancer Service. Commonly, they are used together:

Internet
   │
   ▼
Cloud Load Balancer
   │
   ▼
Ingress Controller Service
(type: LoadBalancer)
   │
   ▼
Ingress Controller Pods
   │
   ├──> frontend-service
   ├──> api-service
   └──> admin-service

The LoadBalancer Service exposes the Ingress Controller. The Ingress rules then decide where HTTP/HTTPS requests go.

So the roles are different:

  • LoadBalancer Service: Provides external network reachability.
  • Ingress: Provides centralized HTTP/HTTPS routing and edge behavior.

In short, LoadBalancer exposes Services individually, while Ingress provides a shared, application-aware entry point. We need Ingress when we want to avoid multiple public load balancers and centralize hostname routing, path routing, TLS, security, and other HTTP concerns.