Deployments, rolling updates and rollbacks

Exam tasks: 2.1 (Deployments, rolling updates and rollbacks)

The decision: how do you change a running app's version so that capacity and downtime stay within the limits the task sets, and how do you get back to a known-good revision when it goes wrong?

How a rollout worksCopy Anchor Link

• A revision is created only when the Pod template changes. Scaling, or editing strategy, doesn't create one.
• Each revision is a ReplicaSet named <deployment>-<pod-template-hash>. Old ReplicaSets stay at 0 replicas so rollout undo can scale them back up. revisionHistoryLimit (default 10) caps how many are kept.
• The selector is immutable in apps/v1. To change it, delete and recreate the Deployment.

Strategy parametersCopy Anchor Link

spec:
  replicas: 6
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # up to 8 Pods in total
      maxUnavailable: 0  # never fewer than 6 available

• maxSurge and maxUnavailable can't both be 0.
• maxUnavailable: 0 with maxSurge: 1 is the "never lose capacity" setting, at the cost of a slower rollout and one Pod's worth of spare node capacity.
• Use Recreate when two versions must never run together, for example an app that migrates a database schema on start or holds a ReadWriteOnce volume that only one node can mount.

Commands you'll useCopy Anchor Link

k create deploy ledger --image=registry.local/ledger:2.3 --replicas=4 -n pay
k set image deploy/ledger ledger=registry.local/ledger:2.4 -n pay   # container=image
k annotate deploy/ledger kubernetes.io/change-cause="ledger 2.4: new fee rules" -n pay
k rollout status deploy/ledger -n pay --timeout=120s
k rollout history deploy/ledger -n pay
k rollout history deploy/ledger -n pay --revision=3   # Pod template of revision 3
k rollout undo deploy/ledger -n pay                   # back to the previous revision
k rollout undo deploy/ledger -n pay --to-revision=2
k rollout pause deploy/ledger -n pay                  # batch several edits into one revision
k rollout resume deploy/ledger -n pay
k rollout restart deploy/ledger -n pay                # new Pods, same spec

• In set image, the part before = is the container name, not the Deployment name. Check it with k get deploy ledger -o jsonpath='{.spec.template.spec.containers[*].name}'.
• rollout restart works by stamping a kubectl.kubernetes.io/restartedAt annotation on the Pod template, so it does create a new revision. Use it to pick up changed ConfigMaps consumed as env vars.
• rollout undo copies the old template forward as a new revision number. The revision you rolled back to disappears from the history list under its old number.
• While paused, template edits pile up without rolling. resume rolls them out as one revision.

Reading a rollout's stateCopy Anchor Link

k get deploy ledger -n pay            # READY, UP-TO-DATE, AVAILABLE
k get rs -n pay -l app=ledger         # one RS per revision, which one has the replicas
k describe deploy ledger -n pay       # Conditions and the scaling events per RS

Blue/green and canary with plain DeploymentsCopy Anchor Link

• Canary: run a second Deployment (ledger-canary, 1 replica) whose Pods share the label the Service selects on. Traffic splits roughly by Pod count.
• Blue/green: run ledger-blue and ledger-green with a track label and switch the Service selector from one to the other with k patch svc. Rollback is switching it back.
• For weighted splits that don't depend on Pod counts, use Gateway API HTTPRoute weights; see Gateway API.

ScenariosCopy Anchor Link

DrillCopy Anchor Link

kubectl config use-context drill-w1. In namespace atlas:

1. Create Deployment tiles with 4 replicas of nginx:1.27-alpine, container name tiles.
2. Configure it so a rollout never has fewer than 4 available Pods and adds at most 1 Pod at a time.
3. Update the image to nginx:1.28-alpine, recording the change cause upgrade to 1.28.
4. Roll back to the first revision and confirm the image.

kubectl config use-context drill-w1
k create ns atlas --dry-run=client -o yaml | k apply -f -
k create deploy tiles --image=nginx:1.27-alpine --replicas=4 -n atlas --dry-run=client -o yaml > tiles.yaml

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: tiles          # was nginx
        image: nginx:1.27-alpine

k apply -f tiles.yaml
k rollout status deploy/tiles -n atlas
k set image deploy/tiles tiles=nginx:1.28-alpine -n atlas
k annotate deploy/tiles kubernetes.io/change-cause="upgrade to 1.28" -n atlas
k rollout status deploy/tiles -n atlas
k rollout history deploy/tiles -n atlas        # revisions 1 and 2
k rollout undo deploy/tiles --to-revision=1 -n atlas
k rollout status deploy/tiles -n atlas

k get deploy tiles -n atlas -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'   # nginx:1.27-alpine
k get deploy tiles -n atlas -o jsonpath='{.spec.strategy.rollingUpdate}{"\n"}'
k rollout history deploy/tiles -n atlas        # now lists 2 and 3: revision 1 moved forward as 3

Further readingCopy Anchor Link

• Deployments
• kubectl rollout
• Performing a rolling update