> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/prune-kubernetes-resources.md).
# Prune Kubernetes resources
Perform Kubernetes pruning during Rolling and Blue Green deployments
This topic describes how to perform Kubernetes pruning using Harness.
Changes to the manifests used in Harness Kubernetes deployments can result in orphaned resources you are unaware of.
For example, one deployment might deploy resources A and B, but the next deployment deploys A and C. C is the new resource and B was removed from the manifest. Without pruning, resource B remains in the cluster.
You can manually delete Kubernetes resources using the [Delete](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/delete-kubernetes-resources.md) step, or you can set Harness to perform resource pruning during deployment using the **Enable Kubernetes Pruning** setting in the **Rolling Deployment** and **Stage Deployment** (used in Blue Green deployments) steps.
Harness uses pruning to remove any resources that were present in an old manifest but are no longer present in the manifest used for the current deployment.
Harness also lets you identify resources you do not want pruned using the annotation `harness.io/skipPruning`.
***
## What you will learn from this topic
* How [Kubernetes pruning criteria](#harness-kubernetes-pruning-criteria) compare the current release with prior releases
* How pruning behaves for [Rolling](#harness-kubernetes-pruning-criteria) and [Blue Green](#harness-kubernetes-pruning-criteria) deployments
* How to [skip pruning for a resource](#skip-pruning-for-a-resource) with `harness.io/skipPruning`
* How to read [pruning examples](#pruning-examples) in pipeline execution
***
## Before you begin
Confirm the following before you enable pruning:
* [Kubernetes Continuous Delivery quickstart](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-cd-quickstart.md): Basic Kubernetes service, environment, and pipeline setup.
* [Create a Kubernetes Rolling deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-rolling-deployment.md): Rolling strategy used with pruning.
* [Create a Kubernetes Canary deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-canary-deployment.md): Related Kubernetes strategy background.
* [Delete Kubernetes resources](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/delete-kubernetes-resources.md): Manual delete step when you need an explicit delete instead of prune.
***
## Supported platforms and technologies
Pruning is supported for the following deployment strategies:
* Rolling deployments
* Blue Green deployments
Go to [Supported platforms and technologies](/continuous-delivery/new-to-continuous-delivery/cd-integrations.md) for the full integrations list.
***
## Important notes
Review the following limitations before you enable pruning:
* To prevent pruning using the Harness annotation `harness.io/skipPruning: "true"`, the resource must have been deployed by Harness.
* Harness pruning does not consider resources outside of a Harness deployment.
* If you make any changes to your Kubernetes resources using a tool other than Harness (before or after the deployment), Harness does not track those changes.
* The maximum manifest/chart size is 0.5MB. When Harness prunes, it stores the full manifest in ConfigMap to use it as part of release history. While deploying very large manifests/charts through Kubernetes, Harness is limited by ConfigMap capacity.
* While it is unlikely, if you use the same entity in two Harness services, Harness does not know this. If you prune the resource in one deployment, it might be unavailable in another deployment. Use the annotation `harness.io/skipPruning: "true"` to avoid issues.
* Ensure that the metadata name for deployments is unique for each deployment. If names are shared, ConfigMaps can be overwritten, which can cause resources to be removed.
* Infrastructure release names should also be unique. By default, this is set to `release-<+INFRA_KEY>`, but if you change it, go to [INFRA\_KEY and INFRA\_KEY\_SHORT\_ID](https://developer.harness.io/docs/platform/variables-and-expressions/harness-expressions-reference) to keep the value unique.
{% hint style="warning" %}
**Release name uniqueness**
Platform documentation describes `release-<+INFRA_KEY_SHORT_ID>` as the current default for Kubernetes and Native Helm in some flows. Confirm the value in your infrastructure definition before you rely on it for prune safety.
{% endhint %}
***
## Harness Kubernetes pruning criteria
Kubernetes pruning in Harness is similar to the `kubectl apply --prune` method provided by [Kubernetes](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune-l-your-label).
Kubernetes pruning queries the API server for all objects matching a set of labels and attempts to match the returned live object configurations against the object configuration files.
Similarly, Harness compares the objects you are deploying with the objects it finds in the cluster. If Harness finds objects that are not in the current release, it prunes them.
Harness also lets you identify resources you do not want pruned using the annotation `harness.io/skipPruning`.
Rolling deployments
When the **Enable Kubernetes Pruning** setting is enabled, Kubernetes Rolling deployments manage pruning as follows:
1. During deployment, Harness compares resources in the last successful release with the current release.
2. Harness prunes the resources from the last successful release that are not in the current release.
3. If a deployment fails, Harness recreates the pruned resources during its Rollback stage.
4. During rollback, any new resources that were created in the failed deployment stage that were not in the last successful release are deleted also.
Blue Green deployments
When the **Enable Kubernetes Pruning** setting is enabled, Kubernetes Blue Green deployments manage pruning as follows:
* Harness does not recreate pruned resources during rollbacks caused by failure.
* By default, rollback for Blue Green deployments only consists of swapping back the service selectors.
* Pruning is not performed on the immediate previous release. Harness prunes the resources of all older non-primary releases (n-2 release onwards). For example:
1. release r1 → a, b, c
2. release r2 → a, b, d
3. release r3 → a, b, e (only c is pruned)
4. release r4 → a, b, e (d is now pruned)
***
## Pruning examples
The first time you deploy a resource (Deployment, ReplicaSet, and similar kinds), no pruning takes place.
In Harness pipeline execution, you see a **Prune** section with the following message:
```bash
No previous successful deployment found, so no pruning required
```
When the **Enable Kubernetes Pruning** setting is enabled and Harness finds resources that match the pruning criteria, you see a message like this:
```bash
kubectl --kubeconfig=config delete Deployment/k8s-orphaned-resource-b --namespace=default
deployment.apps "k8s-orphaned-resource-b" deleted
kubectl --kubeconfig=config delete ConfigMap/k8s-orphaned-resource-configmap-b --namespace=default
configmap "k8s-orphaned-resource-configmap-b" deleted
Pruning step completed
```
If a deployment fails, Harness recreates any of the pruned resources it removed as part of the deployment. In the **Rollback** step, you see a **Recreate Pruned Resources** section with a message like this:
```bash
kubectl --kubeconfig=config apply --filename=manifests.yaml --record
deployment.apps/k8s-orphaned-resource-f created
Successfully recreated pruned resources.
```
***
## Skip pruning for a resource
To ensure that a resource is not pruned, add the annotation `harness.io/skipPruning: "true"`.
When Harness identifies resources from the last successful release that are not in the current release, it searches for the `harness.io/skipPruning` annotation and ignores any resources that have it set to `true`.
You can deploy a resource using the annotation `harness.io/skipPruning: "true"`, and then if the manifest is removed and another deployment occurs, Harness sees the annotation `harness.io/skipPruning: "true"` on the resource previously deployed and skips pruning it.
As noted in [Important notes](#important-notes), you cannot add a resource with the annotation outside of a Harness deployment and have Harness skip the pruning of that resource.
***
## Troubleshooting
A resource I still need was pruned
Confirm that the resource was present in the current manifest and that it does not share a metadata name or release name with another Harness service. If the resource must remain when it leaves the manifest, add `harness.io/skipPruning: "true"` in a Harness-managed deployment before you remove it from the manifest.
Pruning removed something edited outside Harness
Harness pruning only tracks resources from Harness deployments. Changes made with other tools are not considered. Keep cluster edits in the Harness-managed manifests, or use `harness.io/skipPruning: "true"` for resources that must remain.
Blue Green rollback did not recreate pruned resources
Blue Green rollback swaps service selectors and does not recreate pruned resources. Restore needed objects from a prior release manifest or redeploy a release that includes them.
***
## Next steps
* [Delete Kubernetes resources](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/delete-kubernetes-resources.md): Remove specific resources with the Delete step.
* [Create a Kubernetes Rolling deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-rolling-deployment.md): Enable pruning on Rolling Deployment.
* [Create a Kubernetes Blue Green deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md): Use Stage Deployment pruning behavior for Blue Green.
{% @harness-feedback/feedback %}