This trace follows the actual state transitions behind the companion Deployments Reconcile Desired State. Each step below names its concrete inputs; values illustrate the mechanism and vary across implementations.
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.
Checkpoint: A Deployment controller compares the declared pod template with cluster state and gradually replaces replicas; readiness determines when a new Pod can receive traffic. Confirm this state before advancing to Check readiness and rollout.
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 done when this check holds: A Deployment requests six replicas but only four are ready. Compare the outcome against the companion article before making a performance claim.
Hardware, runtime, and observability notes
When tracing Trace: Deployments Reconcile Desired State in a live production environment (subsystem: distributed-systems, primary layer: system), keep the following step-level cost model and diagnostic checklist in mind:
- Step 1 (system): Declare the desired replicas — verifies state invariants before advancing the execution pointer.
- Step 2 (system): Reconcile a ReplicaSet — verifies state invariants before advancing the execution pointer.
- Step 3 (system): Schedule and start Pods — verifies state invariants before advancing the execution pointer.
- Step 4 (system): Check readiness and rollout — verifies state invariants before advancing the execution pointer.
- Step 5 (system): Retry or roll back safely — verifies state invariants before advancing the execution pointer.
Every transition across the system boundary carries both a direct CPU/memory cost (cache-line fills, descriptor lookups, lock acquisitions, or context switches) and a tail-latency queueing risk under contention. To verify this trace on your own service, capture latency histograms and hardware/kernel counters across each step boundary, compare cold-cache versus warm-cache execution paths, and confirm that error or timeout branches release all acquired descriptors, locks, and buffers cleanly.