Skip to main content

Rollback

Did something go wrong after deployment? With rollback, you can quickly restore to the previous version. When bugs or performance issues appear after a new version, you can return to a stable previous version with just a few clicks.

The rollback method differs by runtime
  • Kubernetes: The Deployment Management tab in the operations modal has an Instant Rollback button (kubectl rollout undo).
  • Docker · Podman: There is no dedicated rollback UI. Roll back by selecting a previous image tag in the Deploy stage and redeploying.
When is rollback needed?
  • When unexpected errors occur after deploying a new version.
  • When performance degradation or memory leaks are discovered.
  • When compatibility issues with external services arise.
  • When serious bug reports come in from users.

Deployment Management Tab

Rollback Overview​

Rollback methods differ by runtime.

  • Kubernetes: Use the Immediate Rollback button in the Deployment Management tab of the operations modal to revert to the previous revision. Internally, it executes kubectl rollout undo.
  • Docker: There is no dedicated rollback UI. To roll back, redeploy a previous image tag from the Deploy stage.
Current Implementation Scope

The KIOPS UI can only roll back automatically to the previous revision (N-1). To roll back to an earlier revision, run kubectl rollout undo --to-revision=N manually in the Command Execution tab of the operations modal.

Kubernetes Rollback​

Step 1: Check Deployment History​

  1. Click the Operations card for the service on the [Service Management] page.
  2. Select the Deployment Management tab in the operations modal.
  3. Click the View History button. The raw output of kubectl rollout history is shown in a TextArea.

Example Rollout History Output​

deployment.apps/my-app
REVISION  CHANGE-CAUSE
3         kubectl set image deployment/my-app api=registry/api:v1.0.2
4         kubectl set image deployment/my-app api=registry/api:v1.0.3
5         kubectl set image deployment/my-app api=registry/api:v1.0.4
  • The output is not a formatted table — it is the raw standard output of the kubectl command.
  • The current revision corresponds to the topmost or bottommost entry depending on cluster state.
  • The CHANGE-CAUSE column shows the command or annotation recorded at deployment time.

Step 2: Run Immediate Rollback​

  1. Review the history output and decide whether to revert to the previous revision.
  2. Click the Immediate Rollback button.
  3. After confirming in the dialog, the backend runs kubectl rollout undo deployment/<name> -n <namespace>.
No revision picker

The KIOPS UI does not let you pick a specific revision to roll back to. The Immediate Rollback button always invokes the command without the --to-revision flag, so it only reverts to the previous revision (N-1).

Step 3: Verify Rollback Result​

After rollback completes, open the Pod List tab in the operations modal and verify the new ReplicaSet has started normally.

  • All Pod statuses are Running
  • Service responses are normal (Health Check passes)
  • No errors in logs
  • Key features work properly

Docker · Podman Rollback​

There is no dedicated rollback UI in the Docker·Podman environment. You roll back by selecting a previously successful image tag and redeploying.

Step 1: Find the Previous Image Tag​

  1. Select the service on the [Service Management] page.
  2. Check the build history or container registry for a previously working image tag.
Finding Image Tags

If the tag format is ${BRANCH}-${SHORT_SHA}, you can find it from the previous commit hash.

Step 2: Redeploy the Previous Image​

  1. Click the Deploy stage in the pipeline.
  2. In the DockerDeployModal, change the Image Version to the previous version.
  3. Make sure the Auto-backup before deploy option is enabled. With it on, the state right before redeploy is backed up so you can restore it if the redeploy fails.
  4. Click the Deploy button.

Step 3: Check Container Status​

In the operations modal's Container List tab, verify the new container is Running and the logs contain no errors.

Rolling Back to Earlier Revisions (Emergency / Manual)​

The Immediate Rollback button only reverts to the previous revision. To roll back two or more revisions back, run commands manually.

Run from the Command Execution Tab​

  1. Open the Command Execution tab in the operations modal.
  2. List the available revisions:
kubectl rollout history deployment/<deployment-name> -n <namespace>
  1. Pick a revision number and roll back to it:
kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number> -n <namespace>
Verify State After Manual Rollback

After a manual rollback, KIOPS's deployment history view and the actual cluster state may be temporarily out of sync. Verify the actual Pod state in the Pod List tab, and re-fetch the latest history via the View History button if needed.

Rollback Precautions​

Database Migrations​

Be sure to check before rolling back.

  • Schema Changes: Verify if tables/columns were added or changed in the new version.
  • Data Compatibility: Verify if data saved in the new format is compatible with the previous version.
  • Migration Rollback: Review if the DB migration also needs to be rolled back.
Destructive Migration Warning

If destructive migrations like column deletion or type changes were applied, simple rollback may be difficult. Check DB backups and consult with your DBA.

Configuration Changes​

Settings to verify when rolling back.

  • Environment Variables: Are all environment variables needed by the previous version present?
  • ConfigMap: Are configuration values compatible with the previous version?
  • Secret: Were authentication credentials changed?

External Service Integration​

  • If external API versions changed, verify compatibility.
  • Check communication protocols with other microservices.

Handling Rollback Failures​

If the Previous Image Is Unavailable​

  • Deleted from registry: Rebuild from the previous version source code.
  • Tag overwritten: Try to restore using the image digest (SHA).
Restoring via Image Digest

If you check the image digest (SHA256) in Harbor or Docker Hub, you can restore to a specific version even if the tag was overwritten.

If Docker Redeploy Fails​

If the auto-backup-before-deploy option was enabled, you can restore the containers/volumes to the state captured at backup time. Open the [Backup Management] page, select the corresponding backup, and run the restore.

If Issues Persist After Rollback​

  1. Log Analysis: Identify the root cause from application logs.
  2. Environment Check: Review environment variables, ConfigMap, and Secret settings.
  3. External Dependencies: Check database and external API status.
  4. Earlier Version: Roll back further from the Command Execution tab if needed.

Best Practices to Prevent Rollbacks​

Recommendations to reduce situations requiring rollback.

Pre-deployment Verification Checklist​

  • Build: Verify tests passing and security scan passing.
  • Staging: Perform functional testing and performance testing.
  • Canary: Real environment verification with partial traffic.
  • Production: Set up monitoring dashboard and alert configuration.

Stable Rollout Settings (Kubernetes)​

Recommended settings for stable rollouts in Kubernetes.

  • Pod startup safety: Configure progressDeadlineSeconds.
  • Health Checks: Configure readinessProbe and livenessProbe.
  • Resource protection: Configure resources.limits.
Gradual Rollout

Setting maxUnavailable: 0 keeps existing Pods until new Pods reach Ready status. If issues occur, new Pods never become Ready and the existing Pods continue to serve traffic.