Warrior, you've now learned Services, so you're ready for one of the most important concepts in real-world Kubernetes:
Ingress = HTTP/HTTPS entry point and routing layer for applications inside a Kubernetes cluster.
We'll build this mental model:
INTERNET
│
▼
┌──────────────┐
│ Load Balancer│
└──────┬───────┘
│
▼
┌──────────────┐
│ Ingress │
└──────┬───────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
frontend-svc backend-svc admin-svc
│ │ │
Pods Pods PodsImagine your application has:
Next.js frontend
Node.js API
Admin applicationYou have:
frontend-service
backend-service
admin-serviceWithout an HTTP routing layer, you could expose them separately:
frontend → LoadBalancer
backend → LoadBalancer
admin → LoadBalancerThat can become expensive and unnecessarily complicated.
Instead, we want:
example.com
│
▼
Ingress
/ | \
/ | \
▼ ▼ ▼
FE API AdminAn Ingress is a Kubernetes API object containing rules for routing HTTP/HTTPS traffic to Services.
For example:
example.com/
↓
frontend-service
example.com/api
↓
backend-service
admin.example.com
↓
admin-serviceSo:
Ingress defines HTTP/HTTPS routing rules.
But there's an important distinction.
This is a very common interview question.
The Kubernetes object containing rules.
kind: IngressThe actual software that reads those rules and handles traffic.
Examples include:
NGINX Ingress Controller
Traefik
HAProxy
AWS Load Balancer ControllerConceptually:
Ingress YAML
│
▼
Ingress Controller
│
▼
Actual HTTP trafficAn Ingress object by itself doesn't magically route traffic.
You need an Ingress Controller or another implementation that supports the Ingress API.
Suppose:
frontend-service → frontend Pods
backend-service → backend PodsWe want:
example.com/
↓
frontend-service
example.com/api
↓
backend-serviceIngress:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80
- path: /api
pathType: Prefix
backend:
service:
name: backend-service
port:
number: 80The first rule:
host: example.commeans:
Request hostname:
example.comThen:
path: /means traffic for the root path goes to:
frontend-serviceAnd:
path: /apigoes to:
backend-serviceSo:
https://example.com/
↓
frontend-servicewhile:
https://example.com/api/users
↓
backend-serviceThis is called:
Path-based routing
Example:
example.com/
↓
Frontend
example.com/api
↓
Backend
example.com/admin
↓
AdminArchitecture:
example.com
│
▼
Ingress
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
/ /api /admin
│ │ │
▼ ▼ ▼
Frontend Backend Admin
Service Service ServiceYou can also route based on domain/subdomain.
For example:
example.com
↓
frontend-service
api.example.com
↓
backend-service
admin.example.com
↓
admin-serviceIngress:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: backend-service
port:
number: 80
- host: admin.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: admin-service
port:
number: 80Now:
example.com
↓
Frontend
api.example.com
↓
Backend
admin.example.com
↓
Adminexample.com/
example.com/api
example.com/adminexample.com
api.example.com
admin.example.comYou can also combine them.
For example:
api.example.com/v1
↓
API v1
api.example.com/v2
↓
API v2pathType?#You'll commonly see:
pathType: PrefixThere are three Kubernetes path types:
Exact
Prefix
ImplementationSpecificpath: /api
pathType: ExactMatches:
/apibut not necessarily:
/api/userspath: /api
pathType: PrefixMatches paths under:
/api
/api/users
/api/products
/api/orders/123This is commonly useful for APIs.
The interpretation depends on the Ingress Controller.
For beginners, prefer understanding:
Exact
Prefixfirst.
This is critical.
Ingress normally does not directly select Pods.
The flow is:
Ingress
↓
Service
↓
PodsExample:
Internet
↓
Ingress
↓
backend-service
↓
PodSo you should not think:
Ingress → PodThink:
Ingress → Service → PodSuppose you have:
frontend-service
backend-serviceand:
frontend Pods
backend PodsArchitecture:
INTERNET
│
▼
Ingress
/ \
/ \
▼ ▼
frontend-service backend-service
│ │
┌────┼────┐ ┌────┼────┐
▼ ▼ ▼ ▼ ▼ ▼
Pod Pod Pod Pod Pod PodIngress generally operates at:
HTTP/HTTPS application layer (Layer 7).
That's why it can understand things like:
Host
Path
HTTP method
TLS
HTTP headersFor example:
/api/userscan be routed differently from:
/adminA basic TCP load balancer doesn't inherently make decisions based on HTTP URL paths in the same way.
Transport-level:
TCP
UDPExample:
IP:PortApplication-level:
HTTP
HTTPSExample:
Host: api.example.com
Path: /usersIngress is primarily about HTTP/HTTPS routing.
Production applications should use:
HTTPSinstead of plain:
HTTPTraffic:
Browser
│
│ HTTPS
▼
Ingress
│
│ HTTP/internal HTTPS depending on setup
▼
Service
▼
PodsIngress can be configured with TLS certificates.
Example:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
tls:
- hosts:
- example.com
secretName: example-tls
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80secretName?#Here:
secretName: example-tlsKubernetes references a Secret containing TLS certificate information.
Conceptually:
TLS Secret
│
├── Certificate
└── Private KeyThe Ingress Controller uses it to terminate TLS.
Suppose:
Browser
│
│ HTTPS
▼
IngressIngress decrypts the HTTPS traffic.
Then internally:
Ingress
│
│ HTTP
▼
Service
│
▼
PodThis is called:
TLS termination at the Ingress layer.
You can also configure encryption from Ingress onward when required.
Suppose your domain is:
example.comYou need DNS to resolve it to the external entry point.
Conceptually:
example.com
│
▼
DNS
│
▼
Load Balancer IP / hostname
│
▼
IngressSo Kubernetes Ingress doesn't magically create your domain registration.
You still need appropriate DNS configuration.
Imagine you type:
https://api.example.com/usersThe request might travel:
Browser
│
│ HTTPS
▼
DNS
│
▼
Cloud Load Balancer
│
▼
Ingress Controller
│
│ host = api.example.com
│ path = /users
▼
backend-service
│
▼
backend Pod
│
▼
Node.jsThis is the flow you should be able to explain in an interview.
Let's make the distinction crystal clear.
You create:
kind: IngressBut Kubernetes needs something actually processing that configuration.
For example:
Ingress Resource
│
▼
NGINX Ingress Controller
│
▼
TrafficThe controller watches the Kubernetes API for Ingress resources and configures its traffic-routing behavior accordingly.
Examples:
Widely used Kubernetes ingress implementation.
Popular reverse proxy / ingress solution.
For example, cloud providers may offer controllers that integrate Kubernetes routing with their native load-balancing systems.
The exact choice depends on your platform and architecture.
This confuses many beginners.
Internet
↓
Cloud Load Balancer
↓
Service
↓
PodsInternet
↓
Load Balancer
↓
Ingress Controller
↓
Service
↓
PodsIngress gives you HTTP-aware routing.
Suppose you have:
frontend
backend
admin
paymentsUsing separate LoadBalancer Services:
4 applications
↓
4 external load balancersIngress can potentially provide:
1 external entry point
↓
Ingress
┌────┼────┬────┐
▼ ▼ ▼ ▼
FE API Admin PaymentsThis can simplify routing and infrastructure, although exact cost and architecture depend on the cloud provider and controller.
Ingress Controllers often support additional configuration through annotations.
For example, depending on the controller:
metadata:
annotations:
...Possible features include:
URL rewriting
Rate limiting
Authentication
Redirects
Timeouts
Request size limits
Security settingsBut:
Annotations are controller-specific.
Don't assume an annotation supported by NGINX will work with every other Ingress Controller.
Another important distinction.
Ingress handles application routing.
Security can involve:
Cloud firewall
NetworkPolicy
Security Groups
WAF
RBAC
Authentication
TLSDon't think:
Ingress = complete security layerIt isn't.
These concepts overlap but aren't identical.
An API Gateway can provide capabilities such as:
Authentication
Authorization
Rate limiting
API keys
Analytics
Transformation
Caching
RoutingIngress primarily provides HTTP routing into Kubernetes, although specific controllers/gateways can provide additional features.
In modern Kubernetes ecosystems, Gateway API is also increasingly important and provides a more expressive routing model than the original Ingress API.
We'll focus on Ingress first because it's foundational.
Since you work heavily with Next.js and Node.js, imagine this:
INTERNET
│
▼
┌────────────────┐
│ Load Balancer │
└───────┬────────┘
│
▼
┌───────────┐
│ Ingress │
└─────┬─────┘
│
┌────────────┼────────────┐
│ │
example.com api.example.com
│ │
▼ ▼
nextjs-service node-api-service
│ │
┌─────┼─────┐ ┌─────┼─────┐
▼ ▼ ▼ ▼ ▼ ▼
Pod Pod Pod Pod Pod Pod
│
▼
postgres-service
│
▼
PostgreSQLThis is very close to the type of architecture you'll encounter in real projects.
Assume you already have:
frontend-service
backend-serviceCreate:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: myapp.local
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: frontend-service
port:
number: 80
- path: /api
pathType: Prefix
backend:
service:
name: backend-service
port:
number: 80Apply:
kubectl apply -f ingress.yamlCheck:
kubectl get ingressMore details:
kubectl describe ingress app-ingressIf you're using:
Minikube
Kind
Docker Desktop KubernetesIngress setup varies.
For example, Minikube commonly provides an ingress addon:
minikube addons enable ingressThen:
kubectl get pods -n ingress-nginxmay show the controller.
Don't assume every Kubernetes cluster has an Ingress Controller installed by default.
When:
https://example.comdoesn't work, don't randomly change YAML.
Follow the path.
kubectl get ingresskubectl describe ingress app-ingressDepending on the controller:
kubectl get pods -Akubectl get svckubectl get endpointsliceskubectl get pods -o widekubectl logs <pod-name>The request path is:
DNS
↓
Load Balancer
↓
Ingress Controller
↓
Service
↓
Pod
↓
ApplicationFind where it breaks.
You create:
kind: Ingressbut nothing is actually processing it.
Result:
Ingress exists
but traffic doesn't workIngress:
name: backend-servicebut actual Service:
backendTraffic won't reach the intended backend.
Ingress points to:
Service port 80but the actual Service doesn't expose that port.
Service selector doesn't match Pod labels.
Service selector
≠
Pod labelsYour Ingress might be perfectly configured, but:
api.example.comdoesn't resolve to your external entry point.
Then the problem is DNS, not Kubernetes routing.
Ingress is a Kubernetes API resource that defines HTTP/HTTPS routing rules for directing external traffic to Services.
Software that watches Ingress resources and implements their routing behavior.
Normally:
Ingress
↓
Service
↓
PodsRouting based on hostname:
api.example.com → backend
admin.example.com → adminRouting based on URL path:
example.com/ → frontend
example.com/api → backendHTTPS is decrypted at the Ingress/load-balancing layer before traffic is forwarded internally.
No.
Ingress and Service are different Kubernetes resources.
No.
An appropriate Ingress Controller or implementation must be available.
Remember these four concepts:
Ingress
↓
Routing rules
Ingress Controller
↓
Actually implements the routing
Service
↓
Stable endpoint for Pods
Pod
↓
Runs applicationComplete flow:
INTERNET
│
▼
DNS
│
▼
Load Balancer
│
▼
Ingress Controller
│
┌────────┴────────┐
│ │
example.com api.example.com
│ │
▼ ▼
frontend-service backend-service
│ │
Pods PodsIngress decides WHERE HTTP traffic should go; Service provides the stable endpoint; Pods run the application.
You've now connected almost everything:
INTERNET
│
▼
Load Balancer
│
▼
Ingress
/ \
/ \
▼ ▼
Frontend Service API Service
│ │
┌────┼────┐ ┌────┼────┐
▼ ▼ ▼ ▼ ▼ ▼
Pod Pod Pod Pod Pod Pod
│
▼
PostgreSQL Service
│
▼
PostgreSQL Pod
│
▼
PVC
│
▼
Persistent StorageAnd configuration:
ConfigMap ──┐
├──> Pod
Secret ─────┘You're now ready for the scaling and reliability phase.
We'll learn:
CPU
Memory
Requests
Limits
QoS Classes
OOMKilled
CPU throttling
ResourceQuota
LimitRangeand, most importantly:
How Kubernetes decides how much CPU and memory your Pods need, and what happens when they use too much.
Mark it as complete to track your mastery.