Kubernetes rollback
This topic describes how Harness rolls back to the last successful version of your workload in response to failures.
Harness follows standard Kubernetes behavior during rollback. See kubectl rollout undo.
Workload rollback only
Rollback rolls back workloads only. If there are other objects or operations executed in your stage, Harness does not roll those back.
For details on Harness Kubernetes workloads, see What Can I Deploy in Kubernetes?.
Declarative rollback
You can use an alternative rollback behavior for Kubernetes deployments called declarative rollback.
Declarative rollback uses kubectl apply -f <prevision version of manifest>
instead of kubectl rollout undo
.
This method reduces the risk of getting in the wrong state in the subsequent deployment because the merge state is impacted by the rollout undo
command.
To enable declarative rollback, configure the following Harness service options. These options are defined in the service because they are tied to the service's manifests.
- YAML
- Pipeline Studio
Set the following options in the Harness service YAML:
skipResourceVersioning: false
enableDeclarativeRollback: true
Here's an example of a service with these settings configured.
service:
name: nginx
identifier: K8s
tags:
harness: "app"
sample: "demo"
serviceDefinition:
spec:
artifacts:
primary: {}
manifests:
- manifest:
identifier: dev
type: K8sManifest
spec:
store:
type: Harness
spec:
files:
- /Sample Manifest Onboarding
valuesPaths:
- /values.yaml
skipResourceVersioning: false
enableDeclarativeRollback: true
variables:
- name: replica
type: String
description: ""
value: "1"
- name: cpu
type: String
description: "nginx cpu"
value: "0.25"
- name: memory
type: String
description: "nginx memory"
value: 1Gb
type: Kubernetes
To configure these options in Pipeline Studio, do the following:
- In Services, select the Kubernetes service.
- In Manifests, add or edit a manifest.
- In the manifest wizard, navigate to Manifest Details.
- Expand Advanced.
- Select Enable Declarative Rollback.

The Skip Resource Versioning option is disabled automatically.
Important notes:
- Harness stores the manifest in the release history and fetches the last successful manifest for rollback.
- There is no more incremental versioning of the ConfigMap and Secret objects as there is with
kubectl rollout undo
. - During rollback, Harness reapplies the previous manifest. This is the declarative method, and it includes the ConfigMap and Secrets of the last known good state.
- With standard rollback, Harness stores release history in one ConfigMap. With declarative rollback, Harness stores release history in Secrets. Each release is stored in a different Secret, with one Secret per release.
- Harness uses a fixed limit of 2 in its release history cleanup logic, but release history cleanup is performed before the currently executing release goes through. Consequently, on average, you will have 3 secrets:
- Current release Secret.
- Previous successful release Secret.
- One more previous release Secret.