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

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