This trace follows the actual state transitions behind the companion Deployments Reconcile Desired State. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Declare the desired replicas
Kubernetes controllers continuously compare observed cluster state with a declared desired state. A Deployment describes a target number and version of replicated Pods; its controller creates or replaces ReplicaSets and Pods to move the system toward that target.
Step 2: Reconcile a ReplicaSet
When a container image changes, a Deployment can create a new ReplicaSet and gradually shift replicas according to rollout settings. Readiness probes influence whether a Pod is considered ready to receive traffic; liveness probes can trigger a restart when a process is unhealthy under the configured test.
Step 3: Schedule and start Pods
A Deployment controller compares the declared pod template with cluster state and gradually replaces replicas; readiness determines when a new Pod can receive traffic.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Check readiness and rollout
A declarative manifest is a desired-state request, not proof the change succeeded. A rollout may stall because images cannot be pulled, capacity is unavailable, or readiness never passes. Probes should test the intended health contract; overly aggressive probes can restart healthy but slow-starting processes.
Step 5: Retry or roll back safely
A Deployment requests six replicas but only four are ready. List the cluster and application signals you would inspect before increasing the replica count.
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.