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.