Follow the complete journey of a Kubernetes Deployment—from your terminal to a running container inside the cluster.
Most Kubernetes tutorials teach us how to create resources:
kubectl apply -f deployment.yaml
A few seconds later, Pods start running.
Simple, right?
But Kubernetes is doing far more work than most people realize.
Hola Amigos! Welcome to the third episode of K8s with Pravesh. Today, we're going to dive into the lifecycle of one of the most commonly used Kubernetes commands: kubectl apply.
Behind this simple command lies a chain of events involving the API Server, ETCD, Controller Manager, Scheduler, Kubelet, and Container Runtime.
Understanding this workflow is one of the biggest steps toward becoming a better Kubernetes engineer. In this article, we'll trace every step that occurs after running kubectl apply and see how Kubernetes transforms a YAML file into a running application.
So, without further ado, let's get started.
How Does the Information Flow?
Before we dive deep, let's first get ourselves familiar with kubectl.
kubectl is the command-line tool that helps us interact with a Kubernetes cluster. Whenever a user runs:
kubectl apply -f deployment.yaml
the YAML file is sent to the API Server, which acts as the front door of Kubernetes.
The API Server authenticates the request, validates the manifest, and processes Kubernetes objects such as Deployments, Services, Pods, ReplicaSets, and many others.
Once the API Server has the YAML, you might wonder:
"Does Kubernetes create the Pods immediately?"
The answer is No.
Instead of creating Pods right away, Kubernetes first stores the desired state of the resources inside ETCD.
ETCD acts as the primary database—and often the "brain"—of the Kubernetes cluster. Just like in GitOps, where Git serves as the single source of truth, ETCD is the single source of truth for the cluster. It stores the complete cluster state, configuration data, and metadata.
Now you might be wondering:
"Okay, the data is stored in ETCD... but who reads it?"
This is where the Controller Manager comes into the picture.
The Controller Manager is one of the core control plane components. It continuously watches the desired state stored in ETCD and compares it with the current state of the cluster. Whenever it detects a difference, it takes action to reconcile them.
This reconciliation loop is also what enables Kubernetes' self-healing capabilities. For example, if a Pod crashes unexpectedly, the Controller Manager notices the mismatch and automatically creates a replacement Pod to restore the desired state.
Inside our manifest, we only created a Deployment. We never explicitly created a ReplicaSet.
Kubernetes takes care of that for us.
The Deployment Controller automatically creates a ReplicaSet, and the ReplicaSet Controller ensures that the desired number of Pods are always running.
Now comes another important question:
"We have the Pods ready, but who decides where they'll run?"
This is the job of the Scheduler.
The Scheduler is responsible for assigning pending Pods to the most suitable node in the cluster.
It does this in two stages:
- Filtering – Removes nodes that don't satisfy the Pod's requirements, such as available resources, taints, tolerations, affinity, or node selectors.
- Scoring – Evaluates the remaining nodes and selects the best one based on Kubernetes' scheduling algorithms.
Once the Scheduler selects a node, the Kubelet—the primary node agent running on every worker node—takes over.
The Kubelet watches the API Server for Pods assigned to its node. Once it receives the instruction, it communicates with the container runtime (such as containerd) and ensures that the desired state is achieved.
Finally, the container runtime pulls the required container image (if it isn't already available), creates the container, and starts it.
And that's how a simple kubectl apply command works under the hood.
Kubernetes Is Not Magic
When beginners first start learning Kubernetes, it almost feels like magic.
kubectl apply -f deployment.yaml
...and boom! Your application is up and running in no time.
But in reality, Kubernetes is a collection of specialized components working together through a continuous reconciliation process.
Every component has a specific responsibility:
- API Server accepts and validates requests.
- ETCD stores the cluster state.
- Controller Manager reconciles the desired and current state.
- Scheduler selects the best node for Pods.
- Kubelet manages workloads on each node.
- Container Runtime pulls images and runs containers.
Once you understand this flow, troubleshooting Kubernetes becomes much less stressful because you know exactly where to look when something breaks.
Conclusion
And that's the journey of a simple kubectl apply command.
What looks like a single command from our terminal is actually a well-orchestrated sequence of events involving multiple Kubernetes components, each doing one specific job. This separation of responsibilities is what makes Kubernetes powerful, scalable, and resilient.
I hope this article helped you understand not just what Kubernetes does, but how it does it behind the scenes.
This is just the beginning of our Kubernetes Internals journey. In the upcoming articles, we'll dive deeper into individual components like the API Server, ETCD, Scheduler, Kubelet, and many more to understand how they work under the hood.
If you enjoyed this article, consider following me on my socials, where I regularly share content around Kubernetes, AWS, DevOps, and Cloud Engineering.
- 🌐 Blog: blog.praveshsudha.com
- 💼 LinkedIn: Pravesh Sudha
- 🐦 X (Twitter): @praveshstwt
- 💻 GitHub: Pravesh-Sudha
- 📺 YouTube: Pravesh Sudha
See you in the next episode of K8s with Pravesh. 🚀
SOCIAL SHARE CARD GENERATOR