kubectl apply -f my-pod.yaml

But what actually happens after that?

Step 1: Your YAML Hits the API Server  :

Your Request goes to the API Server, which is the front door of your cluster.

The API Server:

Validates the YAML (checks syntax, required fields, etc.)Returns an error if anything is invalid

If valid, it moves forward

All requests in Kubernetes go through the API Server.

Step 2: API Server Stores It in etcd

Once validated, the API Server saves the desired state in the database(etcd):

"A Pod named my-pod should exist in the cluster."

That database is called etcd — it stores the entire state of your cluster.

• At this point:

  • The Pod exists in the cluster state

  • But it has no node assigned yet

Pod status:

Pending

Step 3: Controller Notices Something’s Missing

The Controller Manager is always watching the cluster state

it sees:

“There’s a record in etcd *saying this Pod should exist… but I don’t see it running.”*So, it triggers the next step: Pod scheduling.

Step 4: Scheduler Picks the Best Node

• The scheduler Evaluates:
– CPU / Memory
– Node labels & affinity
– Taints & tolerations

• Then it selects a best Worker Node and tells the API Server to bind the Pod to that Node.

⚠️ Remember: the Scheduler doesn’t create Pods — it just assigns them.

Step 5: Kubelet on the Node Takes Over

Each node has a kubelet that:
• Watches the API Server continuously
• Detects Pods assigned to its node

When detected, it:
• Pulls image (via container runtime like containerd)
• Creates containers
• Sets up networking
• Mounts volumes
• Starts the pod and monitors the health of the Pod

If anything goes wrong (e.g., image not found), the kubelet reports it.

💡 Important:
❌ API Server does NOT push instructions
✅ Kubelet pulls state from API Server

step 6: Pod Is Running!

Once everything is good:

Your Pod is marked as Running

You can see it with:

$ kubectl get pods

here After a Pod is created, the kubelet on the assigned node continuously monitors it.

As the Pod’s state changes, the kubelet sends status updates to the Kubernetes API Server.

The API Server then stores that updated information in etcd, which is the cluster’s database.

When you run:

kubectl get pods

The request goes to the API Server.

The API Server:

• Reads the latest Pod state from etcd

• Returns that information back to kubectl (to you)

Example Pod status updates include:

• Pending

• ContainerCreating

• Running

• CrashLoopBackOff

• Failed

Simplified Flow

kubelet → updates Pod status → API Server → stores in etcd

kubectl get pods → API Server → reads from etcd → shows output to you

commands:

kubectl apply -f my-pod.yaml                 # Create the Pod
kubectl get pods                                    # See Pod status
kubectl describe pod my-pod                # View detailed events
kubectl get events --sort-by=.metadata.creationTimestamp