Introduction

Kubernetes does not have a kubectl unapply command. If you used kubectl apply -f to create or update resources from a manifest, the normal way to reverse that action is kubectl delete -f with the same manifest or with another manifest that identifies the same resources.

The direct inverse is kubectl delete -f

If the file still represents the objects you want to remove, use it directly:

kubectl apply -f deployment.yaml
kubectl delete -f deployment.yaml

delete -f reads the resource kinds, names, and namespaces from the file and tells the API server to remove those objects.

This is the closest thing to "unapply" for manifest-based workflows.

Why Kubernetes does not have unapply

apply is declarative, but it is not a transaction log. Kubernetes stores the resulting resource state, not a reversible history of every file you previously applied.

That means "undo" depends on what you actually want:

• delete the objects entirely
• restore a previous version of the manifest
• remove only one change while keeping the resource

Those are different operations, and Kubernetes expects you to express the target state directly.

Example with multiple resources

Suppose app.yaml contains a Deployment and a Service:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: demo-app
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: demo-app
10  template:
11    metadata:
12      labels:
13        app: demo-app
14    spec:
15      containers:
16        - name: web
17          image: nginx:1.27
18---
19apiVersion: v1
20kind: Service
21metadata:
22  name: demo-app
23spec:
24  selector:
25    app: demo-app
26  ports:
27    - port: 80
28      targetPort: 80

Apply it:

kubectl apply -f app.yaml

Remove the same objects:

kubectl delete -f app.yaml

If the file names the same resources, Kubernetes can delete them even if some fields changed while the objects existed.

When you no longer have the original file

If the original manifest is gone, you can still delete resources by kind and name:

kubectl delete deployment demo-app
kubectl delete service demo-app

Or delete by label if the resources were labeled consistently:

kubectl delete all -l app=demo-app

Label-based cleanup is often the most manageable approach when one feature spans multiple manifests or generators.

Undoing a change without deleting the resource

Sometimes "unapply" really means "roll back the change." In that case, deleting the resource is wrong. Instead, apply the older desired state:

kubectl apply -f app-v1.yaml
kubectl apply -f app-v2.yaml
kubectl apply -f app-v1.yaml

That restores the earlier manifest values rather than removing the objects from the cluster.

For Deployments specifically, rollout history may help:

kubectl rollout undo deployment/demo-app

That is a Deployment feature, not a general replacement for delete -f.

Make deletion safer with labels and namespaces

A good manifest strategy includes predictable labels and explicit namespaces so resources can be removed safely later.

1metadata:
2  name: demo-app
3  namespace: staging
4  labels:
5    app.kubernetes.io/name: demo-app
6    app.kubernetes.io/part-of: checkout

Then cleanup becomes clearer:

kubectl delete -n staging -l app.kubernetes.io/name=demo-app deployment,service

This is especially useful when the original file is no longer the only source of truth.

Common Pitfalls

The biggest mistake is editing the manifest after applying it and then expecting kubectl delete -f to remove objects that are no longer named in the file. Deletion works only for the resources the file currently identifies.

Another issue is assuming apply keeps a built-in undo stack. It does not. If you need rollback, store your manifests in version control and reapply the desired revision.

Developers also forget about namespaces. Deleting the right object name in the wrong namespace does nothing, which can look like Kubernetes ignored the request.

Finally, be careful with broad label deletes such as kubectl delete all -l app=myapp. They are powerful, but the labels must be specific enough that you do not remove unrelated resources accidentally.

Summary

• There is no kubectl unapply; the normal inverse is kubectl delete -f.
• Use the same manifest when you want to remove the objects it defines.
• If you want rollback rather than deletion, reapply the previous desired state.
• Labels and namespaces make cleanup much safer and easier.
• Keep manifests in version control so deletion and rollback remain predictable.