Search for a command to run...
No comments yet. Be the first to comment.
Follow my journey from DevOps Engineer to Kubestronaut as I explore Kubernetes, CNCF certifications, cloud-native technologies, and hands-on learning. In this series, I share my experiences preparing for and passing certifications such as CKA, CKAD, and CKS, along with exam strategies, study resources, troubleshooting lessons, and practical insights gained from real-world Kubernetes environments. Whether you're just starting with Kubernetes or pursuing advanced CNCF certifications, I hope these experiences help guide your own cloud-native journey.
Kubernetes networking is one of the most important — and often most confusing — topics for beginners. Pods have IP addresses, Services have virtual IPs, DNS magically resolves names, Ingress routes tr
Kubernetes Control Plane explained in a practical way for engineers who manage real-world clusters. Introduction When I first started learning Kubernetes, I could create Pods, Deployments, and Service
Kubernetes networking is one of the most important — and often most confusing — topics for beginners. Pods have IP addresses, Services have virtual IPs, DNS magically resolves names, Ingress routes tr
Most developers know that Kubernetes can automatically restart failed applications. But have you ever wondered what actually happens behind the scenes when a Pod crashes? When I first started learning
When developers first start learning Kubernetes, they quickly understand Pods and Deployments. You create a Deployment, Kubernetes creates Pods, and your application starts running. Simple, right? Not
Shahzad Ahmad | Kubernetes, DevOps & Cloud Native Journey
32 posts
Senior DevOps Engineer documenting my journey through Kubernetes, CNCF certifications, cloud-native technologies, platform engineering, and automation. Here you'll find hands-on tutorials, certification experiences (CKA, CKAD, CKS), exam strategies, troubleshooting guides, and lessons learned from real-world DevOps and Kubernetes environments. My goal is to share practical knowledge, help others in their cloud-native journey, and ultimately document the path from DevOps Engineer to Kubestronaut.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Many Kubernetes troubleshooting scenarios become easier once you understand where requests travel.
For example:
Request never reaches the cluster.
Request reaches cluster but cannot find the Service.
Service cannot find Pods.
Request reaches Service but no healthy backend exists.
Request reaches the Pod but returns an error.
Understanding the request path helps you identify where problems occur.
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.
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.