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.
Moving Beyond “kubectl apply” and Understanding What Makes Applications Production-Ready When I first started working with Kubernetes, I thought my responsibility as a developer ended once my containe
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
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, co
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.
Most people start learning Kubernetes by creating Pods, Deployments, and Services.
kubectl create deployment nginx --image=nginx
The Pod becomes Running, the Service gets created, and everything appears to work.
But have you ever stopped to ask:
What actually happens behind the scenes when an application runs on Kubernetes?
Understanding this changed the way I think about Kubernetes.
Instead of seeing Deployments, Services, and Pods as individual resources, I started seeing them as components working together to deliver an application to end users.
Let’s walk through the complete journey.
Before Kubernetes, deploying an application was relatively simple.
Install a server.
Install the application.
Start the process.
Open a port.
Hope nothing crashes.
If the server failed, the application became unavailable.
If traffic increased, scaling was often manual.
Kubernetes was designed to solve these operational challenges.
Imagine you’re deploying a simple web application.
A user opens a browser and enters:
https://myapp.com
From that single request, several Kubernetes components begin working together.
The domain name points to an external load balancer or ingress endpoint.
The user’s request reaches the Kubernetes cluster.
At this point Kubernetes has not yet reached the application itself.
The request has only arrived at the cluster boundary.
The Ingress acts like a smart traffic controller.
It examines:
Hostname
URL path
Routing rules
Example:
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
rules:
- host: myapp.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
The Ingress determines where the request should go next.
A Service provides a stable endpoint for application Pods.
Instead of communicating directly with Pods, users communicate with Services.
Why?
Because Pods are temporary.
Pods can:
Restart
Move to another node
Be recreated
Receive new IP addresses
Services solve this problem by providing a permanent virtual endpoint.
Example:
kind: Service
spec:
selector:
app: web
The Service continuously discovers Pods matching its selector.
Suppose three Pods are running:
web-1
web-2
web-3
The Service automatically load-balances traffic among them.
Request 1 → web-1
Request 2 → web-2
Request 3 → web-3
This happens transparently.
The user never knows which Pod handled the request.
A Pod is the smallest deployable unit in Kubernetes.
Inside the Pod lives the actual application container.
Example:
containers:
- name: web
image: nginx
This container contains:
Application code
Runtime
Libraries
Dependencies
When the request reaches the Pod, the application processes it and generates a response.
Pods do not run directly on Kubernetes.
They run on Nodes.
A Node is a machine that provides:
CPU
Memory
Storage
Networking
Think of Nodes as apartment buildings.
Pods are the apartments.
Kubernetes decides which apartment building should host each tenant.
Every Node runs a component called Kubelet.
The Kubelet continuously checks:
Is the Pod running?
Did the container crash?
Does the Pod match the desired state?
If something goes wrong, Kubernetes attempts to restore the desired state automatically.
This is one of Kubernetes’ most powerful features.
The Deployment acts as the application manager.
Suppose you want three replicas:
replicas: 3
If one Pod crashes:
Current Pods: 2
Desired Pods: 3
The Deployment immediately creates another Pod.
You don’t need to intervene.
Kubernetes continuously works to ensure reality matches your declared configuration.
When I first learned Kubernetes, I viewed each resource separately.
Deployment.
Service.
Ingress.
Pod.
Node.
But real understanding came when I saw how they work together.
A user request travels through an entire chain:
User
↓
DNS
↓
Ingress
↓
Service
↓
Pod
↓
Container
↓
Application
Every Kubernetes resource exists to support that journey.
Once you understand the flow, troubleshooting becomes much easier.
Instead of guessing, you can systematically identify where the problem exists.
DNS issue?
Ingress issue?
Service issue?
Pod issue?
Application issue?
The architecture starts making sense.
The biggest lesson I learned is that Kubernetes is not really about Pods.
It’s about managing the entire lifecycle of applications.
Pods, Deployments, Services, Ingresses, Nodes, and Controllers are simply building blocks working together toward one goal:
Delivering reliable applications to users.
The moment you stop seeing Kubernetes as a collection of YAML files and start seeing it as an application delivery platform, everything begins to click.
And that’s when your Kubernetes journey truly starts.
When I began learning Kubernetes, I spent a lot of time memorizing resources and commands.
Pods.
Deployments.
Services.
Ingresses.
But the real breakthrough came when I understood how these components work together to run and deliver applications.
Kubernetes is not just a platform for managing containers — it is a system designed to ensure applications remain available, scalable, and resilient, even when failures occur.
Once you understand the journey of a request from a user’s browser to a running container, Kubernetes becomes far less intimidating and much more logical.
If you’re learning Kubernetes, don’t focus solely on YAML syntax or exam objectives.
Focus on understanding the flow.
Because when you understand how applications actually run on Kubernetes, you’re no longer just deploying workloads — you’re building the foundation for reliable, 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.