Deployments, ReplicaSets and rolling changes

The mechanism

A Deployment manages ReplicaSets, which manage Pods. Changing the Pod template creates a new rollout revision rather than editing running containers in place. The rollout strategy controls how old and new replicas overlap.

A rolling update trades temporary capacity against availability. maxSurge permits extra replicas; maxUnavailable permits some desired capacity to be unavailable during the transition. These settings interact with readiness, scheduling capacity and application compatibility.

ParcelOps should tolerate old and new versions running together during a rollout. Database schema changes, queue message formats and external API assumptions need their own compatibility plan. Kubernetes cannot infer whether two application versions can safely share state.

Worked example

This offline manifest fragment shows rollout intent. The image is an intentionally non-runnable placeholder; replace it with a reviewed artifact only in an approved environment. It is not a complete hardened production manifest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: parcelops
  namespace: handbook-lab
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels: {app: parcelops}
  template:
    metadata:
      labels: {app: parcelops}
    spec:
      containers:
        - name: api
          image: registry.example/parcelops/api:reviewed-version

Practice: predict, inspect, explain

Offline exercise. With two desired replicas, calculate the maximum temporary Pod count under this strategy. Then assume the new version never becomes ready. Explain why the rollout can stall while old replicas keep serving, and why insufficient capacity for the surge Pod can also block progress.

Expected observation: the intended maximum is three Pods during the rolling transition, subject to lifecycle details and actual observed state. Record readiness and rollout conditions rather than declaring success immediately after the manifest is accepted.

Troubleshooting and trade-offs

If a rollout stalls, inspect new-Pod events, readiness and resource constraints. If rollback restores the image but the application still fails, investigate external data or schema changes. A Deployment rollback does not reverse every downstream effect. Avoid treating a successful rollout condition as proof that business transactions remain correct.

Interview practice

Completion check

Calculate the overlap budget and explain the stalled-readiness and insufficient-capacity cases.

Sources and version notes

Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.

• Official documentation: Deployment
• Official documentation: Assign pod node
• Official documentation: Liveness readiness startup probes