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 RBAC

• Admission Controllers

  • Mutating (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 ReplicaSet

• ReplicaSet Controller creates the required Pods

This 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 node

Once 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."