85 lines
3.3 KiB
Markdown
85 lines
3.3 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
# 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:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
# 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). |