From Kubectl Apply to Running Containers

A successful kubectl apply can return before any container has started. It records the Deployment as desired state; controllers observe that state and reconcile toward Containers. The command submits intent. The cluster still has work to do.

When you apply web, the API server authorizes and validates the request before persisting the Deployment in etcd. etcd confirms the write, and the API returns a result to kubectl. That response confirms the resource was accepted, not that Pods are running.

The Deployment controller observes the desired state in Deployment web and creates a ReplicaSet configured for two replicas. That records how many Pods should exist; it doesn’t start containers itself.

With two replicas desired and none present, the ReplicaSet controller creates Pod 1 and Pod 2. That’s replica-count reconciliation: it keeps the number of Pods aligned with the Deployment’s target. Creating a Pod doesn’t assign it to a node; scheduling is a separate handoff.

Let's think this through. The ReplicaSet controller created two Pods, but neither has a node yet. Which component assigns their nodes? A: The Deployment controller. B: The scheduler. C: The kubelet. Choose an answer, or just think it through. I'll explain in a moment.

The answer is B: The scheduler. The scheduler selects a node for each unscheduled Pod and records that assignment through the API server. The ReplicaSet controller creates Pods; kubelets start containers after Pods are assigned to their nodes.

The API presents the scheduler with the two unassigned Pods. The scheduler selects eligible placement: Pod one on Node A, and Pod two on Node B. It records each assignment through the API. That tells the cluster where to run them, but it doesn’t start the containers.

For each assigned Pod, the API makes the assignment visible to that node’s kubelet. The kubelet asks its container runtime to start the container; the runtime reports it running, and the kubelet sends Pod status back to the API. This loop turns stored intent into observed containers, one node at a time.

A running container has started, but that doesn't mean its readiness checks pass. And even a Ready Pod isn't automatically reachable; users need an access path. Applying the Deployment proves neither.

Apply records desired state; independent control loops work toward it. API, controllers, scheduler, kubelets bring containers up.