Kubernetes Ingress — A Practical Guide

Context — exposing services from a cluster

As organizations adopt microservices and Kubernetes for deploying containerized applications, one critical question arises:

“How do external users securely access my services running inside the Kubernetes cluster?”

By default, Kubernetes provides service types like ClusterIP, NodePort, and LoadBalancer to expose applications. However:

Imagine a production app like url shortener with:

• A frontend UI service
• An Auth service
• A short‑URL service
• A report service
• A metrics endpoint

Using a separate LoadBalancer for each would quickly increase cost and fragment control.

What is Kubernetes Ingress?

Kubernetes Ingress is the native solution for managing external access to your Services. It acts as a reverse proxy and traffic director, routing requests based on hostname, path, or even headers — all from a single IP address or DNS name.

• Serve multiple Services behind one domain
• Apply routing logic without touching individual Services
• Secure traffic using TLS/SSL
• Load balance across Pods
• Implement rewrites, redirects, auth, and more

Ingress is the traffic controller at the edge of your Kubernetes cluster.

1) An Introduction to Kubernetes Ingress

NodePort/LoadBalancer can work for small apps, but they don’t scale well in environments with many Services. Ingress defines HTTP(S) routing rules to expose multiple Services over a single IP or domain — the Kubernetes‑native, scalable approach.

2) Ingress Controllers: Making Ingress Work

The Ingress resource is configuration only. You need an Ingress Controller to process those rules and handle the actual traffic.

What is an Ingress Controller?

A controller runs in‑cluster (often a proxy like NGINX, HAProxy, etc.), watches for Ingress objects, and applies the specified rules.

Popular controllers

• NGINX Ingress Controller (open source, CNCF maintained)
• AWS Load Balancer Controller (for Amazon EKS)
• Traefik, Contour, Istio Gateway (service‑mesh contexts)

How it works

1. Deploy the controller into your cluster
2. Define Ingress resources
3. The controller dynamically updates routing rules

3) Routing Traffic with Ingress Rules

Ingress rules define how traffic is routed to backend Services:

• Host‑based: route by domain (e.g., api.example.com, admin.example.com)
• Path‑based: route by URL path (e.g., /login, /users)
• Header‑based: supported by advanced controllers

4) Securing Ingress with TLS

One of the most powerful features of Ingress is TLS termination — decrypting HTTPS at the edge.

• AWS ACM (with AWS Load Balancer Controller)
• cert‑manager (with NGINX and others)
• Let’s Encrypt certificates

5) Advanced Ingress Features

• URL rewrites: modify request paths before forwarding
• Load balancing: distribute traffic across replicas
• Rate limiting: control requests per client
• Header manipulation: add/modify headers
• Authentication: basic auth, JWT, external IdPs
• gRPC & WebSockets: modern protocol support
• Canary releases: split traffic for safer rollouts

AWS Load Balancer Controller vs NGINX Ingress Controller

Both manage external access to Kubernetes Services, but with different trade‑offs:

Conclusion

• All‑AWS stack? Prefer AWS Load Balancer Controller for managed, native integrations.
• Need flexibility/portability? Prefer NGINX Ingress Controller for advanced routing and deep customization.

Back to top ↑