Kubernetes Ingress Explained — Routing, TLS, and Real Examples

[MyrinNew]

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

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.




More...