Rollback to previous version in Kubernetes - Deep Dive

Overview - Rollback to previous version

What is it?

Rollback to previous version in Kubernetes means returning an application or service to an earlier state after a failed or unwanted update. It helps fix problems caused by new changes by restoring the last working version. This process is automatic or manual and uses Kubernetes' built-in features to manage application versions safely.

Why it matters

Without rollback, a bad update could cause downtime, errors, or data loss, affecting users and business. Rollback lets teams quickly fix issues by going back to a stable version, reducing disruption and improving reliability. It makes updates safer and builds confidence in continuous delivery.

Where it fits

Before learning rollback, you should understand Kubernetes Deployments and how updates work. After rollback, you can explore advanced deployment strategies like blue-green and canary deployments to minimize risks during updates.

Mental Model

Core Idea

Rollback is like an undo button that restores your application to the last known good state when a new update causes problems.

Think of it like...

Imagine writing a document and saving versions as you go. If you make a mistake, you open the previous saved version to fix it. Rollback in Kubernetes works the same way for your app versions.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Version 1    │──────▶│ Version 2    │──────▶│ Version 3    │
│ (Stable)    │       │ (Updated)   │       │ (Problem)   │
└───────────────┘       └───────────────┘       └───────────────┘
         ▲                                              │
         │                                              ▼
         └────────────────────────────── Rollback ──────┘
                        Restores Version 2

Build-Up - 6 Steps

1

Foundation

Understanding Kubernetes Deployments

Concept: Learn what a Deployment is and how it manages app versions.

A Deployment in Kubernetes manages a set of identical pods running your app. It controls how many pods run and updates them when you change the app version. Each update creates a new ReplicaSet, which tracks the pods for that version.

Result

You know that Deployments keep track of app versions and manage updates automatically.

Understanding Deployments is key because rollback works by switching between these versions managed as ReplicaSets.

2

Foundation

How Updates Create New Versions

Concept: Updates to Deployments create new ReplicaSets representing new app versions.

When you change the container image or config in a Deployment, Kubernetes creates a new ReplicaSet for the new version. It gradually replaces old pods with new ones to update the app without downtime.

Result

You see that each update is a new version tracked separately, enabling easy switching back if needed.

Knowing that updates create separate versions helps you understand how rollback can restore an earlier version by switching ReplicaSets.

3

Intermediate

Manual Rollback Using kubectl Commands

🤔Before reading on: do you think rollback requires deleting and recreating Deployments or can it be done with a simple command? Commit to your answer.

Concept: Learn how to rollback manually using Kubernetes commands.

You can rollback a Deployment to a previous version using the command: kubectl rollout undo deployment/ This command switches the Deployment back to the last working ReplicaSet. You can also specify a revision number to rollback to a specific version: kubectl rollout undo deployment/ --to-revision=

Result

The Deployment switches back to the chosen previous version, replacing pods with the older app version.

Knowing the exact command lets you quickly fix problems without complex steps, making rollback practical in emergencies.

4

Intermediate

Checking Rollback Status and History

🤔Before reading on: do you think Kubernetes automatically shows rollback history or do you need to check it manually? Commit to your answer.

Concept: Learn how to view rollout history and status to manage rollbacks safely.

Use these commands to check rollout status and history: kubectl rollout status deployment/ Shows if the current rollout is complete or failed. kubectl rollout history deployment/ Lists all revisions with details, helping you choose which version to rollback to.

Result

You can monitor updates and pick the right version to rollback, avoiding guesswork.

Understanding rollout history prevents accidental rollbacks to bad versions and helps plan safer updates.

5

Advanced

Automated Rollback on Failed Updates

🤔Before reading on: do you think Kubernetes automatically rolls back on failed updates or requires manual intervention? Commit to your answer.

Concept: Learn how Kubernetes can automatically rollback if an update fails health checks.

Kubernetes Deployments use readiness and liveness probes to check pod health during updates. If new pods fail these checks, the rollout pauses or fails. You can configure Deployment strategies with maxUnavailable and maxSurge to control update speed. If failure is detected, Kubernetes can automatically rollback to the last stable version to keep the app running.

Result

Failed updates do not cause downtime because Kubernetes restores the previous working version automatically.

Knowing automated rollback mechanisms helps you design safer deployments that recover without manual fixes.

6

Expert

Rollback Limitations and Complex Scenarios

🤔Before reading on: do you think rollback always restores all previous states perfectly, including data and config? Commit to your answer.

Concept: Understand what rollback does not cover and how to handle complex cases.

Rollback only changes the app version in pods, not external resources like databases or persistent storage. If an update changes database schema or external configs, rolling back the app alone may cause errors. Also, rollback history is limited; very old versions may be garbage collected. For complex apps, you must coordinate rollback of all components and data migrations carefully.

Result

You realize rollback is powerful but not a full disaster recovery solution; extra planning is needed for complex systems.

Knowing rollback limits prevents false confidence and encourages holistic recovery strategies.

Under the Hood

Kubernetes Deployments manage app versions using ReplicaSets. Each update creates a new ReplicaSet with a unique revision number. Rollback switches the Deployment's active ReplicaSet pointer back to a previous revision, causing Kubernetes to terminate pods from the current ReplicaSet and start pods from the chosen older ReplicaSet. This process uses the Deployment controller's reconciliation loop to ensure the desired state matches the rollback target.

Why designed this way?

This design separates version management from pod lifecycle, allowing safe, atomic switches between versions without deleting Deployment objects. It supports gradual rollouts, rollbacks, and history tracking. Alternatives like replacing pods directly risk downtime or inconsistent states. Using ReplicaSets as version snapshots balances flexibility and safety.

┌─────────────────────────────┐
│ Deployment Controller        │
│                             │
│  ┌───────────────┐          │
│  │ ReplicaSet v1 │◀─────────┤
│  └───────────────┘          │
│           │                 │
│           ▼                 │
│  ┌───────────────┐          │
│  │ ReplicaSet v2 │◀─────────┤
│  └───────────────┘          │
│           │                 │
│           ▼                 │
│  ┌───────────────┐          │
│  │ ReplicaSet v3 │          │
│  └───────────────┘          │
│                             │
│ Rollback switches active RS │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does rollback in Kubernetes also restore database changes automatically? Commit yes or no.

Common Belief: Rollback restores the entire application state including databases and external resources.

Reality: Rollback only changes the application pods to a previous version; it does not affect databases or external systems.

Why it matters: Assuming rollback fixes everything can cause data corruption or app crashes if database schema or data is incompatible with the rolled-back app version.

Quick: Is rollback always instantaneous and risk-free? Commit yes or no.

Common Belief: Rollback is a quick, risk-free operation that always fixes problems immediately.

Reality: Rollback can take time as pods are terminated and recreated, and may cause temporary downtime or instability if not managed carefully.

Why it matters: Underestimating rollback complexity can lead to poor incident response and longer outages.

Quick: Does Kubernetes keep unlimited rollback history? Commit yes or no.

Common Belief: Kubernetes stores all previous versions forever, so you can rollback to any past version anytime.

Reality: Kubernetes keeps a limited number of revisions; older ReplicaSets may be cleaned up automatically.

Why it matters: Expecting unlimited rollback history can cause surprises when old versions are no longer available for rollback.

Quick: Does rollback require deleting and recreating the Deployment? Commit yes or no.

Common Belief: To rollback, you must delete the Deployment and create it again with the old version.

Reality: Rollback is done by changing the Deployment's active ReplicaSet using a simple command; no deletion is needed.

Why it matters: Misunderstanding rollback commands can cause unnecessary downtime and manual errors.

Expert Zone

1

Rollback only switches pod versions; it does not revert config changes stored in ConfigMaps or Secrets unless explicitly updated.

2

The Deployment controller uses a revision annotation to track versions, but manual edits to ReplicaSets can break rollback history.

3

Automated rollback depends on readiness and liveness probes; poorly designed probes can cause false rollbacks or block recovery.

When NOT to use

Rollback is not suitable when updates involve irreversible database migrations or external system changes. In such cases, use full disaster recovery plans, backups, or blue-green deployments to switch traffic safely.

Production Patterns

Teams use rollback combined with monitoring and alerting to detect failures quickly. They often pair rollback with canary deployments to limit impact. Some use GitOps tools to manage Deployment manifests and rollback declaratively.

Connections

Version Control Systems (e.g., Git)

Rollback in Kubernetes is similar to reverting commits in Git.

Understanding how version control tracks changes helps grasp how Kubernetes tracks app versions and switches between them.

Continuous Integration/Continuous Deployment (CI/CD)

Rollback is a safety net in CI/CD pipelines for automated deployments.

Knowing rollback helps design pipelines that can recover from failed deployments automatically or manually.

Undo Functionality in Software Applications

Rollback acts like an undo feature for application versions.

Recognizing rollback as an undo operation clarifies its purpose and limitations in system recovery.

Common Pitfalls

#1 Assuming rollback fixes database schema mismatches automatically.

Wrong approach:

kubectl rollout undo deployment/myapp
# Then expecting database to match old app version without migration

Correct approach:

# Rollback app version
kubectl rollout undo deployment/myapp
# Also run database migration rollback scripts manually

Root cause:

Misunderstanding that rollback only affects app pods, not external databases.

#2 Trying to rollback by deleting and recreating the Deployment with old image.

Wrong approach:

kubectl delete deployment myapp
kubectl create deployment myapp --image=myapp:v1

Correct approach:

kubectl rollout undo deployment/myapp

Root cause:

Not knowing the built-in rollback command and how Deployment manages versions.

#3 Ignoring rollout status and history before rollback.

Wrong approach:

kubectl rollout undo deployment/myapp
# Without checking if rollback target is stable

Correct approach:

kubectl rollout history deployment/myapp
kubectl rollout status deployment/myapp
kubectl rollout undo deployment/myapp --to-revision=

Root cause:

Skipping verification leads to rolling back to unstable or broken versions.

Key Takeaways

Rollback in Kubernetes lets you restore your application to a previous working version quickly and safely.

It works by switching the Deployment's active ReplicaSet to an earlier revision, replacing pods with the older version.

Rollback only affects application pods, not external resources like databases or configs, so plan accordingly.

You can perform rollback manually with kubectl commands or rely on Kubernetes to automate rollback on failed updates.

Understanding rollback limits and history helps avoid common mistakes and ensures reliable recovery in production.

Practice

1. What does the command kubectl rollout undo deployment/myapp do in Kubernetes?

easy

A. It updates the deployment 'myapp' to the latest image version.

B. It rolls back the deployment 'myapp' to its previous version.

C. It deletes the deployment 'myapp' permanently.

D. It scales the deployment 'myapp' to zero replicas.

Solution

1. Step 1: Understand the command purpose

   The command kubectl rollout undo is used to revert a deployment to a previous state.

2. Step 2: Apply to the given deployment

   Using deployment/myapp specifies which deployment to rollback.

3. Final Answer:

   It rolls back the deployment 'myapp' to its previous version. -> Option B

4. Quick Check:

   Rollback command = revert deployment [OK]

Hint: Rollback uses 'kubectl rollout undo' with deployment name [OK]

Common Mistakes:

• Confusing rollback with delete command
• Thinking it updates to latest version instead of previous
• Using scale command instead of rollback

2. Which of the following is the correct syntax to rollback a deployment named 'webapp' to its previous version?

easy

A. kubectl rollout undo deployment/webapp

B. kubectl rollback deployment/webapp

C. kubectl undo deployment webapp

D. kubectl rollback undo webapp

Solution

1. Step 1: Recall correct rollback syntax

   The correct command to rollback is kubectl rollout undo deployment/<name>.

2. Step 2: Match syntax with deployment name

   Replacing <name> with 'webapp' gives kubectl rollout undo deployment/webapp.

3. Final Answer:

   kubectl rollout undo deployment/webapp -> Option A

4. Quick Check:

   Correct rollback syntax = rollout undo [OK]

Hint: Remember 'rollout undo' is the rollback command [OK]

Common Mistakes:

• Using 'rollback' instead of 'rollout undo'
• Incorrect order of words in command
• Missing 'deployment/' prefix

3. Given the following commands executed in order:

kubectl apply -f deployment-v1.yaml
kubectl apply -f deployment-v2.yaml
kubectl rollout undo deployment/myapp

What will be the current version of the deployment 'myapp' after the last command?

medium

A. Version 1 (deployment-v1.yaml)

B. Version 2 (deployment-v2.yaml)

C. No change, still version 2

D. Deployment deleted

Solution

1. Step 1: Understand deployment updates

   First, version 1 is applied, then version 2 updates the deployment.

2. Step 2: Rollback command effect

   The rollback command reverts the deployment to the previous version, which is version 1.

3. Final Answer:

   Version 1 (deployment-v1.yaml) -> Option A

4. Quick Check:

   Rollback reverts to last version before update [OK]

Hint: Rollback returns to version before last update [OK]

Common Mistakes:

• Assuming rollback deletes deployment
• Thinking rollback keeps current version
• Confusing rollback with reapply

4. You tried to rollback a deployment using kubectl rollout undo deployment/myapp but got an error: error: no rollout found. What is the most likely cause?

medium

A. Rollback command requires a namespace flag.

B. You misspelled the deployment name in the command.

C. The deployment 'myapp' has no previous versions to rollback to.

D. The Kubernetes cluster is down.

Solution

1. Step 1: Analyze the error message

   The error 'no rollout found' means no previous rollout history exists for rollback.

2. Step 2: Identify cause

   This usually happens if the deployment was never updated or has only one version.

3. Final Answer:

   The deployment 'myapp' has no previous versions to rollback to. -> Option C

4. Quick Check:

   No rollout history = no rollback possible [OK]

Hint: Check rollout history before rollback [OK]

Common Mistakes:

• Assuming cluster is down causes this error
• Forgetting to check deployment name spelling
• Thinking rollback always works without history

5. You have a deployment 'api-server' with three revisions in history. You want to rollback to revision 2 specifically. Which command should you use?

hard

A. kubectl rollout undo deployment/api-server revision=2

B. kubectl rollback deployment/api-server --revision=2

C. kubectl undo deployment/api-server revision 2

D. kubectl rollout undo deployment/api-server --to-revision=2

Solution

1. Step 1: Recall rollback to specific revision syntax

   The correct syntax to rollback to a specific revision is kubectl rollout undo deployment/<name> --to-revision=<number>.

2. Step 2: Apply to 'api-server' and revision 2

   Replacing placeholders gives kubectl rollout undo deployment/api-server --to-revision=2.

3. Final Answer:

   kubectl rollout undo deployment/api-server --to-revision=2 -> Option D

4. Quick Check:

   Use '--to-revision' flag to rollback specific version [OK]

Hint: Use '--to-revision' flag to rollback specific version [OK]

Common Mistakes:

• Using incorrect flags like --revision or wrong command order
• Omitting '--to-revision' flag
• Using 'rollback' instead of 'rollout undo'