Assignment

Earlier today, the Nautilus DevOps team deployed a new release for an application. However, a customer has reported a bug related to this recent release. Consequently, the team aims to revert to the previous version.

There exists a deployment named nginx-deployment; initiate a rollback to the previous revision.

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

Solution

Rollback — `nginx-deployment` to the previous revision

Revert the deployment to the revision that was live before the buggy release.

Why no heredoc apply here: a rollback isn't a declarative manifest operation. It doesn't describe a desired end-state in YAML — it tells the Deployment controller to switch back to a previously recorded ReplicaSet revision stored in rollout history. That's an imperative rollout action, so kubectl rollout undo is the correct (and only idiomatic) tool. Re-applying an old manifest would work only if you happened to still have the exact prior YAML, and even then it's the wrong abstraction.

Command

# Roll back to the immediately previous revision
kubectl rollout undo deployment/nginx-deployment

# Block until the rollback finishes and pods are Ready
kubectl rollout status deployment/nginx-deployment

How it works

Rollout history and revisions

Every change to a Deployment's pod template (image bump, env change, etc.) creates a new revision, each backed by its own ReplicaSet. Kubernetes retains old ReplicaSets (up to spec.revisionHistoryLimit, default 10) precisely so you can roll back. You can inspect them:

kubectl rollout history deployment/nginx-deployment

What `rollout undo` does

With no --to-revision flag, it reverts to the immediately previous revision — the one running before the current (buggy) release. That's exactly this task.
Mechanically, it scales the previous ReplicaSet back up and the current one down using the same RollingUpdate strategy — so the rollback itself is gradual and keeps the app serving, no full outage.
The rollback is recorded as a new revision in history (revisions move forward even when the content is an older template), so you always have a clean audit trail.

Targeting a specific revision (if needed)

If "previous" isn't the right target, pick an explicit revision from the history:

kubectl rollout undo deployment/nginx-deployment --to-revision=<N>

For this task the default (previous revision) is what's required, so no flag is needed.

Verify

# Rollback completed, pods Ready
kubectl rollout status deployment/nginx-deployment

# Confirm the image/template reverted to the prior version
kubectl get deployment nginx-deployment \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

# History shows a new revision at the top reflecting the rollback
kubectl rollout history deployment/nginx-deployment

Expected — rollout reports success with all pods Running/READY, the container image reverted to the previous release's tag, and a new revision entry recording the rollback.

If the rollback stalls, kubectl describe deployment nginx-deployment and kubectl get pods -l <selector> show what's blocking (e.g. the old image also failing to pull).

3.3 KiB Raw Blame History