Anatomy of `kubectl apply` - Inside the Kubernetes Control Plane

<p>When I run kubectl apply, the request is sent to the <strong>Kubernetes API Server</strong>, which acts as the entry point to the cluster.</p><p>The API Server processes the request through several stages:</p><ul><li><p><strong>Authentication</strong> – validates the client (certificates, tokens, etc.)</p></li><li><p><strong>Authorization</strong> – checks permissions using RBAC</p></li><li><p><strong>Admission Controllers</strong></p><ul><li><p>Mutating (e.g., inject defaults, sidecars)</p></li><li><p>Validating (ensure request is compliant)</p></li></ul></li></ul><p>Once validated, the object is persisted.</p><p>The API Server stores the Deployment object in <strong>etcd</strong>, which is the cluster’s consistent key-value store.</p><p>At this point, the desired state is recorded—but nothing is running yet.</p><p>The <strong>Kubernetes Controller Manager</strong> detects the new Deployment via the API Server’s watch mechanism.</p><ul><li><p>Deployment Controller creates a ReplicaSet</p></li><li><p>ReplicaSet Controller creates the required Pods</p></li></ul><p>This is all driven by control loops comparing:</p><ul><li><p>Desired state (in etcd)</p></li><li><p>Current state (actual cluster)</p></li></ul><p>The Pods are created without a node assigned.</p><p>The <strong>kube-scheduler</strong>:</p><ul><li><p><strong>Filters</strong> nodes (resource constraints, taints, node selectors)</p></li><li><p><strong>Scores</strong> remaining nodes (resource availability, affinity rules)</p></li><li><p>Assigns the best node</p></li></ul><p>Once scheduled, the kubelet on the node pulls the image and starts the container.</p><p>&quot;The important thing is Kubernetes is entirely <strong>declarative and event-driven</strong>.<br>Nothing is executed immediately—instead, components continuously reconcile actual state toward desired state.&quot;</p><p> </p>