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.
See you in the next episode of K8s with Pravesh. 🚀
SOCIAL SHARE CARD GENERATOR