Deployments and ReplicaSets

What you will be able to do

• Distinguish deployment intent from replicaset owner in a realistic deployments and replicasets case.
• Interpret the operational evidence and boundary associated with pod replicas.
• Choose an appropriate action involving revision history without exceeding the named workload scope.
• Verify availability result through an observable runtime result and reproducible handoff.

01

Frame Deployments and ReplicaSets

Use Deployments and ReplicaSets to declare replica state, observe rollout revisions, and verify availability instead of managing Pods individually.

A three-replica API must move to a new image while retaining service capacity and a traceable previous revision.

Keep declared state, runtime state, observable evidence, access boundaries, and recovery outcomes separate. Begin with the smallest read-only inspection that identifies the exact image, container, Pod, controller, network, storage object, or policy in scope.

02

Deployment intent

A Deployment manages a declarative rollout for stateless Pods through ReplicaSets. Within deployments and replicasets, this role answers one specific container or orchestration question and keeps its own evidence.

Set the desired image, replica count, labels, and update strategy in the Deployment. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not edit managed pods as the source of desired state. The observable result is specific: the deployment records the intended api revision.

03

ReplicaSet owner

A ReplicaSet keeps the requested number of matching Pod replicas for one template revision. Within deployments and replicasets, this role answers one specific container or orchestration question and keeps its own evidence.

Inspect the new and previous ReplicaSets during rollout. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not scale an owned replicaset separately from its deployment. The observable result is specific: replicaset counts explain the rollout transition.

04

Pod replicas

Deployment-managed Pods are replaceable instances selected by labels rather than durable identities. Within deployments and replicasets, this role answers one specific container or orchestration question and keeps its own evidence.

Compare Pod image, readiness, and owner references across replicas. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not depend on one pod name as a stable service endpoint. The observable result is specific: all desired replicas use the intended template.

05

Revision history

Deployment revision history supports inspection and rollback to a previous Pod template. Within deployments and replicasets, this role answers one specific container or orchestration question and keeps its own evidence.

Record the change cause and identify the previous usable revision. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not assume unlimited revision history is retained. The observable result is specific: the current and prior revisions are distinguishable.

06

Availability result

Deployment conditions and ready or available counts show whether the rollout has achieved usable capacity. Within deployments and replicasets, this role answers one specific container or orchestration question and keeps its own evidence.

Wait for rollout status and verify the service response. Apply that action to the named workload before expanding scope, changing another resource, or discarding the current state.

Respect this boundary: do not accept updated replica count without readiness evidence. The observable result is specific: three ready replicas serve the new api version.

07

Apply Deployments and ReplicaSets to One Workload

Use one bounded workload decision: A three-replica API must move to a new image while retaining service capacity and a traceable previous revision.

First, set the desired image, replica count, labels, and update strategy in the deployment. Then, inspect the new and previous replicasets during rollout. Preserve both observations with the exact resource identity before changing runtime state.

Next, compare pod image, readiness, and owner references across replicas. After that, record the change cause and identify the previous usable revision. Close the task only after you wait for rollout status and verify the service response.

08

Recap Before Practice and Prove

Deployment intent: A Deployment manages a declarative rollout for stateless Pods through ReplicaSets. In this workload, set the desired image, replica count, labels, and update strategy in the deployment. Preserve the boundary: do not edit managed pods as the source of desired state.

ReplicaSet owner: A ReplicaSet keeps the requested number of matching Pod replicas for one template revision. In this workload, inspect the new and previous replicasets during rollout. Preserve the boundary: do not scale an owned replicaset separately from its deployment.

Pod replicas: Deployment-managed Pods are replaceable instances selected by labels rather than durable identities. In this workload, compare pod image, readiness, and owner references across replicas. Preserve the boundary: do not depend on one pod name as a stable service endpoint.

Revision history: Deployment revision history supports inspection and rollback to a previous Pod template. In this workload, record the change cause and identify the previous usable revision. Preserve the boundary: do not assume unlimited revision history is retained.

Availability result: Deployment conditions and ready or available counts show whether the rollout has achieved usable capacity. In this workload, wait for rollout status and verify the service response. Preserve the boundary: do not accept updated replica count without readiness evidence.