Kubernetes networking looks confusing until you understand Ingress.
Kubernetes networking looks confusing until you understand Ingress.
Most confusion happens because people mix Service exposure with HTTP routing.
Ingress exists to solve one specific problem — how HTTP/HTTPS traffic enters your cluster.
This post explains Kubernetes Ingress using production-relevant concepts, with text diagrams and real examples.
What Problem Does Ingress Solve?
Without Ingress
-
Every Service needs its own NodePort or LoadBalancer
- Each application must be exposed individually instead of sharing one entry point.
-
Costs increase (cloud load balancers are not free)
- If you have 100 Services, you need 100 LoadBalancers.
- That means 100 public IP addresses and 100 separate billing items from the cloud provider.
-
Routing logic lives outside Kubernetes
- Traffic routing is handled by external load balancers or manual DNS rules.
- Kubernetes has no visibility or control over how traffic is routed.
-
TLS management becomes messy
- Each Service needs its own TLS certificate.
- Certificates must be renewed, rotated, and configured per Service.
- Managing HTTPS for dozens of Services becomes error-prone and hard to scale.
Ingress solves this by acting as a smart HTTP entry point.
What Is Kubernetes Ingress?
An Ingress is a Kubernetes resource that defines HTTP and HTTPS routing rules.
Ingress can:
- Route traffic by host
- Route traffic by path
- Terminate TLS (HTTPS)
- Forward traffic to Services
⚠️ Ingress does NOT handle traffic by itself.
It requires an Ingress Controller.
Ingress Controller (Critical Concept)
An Ingress Controller is the actual component that:
- Listens for external traffic
- Reads Ingress rules
- Routes traffic accordingly
Common controllers:
- NGINX Ingress Controller
- Traefik
- HAProxy
- Cloud-specific controllers (AWS ALB Ingress)
Without a controller, Ingress resources do nothing.
How Ingress Works
Client (Browser)
↓
Ingress Controller (NGINX / Traefik)
↓
Ingress Rules
↓
Service
↓
Pods (Deployment)
Ingress operates at Layer 7 (HTTP/HTTPS).
Basic Ingress Example (Single Service)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: app.sharon.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80
What this does
- Accepts traffic for app.sharon.com
- Routes all requests to app-service(k8s service name)
- Service load balances traffic to Pods
Path-Based Routing Example
Ingress can route different paths to different Services.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-app-ingress
spec:
rules:
- host: sharon.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /web
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
Routing Behaviour
sharon.com/api → api-service
sharon.com/web → web-service
Host-Based Routing Example
Ingress can route traffic by domain name.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: host-ingress
spec:
rules:
- host: api.sharon.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- host: web.sharon.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
Routing Behaviour
api.sharon.com → api-service
web.sharon.com → web-service
TLS / HTTPS with Ingress
Ingress can terminate TLS using Kubernetes Secrets.
Ingress can handle HTTPS (TLS) termination for your applications using Kubernetes Secrets.
This means HTTPS is handled at the Ingress level, not inside the application Pods.
TLS Secert
kubectl create secret tls app-tls \
--cert=cert.pem \
--key=key.pem
Ingress with TLS*
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tls-ingress
spec:
tls:
- hosts:
- app.sharon.com
secretName: app-tls
rules:
- host: app.sharon.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80
What this does
- Terminates HTTPS at the Ingress Controller
- Traffic inside the cluster remains HTTP
- TLS certificates are centrally managed
Ingress vs LoadBalancer
| Feature | Ingress | LoadBalancer |
|---|---|---|
| Layer | L7 (HTTP/HTTPS) | L4 |
| Routing | Host & path based | No |
| TLS | Yes | Limited |
| Cost | Low (single load balancer) | High (per Service) |
| Scalability | High | Limited |
Ingress is preferred for HTTP-based applications.
Common Mistakes
- Creating Ingress without an Ingress Controller
- Using LoadBalancer for every Service
- Forgetting DNS configuration
- Mixing Service exposure and routing logic
- Managing TLS separately for every Service
When You Should Use Ingress
Use Ingress when:
- You run HTTP/HTTPS applications
- You need routing by domain or path
- You want centralized TLS management
- You want to reduce cloud load balancer costs
Final Complete Flow
Internet
|
v
DNS (Domain → IP)
|
v
Ingress Controller (NGINX / Traefik)
|
v
Ingress Rules (Host / Path / TLS)
|
v
Service (Stable Endpoint)
|
v
Pods (Managed by Deployment)
Without Ingress
-
Every Service needs its own NodePort or LoadBalancer
- Each application must be exposed individually instead of sharing one entry point.
-
Costs increase (cloud load balancers are not free)
- If you have 100 Services, you need 100 LoadBalancers.
- That means 100 public IP addresses and 100 separate billing items from the cloud provider.
-
Routing logic lives outside Kubernetes
- Traffic routing is handled by external load balancers or manual DNS rules.
- Kubernetes has no visibility or control over how traffic is routed.
-
TLS management becomes messy
- Each Service needs its own TLS certificate.
- Certificates must be renewed, rotated, and configured per Service.
- Managing HTTPS for dozens of Services becomes error-prone and hard to scale.
Final Thought
Ingress is not optional in production — it is the control plane for HTTP traffic in Kubernetes.
Top comments (0)