The Life of a Request Inside Kubernetes
One of the most common questions developers ask when they start working with Kubernetes is:
“What actually happens when a user sends a request to my application?”
We deploy Pods, create Services, configure Ingress resources, and expose applications to the internet. But once a request enters a Kubernetes cluster, it travels through several layers before finally reaching the application container.
Understanding this journey is one of the most important Kubernetes concepts because it connects networking, services, load balancing, and application delivery into a single picture.
Let’s follow a request from a user’s browser all the way to a running container.
The Scenario
Imagine you’ve deployed a simple web application.
User
|
v
Ingress
|
v
Service
|
v
Pod
Your application is accessible at:
https://shop.example.com
The user opens the website and clicks a product page.
What happens next?
Step 1: The Browser Sends a Request
The journey starts on the user’s device.
The browser sends an HTTPS request:
GET /products
Host: shop.example.com
Before the request reaches Kubernetes, DNS resolution occurs.
The browser asks:
Where is shop.example.com?
DNS responds with an IP address.
203.0.113.10
This IP typically belongs to:
Load Balancer
Cloud Load Balancer
Ingress Controller
The browser now knows where to send the request.
Step 2: The Load Balancer Receives the Request
In cloud environments such as:
AWS
Azure
Google Cloud
an external Load Balancer is often the first Kubernetes component that receives traffic.
Example:
Internet
|
v
Load Balancer
The Load Balancer acts as the entry point into the cluster.
Its responsibilities include:
Accepting incoming traffic
Health checking backend nodes
Distributing traffic across nodes
The request is then forwarded into the Kubernetes cluster.
Step 3: The Ingress Controller Takes Over
The request reaches an Ingress Controller.
Popular examples include:
NGINX Ingress Controller
Traefik
HAProxy
Kong
The Ingress Controller examines:
Host Header
Path
Protocol
Example:
Host: shop.example.com
Based on Ingress rules:
rules:
- host: shop.example.com
http:
paths:
- path: /
backend:
service:
name: web-service
the controller determines which Service should receive the request.
Think of Ingress as a smart traffic director.
Step 4: The Service Receives Traffic
The request is now forwarded to:
web-service
The Service acts as a stable networking endpoint.
This is important because Pods are temporary.
Today a Pod may be:
10.1.0.15
Tomorrow it may be:
10.1.0.27
Applications cannot rely on Pod IP addresses.
The Service solves this problem by providing a permanent virtual IP.
Example:
kind: Service
spec:
selector:
app: web
The Service continuously tracks matching Pods.
Step 5: kube-proxy Performs Load Balancing
The Service itself does not forward traffic.
Instead, Kubernetes uses:
kube-proxy
running on every node.
kube-proxy maintains networking rules using:
iptables
IPVS
nftables
When traffic arrives at the Service IP:
10.96.0.25
kube-proxy selects one healthy Pod.
Example:
Pod A
Pod B
Pod C
The request may be routed to:
Pod B
This provides built-in load balancing.
Step 6: The Pod Receives the Request
The request finally reaches the target Pod.
Inside the Pod, the container receives:
GET /products
Your application processes the request.
For example:
Spring Boot
Node.js
Python Flask
Go Application
.NET API
The application performs business logic.
Typical actions include:
Database queries
API calls
Cache lookups
Authentication checks
The application generates a response.
Step 7: The Response Travels Back
The response now travels in reverse.
Application
|
v
Pod
|
v
Service
|
v
Ingress
|
v
Load Balancer
|
v
Browser
Example response:
200 OK
with product information.
The browser renders the page.
The user sees the results.
The entire process typically takes milliseconds.
What Happens If the Pod Fails?
Suppose the selected Pod crashes.
Pod B
becomes unavailable.
Kubernetes immediately removes it from the Service endpoints.
Future requests are routed to:
Pod A
Pod C
instead.
Users continue accessing the application without noticing the failure.
This is one of the reasons Kubernetes provides high availability.
What Happens When Traffic Increases?
Imagine traffic suddenly jumps from:
100 requests/sec
to:
5,000 requests/sec
The Horizontal Pod Autoscaler may create additional Pods.
Example:
Pod A
Pod B
Pod C
Pod D
Pod E
Pod F
The Service automatically discovers the new Pods.
No configuration changes are required.
Traffic begins flowing to the new instances immediately.
A Simple Visualization
The complete request journey looks like this:
User Browser
|
v
DNS
|
v
Load Balancer
|
v
Ingress Controller
|
v
Service
|
v
kube-proxy
|
v
Pod
|
v
Application
|
v
Response
Every Kubernetes application follows some variation of this path.
Why Understanding This Matters
Many Kubernetes troubleshooting scenarios become easier once you understand where requests travel.
For example:
DNS Issue
Request never reaches the cluster.
Ingress Misconfiguration
Request reaches cluster but cannot find the Service.
Service Selector Issue
Service cannot find Pods.
Pod Failure
Request reaches Service but no healthy backend exists.
Application Bug
Request reaches the Pod but returns an error.
Understanding the request path helps you identify where problems occur.
Final Thoughts
When users access a Kubernetes-hosted application, much more happens than simply reaching a container.
A single request may pass through:
DNS
Load Balancer
Ingress Controller
Service
kube-proxy
Pod
Application
before returning a response.
Kubernetes abstracts much of this complexity, making applications easier to deploy and scale. However, understanding these layers is essential for debugging, performance tuning, and operating production workloads.
The next time you open an application running on Kubernetes, remember that every request is taking a carefully orchestrated journey through multiple components before reaching the code you’ve written.
And that’s one of the reasons Kubernetes is such a powerful platform for modern cloud-native applications.
Connect With Me
If you’re preparing for Kubernetes certifications, pursuing the Kubestronaut journey, or working in the cloud-native ecosystem, I’d love to connect.
Follow me for more articles on Kubernetes, CNCF certifications, DevOps, Platform Engineering, and Cloud-Native technologies.
LinkedIn: https://www.linkedin.com/in/shahzadaliahmad/
LFX Profile: https://openprofile.dev/profile/shahzadahmad91
Credly: https://www.credly.com/users/shahzadahmad
Website: https://shahzadahmad.dev/
If you found this article helpful, consider sharing it with others in the Kubernetes community.
