“ kubectl application”的反义词是什么?

我在 minikube 玩游戏时,安装了错误的 istio 版本:

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

而不是:

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

我想我可以解除它,安装正确的那个。

但我似乎找不到 unapply命令。

我如何 撤销一个“ kubectl 应用”命令?

44353 次浏览

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

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

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.