Kubernetes Rollbacks: How I Made Deployments Safer and Easier

Deploying new software is easy when everything works. The real challenge starts when something breaks.

How quickly can you restore the previous working version?

I recently improved my Kubernetes deployment workflow to make rollbacks predictable, traceable, and easier to execute.

Here are the practical changes that made the biggest difference.

1. Stop Using latest for Production

Using a Docker image like:

my-api:latest

makes it difficult to identify exactly which version is running.

Instead, I generate unique image tags using a timestamp and Git commit:

GIT_SHA=$(git rev-parse --short HEAD) BUILD_TIME=$(date +%Y%m%d-%H%M) IMAGE_TAG="${BUILD_TIME}-${GIT_SHA}"

Example:

my-api:20261101-1430-a8f21c3

This makes each deployment identifiable and helps ensure previous images can be restored.

Important: Image tags should never be overwritten.

2. Always Check Rollout History

After deploying, I verify the rollout:

kubectl rollout status deployment/my-api

Check the currently configured image:

kubectl get deployment my-api \ -o jsonpath='{.spec.template.spec.containers[*].image}'

View deployment history:

kubectl rollout history deployment/my-api

These commands help identify the running version and available rollback revisions.

3. Keep Previous Revisions

Kubernetes needs Deployment revision history to perform rollbacks.

In the Deployment manifest:

spec: revisionHistoryLimit: 2

This retains up to two old ReplicaSets for rollback purposes.

For critical applications, keeping more revisions may be appropriate.

4. Roll Back with One Command

When a deployment causes problems:

kubectl rollout undo deployment/my-api

To restore a specific revision:

kubectl rollout undo deployment/my-api \ --to-revision=5

I also use a small Bash script that:

  • Displays the current image.
  • Shows available revisions.
  • Asks for confirmation.
  • Performs the rollback.
  • Waits for rollout completion.
  • Displays the resulting image.

The goal is to make recovery straightforward without hiding important information.

5. Verify the Application After Rollback

A successful Kubernetes rollout does not necessarily mean the application works correctly.

I check:

kubectl rollout status deployment/my-api kubectl get pods -l app=my-api kubectl logs deployment/my-api --tail=100

Then verify the application's health endpoint:

curl -fsS https://example.com/health

A rollback is complete only after the application has been verified.

6. Understand What Rollbacks Cannot Fix

Kubernetes Deployment rollbacks restore a previous Pod template, but they do not automatically reverse:

  • Database migrations
  • External service failures
  • Incompatible schema changes
  • Changes to external configuration or secrets
  • Other independently deployed services

These require separate recovery planning.

Final Thoughts

My deployment workflow now follows five simple principles:

  1. Use unique, immutable image tags.
  2. Keep useful deployment history.
  3. Make rollback commands easy to execute.
  4. Confirm before changing production.
  5. Verify the application after recovery.

A reliable deployment process is not one that never fails. It is one that makes recovery predictable.

Written by **Giorgi Beria, Software Engineer & Product Builder.

Originally published on giorgiberia.com.

GitHub: github.com/giorgiberia