What is the reverse of "kubectl apply"?

I was playing around in minikube and installed the wrong version of istio. I ran:

kubectl apply -f install/kubernetes/istio-demo-auth.yaml

instead of:

kubectl apply -f install/kubernetes/istio-demo.yaml

I figured I would just undo it and install the right one.

But I cannot seem to find an unapply command.

How do I undo a "kubectl apply" command?

One way would be kubectl delete -f <filename> but it implies few things:

1. The resources were first created. It simply removes all of those, if you really want to "revert to the previous state" I'm not sure there are built-in tools in Kubernetes to do that (so you really would restore from a backup, if you have one)

2. The containers did not modify the host machines: containers may mount root filesystem and change it, or kernel subsystems (iptables, etc). The delete command would not revert it either, and in that case you really need to check the documentation for the product to see if they offer any official way to guarantees a proper cleanup

It's really important to remember that technically there isn't an inverse to kubectl apply. This is because of how k8s works, it converges desired state against current state. By running apply, you are telling the cluster to "make it look like this". But the controllers in the cluster do not version your configuration in the strictest sense.

In your situation, what you really mean is "how do I get rid of the resources that were created by my misapplied manifest?" Which is not quite the same thing. The other answers do a good example of answering that for your situation. But it's useful to be aware that it is more nuanced than that.

What do I mean by that?

Consider what would happen if you applied a manifest, adjusted the contents of the manifest then reapplied it to a cluster? How would I go from state B to state A without deleting everything and restarting from scratch?

K8s doesn't remember what the previous state of your manifest was once its done the apply, there isn't an "undo" button in this context, so you can't revert it to a previous state just by running some form of hypothetical kubectl undo command.

If you wanted to undo some form of patch to a resource, you really need to use other tools outside of the scope of k8s. This is why version control becomes very important, particularly when you are operating more complicated stacks. In the scenario I proposed, you could potentially checkout a previous version and apply it to operate as your "rollback". As always, there are some caveats, but for most use cases this would work well.

If you created new application, use kubectl delete as @zerkms suggested.

However, if you are like me and deployed newer version to different cluster -- and therefore the app is stuck in creating mode like this:

NAME                   READY   STATUS             RESTARTS   AGE
my-application-csbxl   0/1     ContainerCreating  0          5m25s
my-application-5bcvc   1/1     Running            0          2d1h

Then the best solution is rollback, because it returns back to the previous deployment:

kubectl rollout undo deployment my-application