Suppose a Deployment is changed from two replicas to three. Kubernetes does not run one synchronous command that creates a complete application. Controllers observe desired state and repeatedly reconcile the objects they own.
1. Store intent
The API server authenticates and validates the request, then stores the Deployment object. The API response confirms that the object was accepted; it does not guarantee that a new Pod is already running or ready.
2. Reconcile the ReplicaSet
The Deployment controller compares the desired pod template and replica count with observed ReplicaSets. It creates or updates a ReplicaSet that will manage the requested number of Pods. Controllers may retry when dependencies are temporarily unavailable.
3. Schedule and start
The scheduler selects a node for each unassigned Pod based on constraints and available resources. A node agent observes the assignment, prepares storage and networking, and asks the container runtime to pull the image if needed and start containers.
4. Report readiness
The kubelet reports Pod status and probe results. A Service implementation updates the set of endpoints eligible for traffic according to readiness and networking configuration. The actual transition can take time or fail at image pull, placement, startup, or health checks.
Kubernetes documents the Deployment controller and Pod lifecycle; implementation details vary across cluster versions and networking plugins.