// under the hood
What Really Happens When You Run “kubectl apply”?
Most engineers run this command every day. Behind that single line lies an entire distributed orchestration engine working asynchronously to bring your application to life.
Infographic Architecture Map
Full Resolution ↗
🔍 Click diagram to view full high-resolution graphic in new tab.
The 8-Stage Request Lifecycle
From client-side OpenAPI parsing to the CNI assigning a routable Pod IP:
1️⃣ Client-Side (kubectl)
Validates schema against discovery cache, computes 3-way strategic merge patch, and sends HTTP POST to API Server.
2️⃣ API Server (Authentication & Admission)
Authenticates caller, checks RBAC permissions, applies Mutating Webhooks (sidecars), and validates schema rules.
3️⃣ etcd Storage & Consensus
The source of truth persists the desired state across a quorum of nodes via Raft. (No pods exist yet!)
4️⃣ Deployment & ReplicaSet Controllers
Controllers observe the watch event. Deployment controller creates a ReplicaSet; ReplicaSet creates unbound Pod objects (Pending state).
5️⃣ Kube-Scheduler
Watches for unassigned Pods. Filters ineligible nodes (Predicates) and scores candidate nodes (Priorities), then writes a Binding.
6️⃣ Kubelet & CRI (containerd)
The node agent detects its assigned Pod, pulls container images, and instructs containerd to create the pause sandbox.
7️⃣ CNI Networking & IP Assignment
The CNI plugin configures the network namespace, attaches the veth pair, assigns a Pod IP, and container execution starts.
8️⃣ Readiness Probes & Service Ingress
Once readiness checks pass, the Endpoints controller links the Pod IP to Services; kube-proxy programs routing rules to accept live traffic.
👉 The Core Principle: Kubernetes is a Desired State System
You don’t tell Kubernetes how to run your application; you tell it what you want. That declarative contract is why Kubernetes can self-heal crashed containers, autoscale on traffic surges, recover from node failures, and perform zero-downtime rolling updates.
